Optimizations for q40, q80, q5k, fix Cosmos VLM prefill - #92
Open
liangliangchang wants to merge 7 commits into
Open
Optimizations for q40, q80, q5k, fix Cosmos VLM prefill#92liangliangchang wants to merge 7 commits into
liangliangchang wants to merge 7 commits into
Conversation
Apply the Q4_K J=128 WMMA split and next-K X prefetch to Q4_0 MMQ.
Co-authored-by: Cursor <cursoragent@cursor.com>
Q5_K unpacks to the same IU8 SRAM as Q4_K, so reuse the J=128 ntx=1 wmma_low / convert / wmma_high schedule and the Q4_K J policy. Co-authored-by: Cursor <cursoragent@cursor.com>
Prefetch Q5_K low- and high-bit data during WMMA while distributing high bits across lanes to keep J128 spill-free. Co-authored-by: Cursor <cursoragent@cursor.com>
The prefetch pipeline was gated on J == 96 || J == 128, but the batched WMMA vec_dot it feeds is gated on J == 128 only, and rows_per_warp() returns 16 (ntx=1) only at J == 128 -- at J == 96 it returns 32 (ntx=2). So J == 96 paired the prefetch with the generic two-minitile kernel. Q8_0 is also the only type caching 2*(I/nwarps) = 32 ints where the others cache 16, on top of two A tiles and 48 accumulators, so that combination spills. mmq_rdna35_tuned_J maps Q8_0 J_occupancy == 64 to 96 to avoid the J == 64 pathology, which made every 64-wide batch land on the broken width. MoE Q8_0 (J > 32 -> 96) had the same exposure. Cosmos-Reason2-8B Q8_0 prefill on gfx1151, llama-bench -p 512 -r 3 against rocm/gfx11 03d2068: ubatch 64: 111.4 -> 178.7 t/s (was -37.7% vs gfx11, now -0.1%) ubatch 96: n/a -> 267.6 t/s (now -0.4% vs gfx11) ubatch 128: 1426.8 -> 1430.9 t/s (+3.0% vs gfx11, unchanged) ubatch 512: 1581.5 -> 1581.9 t/s (+2.8% vs gfx11, unchanged) The J == 128 win is retained in full. test-backend-ops MUL_MAT q8_0: 64/64. Co-authored-by: Cursor <cursoragent@cursor.com>
Q4_0 and Q8_0 only have a batched WMMA vec_dot at J=128. At the other two widths where rows_per_warp() would pick 32 (J=64 and J=96, the only J>=64 multiples of 32) they fall back to the generic two-minitile schedule, which is several times slower on gfx115x. J=72/80/88/104/112/120 are unaffected because they are not multiples of 32 and already run ntx=1. This is a pre-existing cliff, not a regression: gfx11 shows it too. Q4_K is not affected, since its generic path handles ntx=2 well. llama-bench -p 512 -r 3 on gfx1151, versus rocm/gfx11 03d2068: Cosmos-Reason2-8B Q8_0 ubatch 64: 178.9 -> 883.1 t/s (+394%) ubatch 96: 268.8 -> 1151.4 t/s (+328%) Qwen3-14B Q4_0 ubatch 64: 153.6 -> 708.7 t/s (+361%) ubatch 96: 156.8 -> 725.8 t/s (+363%) Unaffected widths are unchanged (Q8_0 ubatch 32: 534.5 -> 533.1, ubatch 128: 1389.7 -> 1416.1). test-backend-ops MUL_MAT q4_0+q8_0: 134/134. Co-authored-by: Cursor <cursoragent@cursor.com>
The widening existed because J=64 was several times slower for q8_0, but that was the generic ntx=2 schedule which rows_per_warp() no longer selects for block quants. With J=64 healthy the widening only pads 64 valid columns into a 96-wide tile. Cosmos-Reason2-8B Q8_0, llama-bench -p 512 -r 3 on gfx1151: ubatch 64 (J 96 -> 64): 883.1 -> 1118.5 t/s (+26.7%) ubatch 96 (J 96, same): 1151.4 -> 1147.2 t/s (-0.4%) ubatch 128 (J 128, same): 1416.1 -> 1398.1 t/s (-1.3%) MoE keeps its own widening, which is untested here and unchanged. test-backend-ops MUL_MAT: 1484/1484. Co-authored-by: Cursor <cursoragent@cursor.com>
liangliangchang
marked this pull request as ready for review
September 1, 2026 19:49
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Highlights: prefill gains on the shapes the MMQ work targets
Q4_0: Latency and throughput
Q8_0 Latency and throughput
Q5_k Latency and throughput
Model performance