mirror of
https://github.com/deepseek-ai/DeepGEMM.git
synced 2026-11-05 00:47:26 +00:00
[PR #480] Use the allocated TMEM base in the SM100 HC prenorm GEMM #482
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
deepseek-ai/DeepGEMM#482
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Pull Request Information
Original PR: https://github.com/deepseek-ai/DeepGEMM/pull/480
Author: @XFDG
Created: 10/21/2026
Status: 🔄 Open
Base:
main← Head:fix/479-sm100-hc-prenorm-tmem-base📝 Commits (1)
6563a81Use the allocated TMEM base in the SM100 HC prenorm GEMM📊 Changes
1 file changed (+8 additions, -4 deletions)
View changed files
📝
deep_gemm/include/deep_gemm/impls/sm100_tf32_hc_prenorm_gemm.cuh(+8 -4)📄 Description
Fixes #479.
sm100_tf32_hc_prenorm_gemm_implallocates 256 tensor memory columns, but it addresses its cast A stages and its accumulator from column 0 and frees them withfree(0, kNumTmemCols). The allocator can return a non-zero base when another CTA on the same SM already holds tensor memory. This kernel uses at most about 200 KB of shared memory, so a small CTA of another kernel, for example one on another stream, can run next to it. The GEMM then writes into that CTA's columns, andtcgen05.deallocon columns it does not own hits the tcgen05 guardrail trap.This change reads the base that the allocator wrote after
__syncthreads()and adds it to every tensor memory address and tofree, assm100_mega_mhcalready does.Validation on B200 (CUDA 13.1). A test kernel is launched first on one stream with one CTA per SM (148 CTAs). Each CTA allocates 32 or 256 columns (all at base 0), fills them with a pattern and holds them until the GEMM on a second stream has finished, then checks them. In every concurrent run that completed, the GEMM finished while all 148 CTAs were still resident.
main(5081f85)freefixed (diagnostic)unspecified launch failureunspecified launch failurecalc_diffis NaN)Under cuda-gdb,
mainstops insm100_tf32_hc_prenorm_gemm_impl<24u, 7168u, 64u, 32u, 64u, 16u, 128u, 12u, 128u, 128u>with the error from the issue:tests/test_hyperconnection.pypasses with and without this change. Kernel times are unchanged within noise: across the 24 shapes of that test, median per-kernel times differ by -8% to +6% in both directions (geometric mean 0.996). Another process shared the GPU during timing, so these numbers are not exact. The SASS of the two configs I compared has 24 and 32 fewer instructions, with the same or one fewer register.The other SM100 kernels that free from column 0 (
sm100_bf16_gemm,sm100_fp8_fp4_gemm_1d1d,sm100_bmk_bnk_mn,sm100_sparse_mqa_logits,sm100_mqa_logits,sm100_bf16_mega_gate, and the two Mega MoE kernels) are not changed here. I can extend this PR if you want them handled the same way. The test kernel and script are about 340 lines; I can share them if that helps.🤖 Generated with Claude Code
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.