[glennneuber]

Summary

Folds the ROCm host's variant into docs/maxusai/tasks/mmq-29953-y-tile-guard.patch, the compile-time guard offered as material for llama.cpp#29953, as agreed on #455. With it, nvcc and hipcc report exactly the guard's errors, and agree build for build.

The guard's per-type static_asserts were gathered by a static_assert on a fold. Under clang, once a per-type assertion fails that outer expression stops being constant, so clang added one error per failing table, worded like a constant-evaluation limit. The variant gathers them with an explicitly instantiated class that inherits every per-type guard (#455, #456).

nvcc 12.8, sm_120, mmq.cu compiled directly, every build scored by why it failed:

host load at start (1/5/15 min): 38.78 35.94 28.60, 32 cores
1-head-unpatched                   rc=0   ok   want=ok   as-expected    13.5s
patch applies to a pristine 3070d927f6c172242d56a2c1fb897e838e7b2632
2-head-with-guard                  rc=0   ok   want=ok   as-expected    19.1s
3-helper-shrunk-to-J-blocks        rc=2   fail want=fail as-expected     5.0s
    errors=220, from the guard=220, tables named: ampere blackwell cdna gcn pascal_dp4a pascal_older rdna2 rdna3 rdna3_5 rdna4
4-helper-rounded-to-one-warp       rc=2   fail want=fail as-expected     5.0s
    errors=220, from the guard=220, tables named: ampere blackwell cdna gcn pascal_dp4a pascal_older rdna2 rdna3 rdna3_5 rdna4
mutation 5 rewrote:     CASE(GGML_TYPE_MXFP4, 256, 1, 128,   8, GGML_CUDA_MMQ_SRAM_LAYOUT_FP4, MMQ_ITER_K_FP4, true, true); ->     CASE(GGML_TYPE_MXFP4, 192, 1, 128,   8, GGML_CUDA_MMQ_SRAM_LAYOUT_FP4, MMQ_ITER_K_FP4, true, true);
5-blackwell-config-at-192-threads  rc=2   fail want=fail as-expected     6.1s
    errors=1, from the guard=1, tables named: blackwell
mutation 5b rewrote:     CASE(GGML_TYPE_Q1_0, 256, 2, 128,  64, GGML_CUDA_MMQ_SRAM_LAYOUT_Q8_0, MMQ_ITER_K, false, true); ->     CASE(GGML_TYPE_Q1_0, 160, 2, 128,  64, GGML_CUDA_MMQ_SRAM_LAYOUT_Q8_0, MMQ_ITER_K, false, true);
5b-rdna3_5-config-at-160-threads   rc=2   fail want=fail as-expected     6.0s
    errors=1, from the guard=1, tables named: rdna3_5
6-guard-compiled-out               rc=0   ok   want=ok   as-expected    14.2s
VERIFY29953GUARD COMPLETE 2026-10-05T04:51:06Z all_as_expected=1

• hipcc agrees on every build (ROCm 7.2.1, gfx1151, run by the ROCm host in docs(mmq): Verify the #29953 y-tile guard under hipcc for #455 #456), including blackwell at 192 and rdna3_5 at 160.
• No generated code changes, on either compiler. On hipcc mmq.o is byte-identical with and without the guard. On nvcc, whose objects differ from build to build, the host disassembly is identical across the first form, the variant, no guard and a repeat build.
• Cost: about 3 s per nvcc compile of mmq.cu (a median of 15.2 s against 11.8 s at a load of 28-36), and 0.8 s on hipcc.
• Build 5b is new: rdna3_5 at 160 threads. The 192 that Help wanted (ROCm): does the llama.cpp#29953 y-tile guard compile, and fire, under hipcc? #455 first specified cannot fire on rdna3_5, whose first 256-thread line has J = 64.

Changes

• tasks/mmq-29953-y-tile-guard.patch: the variant folded in; still +70/-9 on 3070d927f, and it applies cleanly.
• tasks/mmq-29953-guard-verify.sh: build 5b, and a header note on the variant.
• tasks/mmq-successor-results/: verify-29953-guard.txt and guard-timing.txt re-run against the folded patch.
• upstream-mmq-29953-material.md: the guard section updated for the variant, 5b, hipcc and the object comparison; the Conclusion says verified on both compilers; a note in the ten-architecture section reflowed.
• llama/compat/README.md: "verified with nvcc and hipcc".

Docs and tooling only. Nothing here ships: the guard is material for the maintainer, and nothing goes to ggml-org.

Test plan

• The folded patch applies to a pristine 3070d927f.
• nvcc: the seven builds above, all as expected.
• hipcc: docs(mmq): Verify the #29953 y-tile guard under hipcc for #455 #456, all as expected (the ROCm host will re-run against this patch once it is on main).
• Timing: five interleaved repeats (guard-timing.txt).
• check_source_paths.py --changed-since origin/main, name scan.

🤖 Generated with Claude Code

---

From ai-server/mlx-cuda via /collab · 2026-10-05 · build llama.cpp 3070d927f + folded guard patch, nvcc 12.8 · signed ai-server

[glennneuber]

Metal review at ff8835b79: approve. Documentation only, and it merges cleanly into main at 377f9d144. It also merges together with #456.

• 903 already ships this form. compat: 903 becomes llama.cpp#29953 plus the y-tile guard, at b11351 (verified on CUDA and ROCm) #462 took the guard "as docs(mmq): fold the ROCm host's variant into the #29953 y-tile guard #458 has it (ff8835b79, with the ROCm host's variant)", and main's 903 has the explicit-instantiation form (mmq.cu index fcfaa3c, the same as this PR's patch).
• The task files on main are still the first form. docs/maxusai/tasks/mmq-29953-y-tile-guard.patch is blob 729f22c27, with the outer static_assert fold. upstream-mmq-29953-material.md, mmq-29953-guard-verify.sh, verify-29953-guard.txt and guard-timing.txt haven't changed since this PR's base. So main describes a guard that 903 no longer ships, and this PR fixes that.
• Nothing on main contradicts it. On Help wanted (ROCm): does the llama.cpp#29953 y-tile guard compile, and fire, under hipcc? #455 the ROCm host said "Yes, please fold it in."

A gap this PR doesn't close. #462 planned to update the compat README and the retirement register, and didn't. Both still describe 903 as the widest-padded-tile rule:

• llama/compat/README.md: "The rule lives in ggml_cuda_mmq_get_J_pad()", and "At the next pin move".
• the retirement register's 903 row.

#461 corrects README.md's own 903 rows. I'll open a small docs PR for the other two unless you'd rather take them.

Approved from Metal. The merge is yours.