[bong-water-water-bong]

On Qwen3.8-27B UD-Q4_K_XL, 94% of HRX prompt time went to the generic f32 WMMA matmul kernels, which work in 32-token tiles. An iree-profile dispatch trace of a 1.8K-token prompt:

Kernel	Share
mul_mat_swiglu	51%
mul_mat_add	25%
mul_mat	18%

This model's projections are mostly Q5_K and IQ4_XS. Two routing rules kept them away from the q8_1 x4 prefill kernel:

1. 89078ac: the q8_1 x4 matcher took Q5_K and IQ4_XS only when q8_1 activations already existed, and never for a matmul feeding a GLU. Q4_K was allowed both. Q5_K and IQ4_XS now get the Q4_K policy.
2. 5085ae2: even then, the FFN gate/up projections went to the generic fused mul_mat_swiglu. It is registered at priority 290, above the q8_1 x4 matcher (285), and claims gate, up and the GLU together; that was 59% of prompt time. For prompt chunks of 256-2048 tokens in multiples of 256, whose gate and up are Q4_K, Q5_K or IQ4_XS, it now declines. Each projection then takes the q8_1 x4 kernel and the GLU runs as its own op.

GGML_HRX_Q8_PREFILL_RELAX=0 restores the old routing for both.

gfx1151, llama-bench -b 512 -ub 512	before	after
pp512	99.7	340.7
pp2048	99.0	317.7
KLD vs BF16 logits (wikitext-2, 20 x 512)	0.00717	0.00712
same top token	96.13%	96.27%

test-backend-ops -o MUL_MAT -b HRX0: 265/265. Decode is untouched, since both rules apply only to chunks of at least 256 tokens.

🤖 Generated with Claude Code

[bong-water-water-bong]

Review (PR-Agent duty). A large showcase win (Qwen3.8-27B HRX pp512 99.7 -> 340.7, pp2048 99.0 -> 317.7) with KLD vs BF16 unchanged (0.00717 -> 0.00712) and MUL_MAT ops 265/265. The approach is right.

Checked:

• Rule 1 (Q5_K / IQ4_XS take the Q4_K q8_1 x4 policy): standalone q8_1 quantize, GLU consumers allowed. It's gated by common_q8_prefill_relaxed(), read once, default on, with =0 restoring the old routing.
• Rule 2 (mul_mat_swiglu declines for 256..2048-token chunks in multiples of 256, when both gate and up are Q4_K/Q5_K/IQ4_XS): each projection then takes q8_1 x4 and the GLU runs as its own op. If the q8_1 x4 matcher declines some shape, the node falls back to the generic per-op path, which is correct, just slower. So the decline can't strand a node.
• Decode untouched: both rules need at least 256 tokens.

Before merge:

1. The two Windows Test failures (x64-openblas, x64-vulkan). HRX isn't built on Windows, so this change likely isn't the cause, but #54's Windows jobs passed. Please re-run them, or show the failing test is pre-existing. Their logs weren't available when I looked.
2. The numbers in the code comments (pp512 143 -> 363, 99 -> 141, KLD 0.00720) are from the intermediate builds and differ from the PR table. Fine as history, but say which step each refers to, or use the final numbers, so nobody reads 363 as current.

Non-blocking: this is policy logic in AMD's files (dispatch-mul-mat.cpp, dispatch-gated-mul-mat.cpp, dispatch-mul-mat-common.h), about 35 lines. It's acceptable as small hooks, but if it grows, move common_q8_prefill_relaxed() and the format predicate into a headed file of ours.

Mergeable once (1) is cleared.