Skip to content

[Kernel] Fix single-accumulator RDNA3 GEMM tiles - #986

Open
skyguan92 wants to merge 1 commit into
ROCm:mainfrom
skyguan92:codex/rdna3-single-acc-20260808
Open

[Kernel] Fix single-accumulator RDNA3 GEMM tiles#986
skyguan92 wants to merge 1 commit into
ROCm:mainfrom
skyguan92:codex/rdna3-single-acc-20260808

Conversation

@skyguan92

Copy link
Copy Markdown
Contributor

Summary

  • preserve the RDNA3 GEMM accumulator container when an scf.for has exactly one carried result
  • add a native gfx11 regression for the resulting 16x16x32 one-atom tile

Problem

On current main (3df2d7c70059b53f352d83226f9ee8edeceecb33), the public tile parameters admit (reg_m, reg_n, reg_k, waves_m, waves_n)=(1,1,2,1,1). That produces one WMMA accumulator. FlyDSL returns the single post-loop result as the carried vector value, but the kernel always slices it as a sequence:

TypeError: unsupported index type: <class 'slice'>
  rdna3_f16_gemm.py:356: accs = list(results[:n_acc])

The fix wraps that one result before the epilogue and leaves the existing multi-result path unchanged.

Validation

Tested on a Radeon PRO W7900, native gfx1100, ROCm/HIP 7.2, PyTorch 2.9.1+gitff65f5b, with HSA_OVERRIDE_GFX_VERSION unset.

  • new focused regression: 1 passed
  • related RDNA F16/BF16 suite: 23 passed, 7 deselected
  • Ruff 0.16.2 format check and lint: passed
  • BF16 correctness against FP32 torch accumulation passed for the five M16 DeepSeek-V4-aligned (K,N) rows: (4096,1024), (1024,4096), (4096,512), (4096,2048), and (2048,4096)
  • generated ISA for M16/N512/K4096 is wave32, contains 8 static v_wmma_f32_16x16x16_bf16 instructions, contains no scalar FMA fallback, and reports zero private segment/scratch

For bounded performance reconnaissance, the enabled 16x16x64 tile measured 17.735 us hot kernel p50 at M16/N512/K4096 versus 19.059 us for the previously buildable 16x32x64 control (200 captured launches, 4 replays/round, 31 rounds). It is not uniformly faster across all projection shapes, so this PR deliberately changes no default tile, autotune heuristic, or dispatch policy.

This only fixes a legal RDNA3 kernel configuration. It does not add M<16 tail handling or claim an end-to-end model speedup.

FlyDSL unwraps a single scf.for result to the carried value, while the RDNA3 GEMM epilogue always slices the result as a sequence. A one-atom 16x16 tile therefore fails during JIT emission before it can launch.

Keep the accumulator container stable for the one-result case and add a native gfx11 regression that exercises the pipelined K loop.

Signed-off-by: guanjiawei <128683929+skyguan92@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant