mirror of
https://github.com/NVIDIA/cutlass.git
synced 2026-07-17 00:57:25 +00:00
05fd39dca2
* Add SM103 grouped block-scaled GEMM kernel Implements sm103_grouped_blockscaled_gemm.py combining SM103 kernel internals (7-warp layout, MXF4/NVF4 ops, K=768, dedicated TMA SF warp) with SM100 grouped scheduling (StaticPersistentGroupTileScheduler, per-group tensormap updates via SMEM, 5 tensormaps). * [CuTeDSL] Port SM103 grouped block-scaled GEMM to v4.5 + fix scale correctness Rebases the SM103 grouped block-scaled GEMM onto the current tree, which reorganized the CuTeDSL examples (#3202) and changed the TMEM-storage API. Port: - Move kernel to cute/blackwell/kernel/blockscaled_grouped_gemm/ sm103_grouped_blockscaled_gemm.py (beside the SM100 grouped kernel); update the test import to the new package path. - Adopt the v4.5 TMEM storage API: struct field tmem_dealloc_mbar_ptr -> tmem_dealloc_mbar; pointers via storage.<field>.ptr; local tmem_holding_buf -> tmem_holding_buf_ptr. - Rename 3xFP4 -> FP4 Ultra terminology to match the v4.5 dense kernel. Correctness fix at scale: The AB/SF TMA producer wait tokens (try_acquire peek) were initialized once before the persistent tile loop. Each tile's final stage skips the next try_acquire(), so a stale token was carried into the next work tile, letting acquire_and_advance(True) overwrite a pipeline buffer stage before MMA released it -> wrong results once total output tiles exceeded ~1-2K (launch failure at the largest sizes), while small-shape tests passed. Refresh ab_producer / sf_producer at each work-tile boundary inside the loop, matching the SM103 dense and SM100 grouped kernels. Add a large persistent regression test (8 x 2048^3). Verified on NVIDIA GB300 (sm_103, CUTLASS DSL 4.5.2): pytest test/examples/CuTeDSL/sm_103/ --runtime-sm 103 => 23 passed; compute-sanitizer memcheck clean on 8 x 4096^3.