HRX: chat on Qwen3-Coder-30B-A3B and GLM-4.7-Flash fails with 500 "Compute error."

[bong-water-water-bong]

Found by the registry checks (#94, tools/registry_check.py, engine 8c2805d, Strix Halo). It reproduced on a second run.

tests/serve_e2e.sh build/1bit <model> hrx: the server comes up healthy, but the chat request returns HTTP 500 {"error":{"code":500,"message":"Compute error."}}.

Model	GGUF arch	hrx	vulkan
Qwen3-Coder-30B-A3B-Instruct Q4_K_M	qwen3moe	fails	pass
GLM-4.7-Flash Q4_K_M	deepseek2	fails	pass
Qwen3.6-35B-A3B Q8_0	qwen35moe	pass	pass

The wiki records Qwen3-Coder-30B-A3B decoding on HRX at 89.4 tok/s in llama-bench after #84. The serve chat path fails anyway. Both failing models are MoE and Q4_K_M, while the passing 35B is Q8_0.

🤖 Generated with Claude Code

[bong-water-water-bong]

Server log for Qwen3-Coder-30B-A3B on HRX (engine 8c2805d):

W resolve_fused_ops: layer 0 is assigned to device HRX0 but Flash Attention is assigned to device CPU (usually due to missing support)
W resolve_fused_ops: Flash Attention not supported, set to disabled
E graph_compute: ggml_backend_sched_graph_compute_async failed with error -1
E process_ubatch: failed to compute graph, compute status: -1
E srv        decode: Compute error. off = 0, n_batch = 2048, ret = -3

HRX0 doesn't claim flash attention for this model, so llama.cpp falls back to -fa off, and the first prompt batch then fails on HRX0. The wiki's HRX page already lists -fa off as still open. The fix has two parts: HRX0 claiming FA for these shapes, and the non-FA attention path working on HRX0.

[bong-water-water-bong]

More precise: the failing line just before the error is

E graph_compute: value alias target 45 is not transient

This comes from HRX's graph compiler rejecting a buffer alias, not from a kernel. It is the same area as the HRX0 fusion/aliasing issue we saw with batched prompts before. The server runs with n_slots = 4, kv_unified = true.

[bong-water-water-bong]

Qwen3-Coder-30B-A3B is fixed by #97: --device hrx now defaults the context to 32768, so HRX0 keeps flash attention.

GLM-4.7-Flash is still open:

1. Its 576-wide MLA heads are over HRX0's 512 flash-attention limit, so it always runs on the no-FA path.
2. fused_context_claim claims SUM_ROWS/CLAMP whenever the input comes from a GET_ROWS. GLM's router is sigmoid, not softmax, so the top-8 router dispatch can't run them: unsupported HRX node 0: SUM_ROWS. The tighter claim (require the softmax -> argsort -> get_rows chain) removes the error.
3. With (2) fixed, HRX0 answers wrong: "garbled input… _IRQn". It is wrong at -ngl 99 and at -ngl 0, deterministically, and no GGML_HRX_DEBUG_SERIAL_EXECUTION, DISABLE_GRAPH_REPLAY, FRESH_TRANSIENT_ARENA or DISABLE_QWEN_DISPATCH switch changes it. The same fork binary on CPU (--device none) and on Vulkan0 answers "Paris", and all 790 test-backend-ops cases pass on HRX0. So a fused pattern computes wrong on this graph.

(2) should only ship together with the fix for (3).

[bong-water-water-bong]

Root cause of the GLM-4.7-Flash wrong answer, found with a standalone MUL_MAT_ID probe on GLM's real expert weights: HRX's common MUL_MAT_ID ignored the route-id row stride.

llama.cpp's route ids are a [n_used, T] view of the [n_expert, T] argsort, but the dispatch built its routing tables with stride = n_used, so every token after the first used the wrong experts. The l2 error against the CPU was 1.36 with strided ids and 8e-3 with packed ids. Only batched prompts hit it (-ub 1/2/4 answered correctly), and Qwen models are unaffected because their router dispatch supplies the stride.

Fix: 1bit-MONSTER/llama.cpp#3 (branch fix/hr-95-mmid-route-stride). With it plus #101's router-claim change, all 7 HRX models pass serve_e2e, GLM included, and test-backend-ops is 790/790.

#103 in its current form breaks Qwen3-0.6B on hrx (value_stride=1024 outside the FA kernel's range); details are on #103.

To land all of this, the fork needs one pin commit containing #101's commit, llama.cpp#3, and a fixed #103, and then an engine bump to it.