perf(gfx1100): share Q8 KV scans across verifier rows

[alpineQ]

Summary

Follow-up to the R4/R8 discussion in #695 and the qwen3.8 long-context report in #693. This is the multi-row verifier rebased and reviewed as one commit directly on current beta (b8092f7c7).

One wave now owns four or eight Q8 attention query rows and shares each K/V scan across them. The partials layout and reducer are unchanged, and projection GEMMs remain batched.

The route is fail-closed to:

• exact gfx1100;
• Q8 KV;
• head_dim 128 or 256;
• sequential, non-tree batches of 4–32 rows;
• logical context >4096;
• graph capture off.

The launcher repeats the arch/shape checks. If admission and launcher support ever drift, execution falls through to the established batched Step::Attend; it does not fan out into per-row launches. HIPFIRE_FA_PERTOKEN_MIN_CTX=0 disables the route.

Canonical XT product evidence

RX 7900 XTX, gfx1100, wave32, HIP 7.2.53211-9999.

• target qwen3.8-27b.mq4-xt: 14,980,361,216 bytes, SHA-256 9f91556f7e0431a077d03756a7102d0154108757289e6e5fe9a2d204c0c9eeb7, MD5 e45d15bfe0c9a87132697101d17cbed6;
• draft: SHA-256 d0a74a232a0e2166d889f823e91e0fbf778d21dd9668d7de055cdecb065401bc, MD5 013395583cd04206c8aa68f4d061983d;
• committed prompt: benchmarks/prompts/qwen38_issue693_longcode_20676.txt, 75,251 bytes, MD5 b4d0b63cddcac872648ddf3cdd92cac2, 21,550 actual model tokens;
• tested daemon MD5 512fccca7c7189559048a7aba17cb6c1.

Six fresh native-daemon processes, order off,on,on,off,off,on, Q8 KV, DFlash, greedy, HIPFIRE_VERIFY_GRAPH=0, 10-second DPM warmup, 200 output tokens. Same candidate binary and JIT cache; the sole arm delta was route threshold 0 versus 4096. A separate unrecorded probe warmed the cache before the series.

route	decode samples	median	delta
existing batched	33.4, 32.6, 33.4 tok/s	33.4	—
R4/R8	46.4, 42.9, 46.3 tok/s	46.3	+38.6%

All six runs produced 200 tokens in 69 cycles with tau=1.88, no errors, and identical output MD5 b501ab0e0102889bd63537f2006d4f61. A separately built and warmed clean-beta daemon produced 33.5 tok/s with the same output/tau/cycles, matching the disabled candidate arm. The first baseline invocation was cold-JIT and was discarded rather than normalized away.

The committed fixture-bound checkpoint records the complete protocol and identities; lifecycle is historical, not an admission claim.

Kernel evidence

Dedicated oracle, Qwen3.8-27B shape (24 Q heads / 4 KV heads / hd256), 100 timed iterations per cell:

context	R4 vs batched	R8 vs batched
2,048	0.98x	0.72x
4,096	1.45x	2.01x
20,676	1.99x	2.40x
32,768	1.94x	2.28x

Worst relative error was 4.222e-7 (limit 1e-3). The hd128 screen at ctx8192 measured 1.33x/2.03x, worst relative error 3.419e-7.

Radiowave metadata: R4 hd256 = 106 VGPR / 41 SGPR; R8 hd256 = 186 / 58; both wave32 with zero VGPR/SGPR spills and zero private scratch.

Validation

• test_kernels: 16/16 on gfx1100;
• cargo test --release -p rdna-compute -p hipfire-arch-qwen35 --lib: 242/242 and 193/193 (4 ignored);
• canonical-XT serve_harness.py battery: 5/5 coherent, recall checks passed, no empty/runaway/attractor output;
• release CLI/daemon and both hardware examples built;
• crate maps, env-doc scan, changed-file rustfmt, fmt-bomb and diff checks passed.

The canonical kernel-bucket Redline PM4 arm does not pass on either lane. Clean beta and this candidate both stop at the same pre-existing limitation:

gemv_mq4g256v2_residual: GFX10/GFX11 PM4 dispatch does not yet support scratch
(private=32, dynamic_callstack=false)

Before that refusal both lanes had the same prefill/decode launch counts and hashes. The new multi-row route is excluded during graph/retained capture, so the failure is not in the new kernel; I am recording it explicitly rather than presenting the battery alone as a full kernel-bucket pass.

This improves verifier cost only. It does not improve draft/target agreement: tau remains 1.88 on this fixture, so sufficiently low-tau workloads can still favor AR.