Fix SM107 (Rubin) grouped GEMM quant: read TMEM accumulator before releasing the overlapping stage - #673
Conversation
…the overlapping stage Apply the same fix as NVIDIA#654 to the Rubin (SM107) kernel moe_blockscaled_grouped_gemm_quant_rubin.py, which has the identical pattern: the overlapping accumulator stage was released before the TMEM->register copy of that stage's subtile, allowing the MMA warp to overwrite the accumulator while the epilogue was still reading it. Move the t2r copy ahead of the early-release block so the accumulator is read before consumer_release. The other Rubin kernels (glu, glu_hadamard_quant, dglu) already perform the copy before the release, and wgrad_rubin has overlapping_accum disabled, so only this file is affected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 12 included reviews per hour; 11 remain after this review. 📝 WalkthroughWalkthroughThe quantized Rubin grouped GEMM epilogue now copies the TMEM accumulator fragment before the overlapping-accumulator fence and pipeline-stage release. ChangesQuantized Rubin GEMM epilogue
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to This is a localized ordering fix in the Rubin grouped GEMM path, and no actionable merge-blocking risk remains beyond normal checks and review. Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Summary
Follow-up to #654, which fixed the SM100 grouped GEMM kernels to read the TMEM accumulator before releasing the overlapping accumulator stage. As noted in #654 (comment), the Rubin (SM107) kernel
moe_blockscaled_grouped_gemm_quant_rubin.pyhas the identical pattern.With
overlapping_accumenabled, the epilogue released the accumulator stage (acc_pipeline.consumer_release) before performing the TMEM→register copy of that stage's subtile. Once released, the MMA warp can start overwriting the accumulator while the epilogue is still reading it, corrupting results. This PR applies the same reorder as #654: move thet2rcopy ahead of the fence + early-release block.Scope
Checked all Rubin kernels containing the
iter_acc_early_release_in_epilogueearly-release pattern:grouped/quant/moe_blockscaled_grouped_gemm_quant_rubin.pygrouped/glu/moe_blockscaled_grouped_gemm_glu_rubin.pygrouped/glu_hadamard_quant/moe_blockscaled_grouped_gemm_glu_hadamard_quant_rubin.pygrouped/dglu/moe_blockscaled_grouped_gemm_dglu_rubin.pygrouped/wgrad/moe_blockscaled_grouped_gemm_wgrad_rubin.pyoverlapping_accum = False)Summary by CodeRabbit