triton-kernels: publish an XPU build variant - #1136
Merged
github-actions[bot] merged 2 commits intoSep 4, 2026
Merged
Conversation
The kernel is `[torch-noarch]`, but `backends` still decides which variant
directories are published to the Hub, and it lists only `cuda`. On an Intel
GPU `get_kernel` therefore fails outright:
FileNotFoundError: Cannot find a build variant for this system in
kernels-community/triton-kernels
torch-cuda: backend (cuda) does not match system backend (xpu)
and is not universal
which now also stops the test suite from being collected at all, since the
tests moved to `get_kernel`. The Intel opt-flag heuristics added in huggingface#1075 are
consequently unreachable through `kernels`.
Being noarch, this adds no compilation: the extra variant has the same file
set as `torch-cuda`, the same way `liger-kernels` publishes torch-cuda,
torch-rocm and torch-xpu from identical sources.
Several tests hardcoded `device="cuda"` or called `torch.cuda.*` unconditionally, so on a non-CUDA build they failed with "Torch not compiled with CUDA enabled" rather than exercising the kernel. Take the existing `device` fixture instead, and guard the capability-based skips behind `target_info.is_cuda()` so they stay skips on CUDA and are simply not consulted elsewhere. `test_routing.init_data` loses its `device` default for the same reason; both call sites (test_routing, test_swiglu) already have the fixture at hand. The `kernels_ci` subset and the full test_mxfp / test_routing / test_swiglu / test_tensor_details modules pass on Intel Arc Pro B60 (131 passed, 9 skipped). No behaviour changes on CUDA, where the fixture already defaults to "cuda".
jiqing-feng
marked this pull request as ready for review
September 4, 2026 02:30
Member
|
/kernel-bot build triton-kernels |
|
Build request processed. Command: Dispatched (1):
|
danieldk
approved these changes
Sep 4, 2026
Member
|
/kernel-bot merge-and-upload triton-kernels |
|
Build request processed. Command: Merge result: Pull Request successfully merged Dispatched (1):
Hub uploads: |
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
2 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.
Follow-up to #1075. The Intel fixes landed there, but they are still unreachable through
kernels.triton-kernelsis[torch-noarch], yetbackendsdecides which variant directories get published, and it lists onlycuda. So the repo shipsbuild/torch-cudaonly andget_kernelfails on an Intel GPU:Adding
xpucosts no compilation — being noarch, the variant has the same file set astorch-cuda.liger-kernelsalready publishestorch-cuda,torch-rocmandtorch-xputhis way.rocmis left out here only because I cannot validate it.The second commit lets the tests honour the existing
--devicefixture instead of hardcodingdevice="cuda"/torch.cuda.*; compute-capability checks move behindis_cuda(), and genuinely CUDA-only tests are untouched.Validation
Intel Arc Pro B60,
--device xpu: 14 passed / 2 skipped for thekernels_cisubset, 131 passed / 9 skipped across the edited modules.--device cudais unchanged, and the CUDA-only CI runner gains no new job.