[bong-water-water-bong]

Fixes #2150

What this does

Moves third_party/llama.cpp (and registry/architectures.json) from 9dd1a1b72 to 7a96fa179 on 1bit/hrx-vulkan-patched:

• hrx: the shortlist refine reads its exact logits back after a global barrier (engine #2150) llama.cpp#330: the draft head's logits step (mul_mat_q6_k shortlist, refine kernel) handed each exact logit from the workitem that computed it to the workitem that publishes it through global memory, behind a barrier that fenced shared memory only. Now and then a slot was published before the store reached it and carried what was there before: the coarse scan's score for that candidate, x64. Now a global-memory barrier. Adds mul_mat.q6_k.token1_shortlist.repeat (200 recomputes in one process).
• tests: Flash-Next routed experts at the file's 512 experts (engine #572) llama.cpp#329: tests only (Flash-Next routed experts at 512 experts, engine HRX: Qwen3.8-Flash-Next prefill is 287 tok/s on UD-IQ4_XS vs 1,679 for gufo on the same box (and 500-2,400 across published Strix Halo engines) #572).

docs/hrx.md: the #2150 sentence ("came back wrong once and did not recur") now says what it was, what fixed it, and the measurement.

Before / after (strixhalo, gfx1151, 2026-11-12, one gpu-hold ticket per batch, before/after alternated)

The same test binary run against two libraries: before = fork c762975a0 (this pin's parent tree plus #329), after = the #330 head ccb204c03, whose tree is identical to 7a96fa179 (git diff --stat ccb204c03 7a96fa179 is empty).

batch	before: wrong recomputes	after
4 processes x 1,999	318 (wrong value 1543.49 every time)	0
8 processes x 4,999	0	0
total	318 of 47,988	0 of 47,988

The wrong value is predicted, not just observed: a host re-implementation of the coarse score for that row gives 24.1202, and 64 x 24.1202 = 1543.69 against 1543.491 measured. The failures came in the busier batch (the two failing processes were the slow ones); the after processes ran interleaved with them and were clean.

Full test-hrx-ops on the same two libraries: 217 passed / 53 failed on both, the same 53 by name. That build has the HIP add-on (gpu-kernels pin fd69590c) enabled, which takes dispatches the suite expects on Loom kernels (missing expected kernel: loom_libs:...); those 53 are that, not this change. The suite without the add-on was not run for this PR.

🤖 Generated with Claude Code

[bong-water-water-bong]

ready for review at bcb836b

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 2150 - Partially compliant Compliant requirements: Fix for the wrong refined logit issue is implemented The fix is measured on the hardware with the specified conditions The barrier change is correctly implemented in the refine kernel The test case mul_mat.q6_k.token1_shortlist.repeat is added Non-compliant requirements: None Requires further human verification: None 572 - Partially compliant Compliant requirements: None Non-compliant requirements: The performance improvement goal is not addressed in this PR The Flash-Next prefill plan implementation is not included in this PR Requires further human verification: None 330 - Partially compliant Compliant requirements: None Non-compliant requirements: The PR only updates the llama.cpp commit and documentation, but does not map the uncovered architectures Requires further human verification: None

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Documentation Clarity The documentation change mentions that the test mul_mat.q6_k.token1_shortlist.repeat recomputes the case 200 times in one process, but the actual implementation details of this test are not visible in the diff. This could be confusing for someone trying to understand the test setup. refined logit came back wrong once ([engine#2150](https://github.com/1bit-MONSTER/engine/issues/2150)). That was a race, fixed at pin `7a96fa179` (llama.cpp #330): the refine kernel hands each exact logit to the workitem that publishes it through global memory, and the barrier between them fenced shared memory only, so a slot was now and then published before the store reached it and carried the coarse scan's score instead (1543.49, 64 times the coarse 24.12, where the exact logit is 29.15). The test `mul_mat.q6_k.token1_shortlist.repeat` recomputes the case 200 times in one process. Measured on gfx1151 (2026-11-12), 47,988 recomputes on each side: 318 wrong before, 0 after.

[bong-water-water-bong]

VERDICT: READY at bcb836b — Fixes #2150, the second of the window-ordered rows to close, and I verified the one thing a small pin bump can silently do.

The change

third_party/llama.cpp + registry/architectures.json: 9dd1a1b72 → 7a96fa179, carrying llama.cpp#330 — "the draft head's logits step (mul_mat_q6_k shortlist, refine kernel) handed each exact logit from the workitem that computed it". That is #2150's one wrong refined logit fixed at its source, and the pin brings its stress arm (HRX_OPS_SHORTLIST_REPEATS, 200 recomputes in one process) so the property is guarded at the next bump.

The check I ran, because a "+2 line" PR is not always a "+2 line" merge

merge-base..HEAD shows 13 files, not 2 — the branch forked before #2298/#2286 landed, so main's own changes appear as the branch's. That is the diffstat trap, and the question it raises for a pin bump is the one that matters: does the merge revert anything? Test merge on current main:

Automatic merge went well, 0 conflicts
docs/npu.md  engine#2215 = 1   (unchanged)
app/npu_answer_parser.h  harmony refs = 16   (unchanged)

Nothing reverted — so the extra files are base staleness, not the branch's doing, and the PR is exactly the pair of pin updates it claims.

One ask: say in the body that the visible diff will be larger than the change ("the diff shows other PRs' landed work because the branch base predates them; the change is the gitlink and the registry line"). For a two-line pin bump that sentence saves a reviewer the same five minutes of suspicion I just spent, and it is the same courtesy #2241's per-commit table provides.