kernel-builder: support specifying backend archs for noarch kernels#668
Merged
Conversation
So far, we have assumed that noarch kernels work on all GPU architectures for a supported backend. However, some noarch kernels work on a more limited set of hardware. This change adds options to the `torch-noarch` section to indicate which archs are supported, which are then written to the kernel metadata. Ideally we'd keep this path the same as arch kernels, where the capabilities are computed and written to metadata at build-time. However, this turns out to be quite tedious. This PR lets kernel-builder write it to metadata, but keeps noarch vs arch handling out of the common paths, keeping the functions in `common` as generic is possible. Instead, we move some of the code to the `kernels-data` crate. The `Metadata` struct gets a new `for_backend` constructor that creates the metadata for a given build configuration and backend. Co-authored-by: Sayak Paul <spsayakpaul@gmail.com>
|
The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update. |
Coverage report —
|
| Name | Stmts | Miss | Cover | Missing |
|---|---|---|---|---|
| src/kernels/__init__.py | 10 | 0 | 100% | |
| src/kernels/_system.py | 6 | 1 | 83% | 10 |
| src/kernels/_versions.py | 63 | 7 | 89% | 46, 49, 52-53, 56-57, 100 |
| src/kernels/backends.py | 194 | 55 | 72% | 40, 44, 48-51, 68, 90, 108, 117, 121, 125-127, 148, 170, 181, 188-191, 201, 205-225, 233, 256-276 |
| src/kernels/compat.py | 8 | 1 | 88% | 5 |
| src/kernels/deps.py | 54 | 4 | 93% | 58-59, 95, 98 |
| src/kernels/layer/__init__.py | 6 | 0 | 100% | |
| src/kernels/layer/_interval_tree.py | 103 | 4 | 96% | 23, 52, 147, 150 |
| src/kernels/layer/device.py | 48 | 14 | 71% | 42, 47-49, 91, 96-98, 101, 149, 152, 155-157 |
| src/kernels/layer/func.py | 93 | 7 | 92% | 72, 100, 154, 257, 263, 272, 290 |
| src/kernels/layer/globals.py | 5 | 0 | 100% | |
| src/kernels/layer/kernelize.py | 73 | 8 | 89% | 255, 273, 281-282, 288, 292, 308-310 |
| src/kernels/layer/layer.py | 174 | 15 | 91% | 166, 209, 215, 228, 320-321, 333, 342, 350, 361, 390, 394, 407, 460, 490 |
| src/kernels/layer/mode.py | 14 | 0 | 100% | |
| src/kernels/layer/repos.py | 130 | 34 | 74% | 27, 33, 36-41, 61-62, 68, 71-74, 88, 92, 101-102, 108, 111-114, 121-122, 128, 131-134, 141-142, 148, 151-154, 235 |
| src/kernels/lockfile.py | 71 | 46 | 35% | 37-104, 108-131 |
| src/kernels/status.py | 49 | 2 | 96% | 23, 81 |
| src/kernels/utils.py | 301 | 55 | 82% | 65, 77-81, 87-88, 218, 222, 225, 287, 295, 334-335, 373, 404, 409, 444, 673, 676, 678, 684, 697-698, 719-731, 735-742, 750, 754-764, 768-775, 813, 817, 836, 838 |
| src/kernels/variants.py | 262 | 19 | 93% | 56, 87, 108, 138, 247-248, 289, 291, 371-378, 384-390, 421-427, 439-445, 534-536 |
| src/kernels/verify.py | 88 | 1 | 99% | 32 |
| TOTAL | 1752 | 273 | 84% |
Updated by the Test kernels workflow on commit 78eaaf4939312894e49e95486ebdfe40075db749.
sayakpaul
previously approved these changes
Jun 24, 2026
Comment on lines
+72
to
+76
| let python_dependencies = | ||
| itertools::process_results(general.general_python_depends(), |iter| { | ||
| iter.flat_map(|(_, deps)| deps.python.iter().map(|d| format!("\"{}\"", d.pkg))) | ||
| .join(", ") | ||
| })?; |
Member
There was a problem hiding this comment.
Is this formatting change version-related?
Comment on lines
+62
to
72
| pub(crate) fn precomputable_backend_archs(&self, backend: Backend) -> Option<Vec<String>> { | ||
| match self { | ||
| Framework::TorchNoarch(torch_noarch) => match backend { | ||
| Backend::Cuda => torch_noarch.cuda_capabilities.clone(), | ||
| Backend::Rocm => torch_noarch.rocm_archs.clone(), | ||
| _ => None, | ||
| }, | ||
| _ => None, | ||
| } | ||
| } | ||
| } |
Comment on lines
+49
to
+60
| id, | ||
| name: build.general.name.clone(), | ||
| version: build.general.version, | ||
| license: build.general.license.clone(), | ||
| upstream: build.general.upstream.clone(), | ||
| source: build.general.source.clone(), | ||
| python_depends, | ||
| backend: BackendInfo { | ||
| archs, | ||
| backend_type: backend, | ||
| }, | ||
| digest: None, |
Member
There was a problem hiding this comment.
Okay this was pulled out of the builder.
Co-authored-by: Sayak Paul <spsayakpaul@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
So far, we have assumed that noarch kernels work on all GPU architectures for a supported backend. However, some noarch kernels work on a more limited set of hardware. This change adds options to the
torch-noarchsection to indicate which archs are supported, which are then written to the kernel metadata.Ideally we'd keep this path the same as arch kernels, where the capabilities are computed and written to metadata at build-time. However, this turns out to be quite tedious.
This PR lets kernel-builder write it to metadata, but keeps noarch vs arch handling out of the common paths, keeping the functions in
commonas generic is possible.Instead, we move some of the code to the
kernels-datacrate. TheMetadatastruct gets a newfor_backendconstructor that creates the metadata for a given build configuration and backend.