[kernel] VSA kernel: one sm_100a / sm_103a image per listed arch; un-gate backward on sm_103a - #1833
Open
lpc0220 wants to merge 2 commits into
Open
[kernel] VSA kernel: one sm_100a / sm_103a image per listed arch; un-gate backward on sm_103a#1833lpc0220 wants to merge 2 commits into
lpc0220 wants to merge 2 commits into
Conversation
…h; backward on sm_103a ENABLE_VSA_SM100_FAMILY built both data-center Blackwell images whenever either 10.0a or 10.3a appeared in TORCH_CUDA_ARCH_LIST, so a GB200 build (or the auto-detected default) also carried an sm_103a image and the arch list no longer meant what it said. It is replaced by ENABLE_VSA_SM100A and ENABLE_VSA_SM103A, one -gencode per listed architecture, the way the 9.0a / 12.0a entries are handled. The publish workflow lists 10.3a explicitly for the two Blackwell wheels. The VSA backward now builds the same images as the forward: its kernels' multi-arch guards admit the sm_103a pass (they compiled to empty stubs before), the Python is_supported accepts compute capability (10, 3), and the tests' skip conditions follow. The sm_103a backward is compile-only so far; B300/GB300 validation is the next step. Verified on GB200 (driver 580.178.04): TORCH_CUDA_ARCH_LIST=10.0a wheel -> 64 tests passed; TORCH_CUDA_ARCH_LIST=10.3a wheel (before the backward enable) carried only sm_103a images and no backward symbol, as intended. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Contributor
Merge Protections🔴 1 of 1 protections blocking · waiting on 👀 reviews and 🤖 CI
🔴 PR merge requirementsWaiting for
This rule is failing.
|
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
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.
Summary
ENABLE_VSA_SM100_FAMILY([feat] Add native SM103a VSA support #1812) compiled both the sm_100a and the sm_103a image whenever either10.0aor10.3aappeared inTORCH_CUDA_ARCH_LIST, so a GB200 build (or the auto-detected default) also carried an sm_103a image and the arch list no longer meant what it said. Every listed architecture paid for two images: a larger.so, and double the nvcc time for the VSA sources (the forward alone is several minutes per image). It is replaced byENABLE_VSA_SM100A/ENABLE_VSA_SM103Awith one-gencodeper listed architecture, the way the9.0a/12.0aentries are already handled. The publish workflow lists10.3aexplicitly for the two Blackwell wheels, which keeps shipping both images.block_sparse_attn_bwd_sm100a.is_supportedaccepts compute capability (10, 3), and the tests' skip conditions follow.Ungating GB300 for the forward and backward only gives B300/GB300 users an alternative to the Triton-only path: these are the GB200 kernels compiled for sm_103a, not kernels tuned for it. GB300-specific VSA kernels (using the sm_103a-only features) are left as future work.
No kernel code changes; the sm_100a images are byte-identical to before.
Test plan
TORCH_CUDA_ARCH_LIST=10.0awheel;tests/test_block_sparse_sm100a.py37,tests/test_block_sparse_bwd_sm100a.py16,tests/test_block_sparse_sm100a_dispatch.py11 passed; cmake reportsbuilding block_sparse_sm100a (sm_100a; ...).TORCH_CUDA_ARCH_LIST=10.3awheel (before the backward enable): onlysm_103aimages in the.so,block_sparse_sm100a_fwdpresent, no backward symbol, cmake reports(sm_103a; ...).TORCH_CUDA_ARCH_LIST=10.3awheel; the same three suites 37 / 16 / 11 passed;compute-sanitizer --tool memcheckon the backward clean; perf below.GB300 perf (sm_103a image = the GB200 kernels recompiled, nothing tuned for GB300)
B=1 H=8 D=128 bf16, 25% density, median of 3 alternating passes, TFLOPS. Forward in the selected-pairs convention, backward 2.5x that. Triton forward = the vendored reference copy; Triton backward =
fastvideo_kernelkernels, k2q precomputed.