You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
HIP: batch RDNA3.5 MMQ WMMA issue and pipeline the Q4_K weight tile
On the 64-row tile at J=128 the MMQ inner loop has one MMA per j-tile, so it
stalls on that tile's scales before it can issue. mma_half() splits the two WMMA
instructions mma() already emits, letting a caller issue every tile's first half,
load all the scales, then issue the second halves. It goes into the two existing
generic vec_dots rather than a new kernel, so Q4_0 and Q8_0 get it as well.
Q4_K additionally gets a split VRAM-load / SRAM-store pair for the weight tile,
so the kernel can read the next K-iteration's tile into registers while the
current iteration's MMAs run instead of stalling in front of the load.
Q8_0 and Q5_K move to the 64-row tile at J=128, which the batched schedule needs.
That tile on its own regresses those two, which is why the earlier tile-shape
change left them out; combined with batching it pays.
test-backend-ops perf on gfx1151, q4_K: +5.4% at m=4096 n=512 k=14336, +4.4% at
m=12288 n=128 k=4096, +15.1% at m=1024 n=128 k=4096. Batching alone is worth
+2.5% to +4.0% on q4_0 and q8_0. No measured shape regressed.
Correctness: 214/214 MUL_MAT, 225/225 MUL_MAT_ID.
Assisted-by: Claude Opus 5
Co-authored-by: Cursor <cursoragent@cursor.com>
0 commit comments