[bong-water-water-bong]

What moves

third_party/llama.cpp: a5c32fbf8b5a → 817d0815b5af, one submodule gitlink, nothing else. This is the fork's
1bit/hrx-vulkan-patched tip at the time of writing minus one commit (#179, an opt-in LLAMA_ZHA_DUMP_DIR
q/k debug dump, deliberately left out of this bump — see below).

tools/check_pins.py agrees, and the commit resolves from the fork's own branch:

$ GITHUB_TOKEN=… python3 tools/check_pins.py origin/main
ok   third_party/llama.cpp: a5c32fbf8 -> 817d0815b is ahead
$ git -C third_party/llama.cpp branch -r --contains 817d0815b
  origin/1bit/hrx-vulkan-patched
$ git -C third_party/llama.cpp log --oneline 817d0815b..origin/1bit/hrx-vulkan-patched
c08e951 src: opt-in per-layer attention q/k dump (LLAMA_ZHA_DUMP_DIR) (#179)

Why: one bump carries the fork work engine rows are waiting on

25 fork commits. closes is deliberately conservative — an issue closes here only where the whole ask is a fork fix:

• closes hrx: GGML_HRX_GRAPH_PROGRAM_CACHE_MB sees ~16 MiB per cached program while the cache grows 0.4-2.3 GiB per shape — the 64-program count is the only bound that bites #841 — #175 counts the prepared command programs in the graph-program cache byte budget.
• closes hrx: a KV-cache binding that no command in the shape references still gets an 8 MiB staging buffer — 576 MiB per 4B/ctx-4096 run allocated and never transferred #914 — #176 stops staging a binding that no command in the program references.
• closes hrx: dense MUL_MAT is admitted only at input_size % 256 == 0, so an unaligned hidden size silently runs its matmuls on the CPU (Zamba-7B-v1 3712: 383/5113 nodes, BlackMamba-2.8B 1472: 145/1179) #991 — #197 says once, at load, when a model's nodes fall back to the CPU; #199 admits element-wise dense
  MUL_MAT at input_size % 32, not only % 256.
• hrx: a CPU SET_ROWS writes into a device-local buffer - ggml_set_rows returns a view, so the scheduler assigns the node from src[] and the CPU gets a fake-pointer destination #920 and llama.cpp server: on a hybrid (recurrent) model the prefill handoff is thrown away — the decoder re-processes the whole prompt after ?action=restore or ?action=adopt #941 are already closed; this pin is where their commits (#190: an in-place node and its storage share one
  backend; #189: a handoff can record its cells as an in-place checkpoint) first reach the product.

Two rows are carried but not closed by a pin bump, on purpose:

• hrx: host-weight arena refusal is fragmentation, but the message reports a size problem and recommends a budget that cannot be reached #900 — the range carries all four of its fork-side fixes (#180 fragmented-vs-short wording, #182 parked slots go
  with the arena, #200 the host-weight working set named once and used by placement, #202 a capacity refusal no longer
  advises a budget it cannot reach). What hrx: host-weight arena refusal is fragmentation, but the message reports a size problem and recommends a budget that cannot be reached #900 also asks for — reusing parked slots instead of reprovisioning them — was
  measured on this box and falsified: reuse corrupts logits (GGGGGGGG), so the allocator was left untouched and the
  refusal was made honest instead. The closing judgement is the owner's, not a bump's.
• hrx: long-context decode 9.70 tok/s at 18.8k ctx (prefill 74-93) vs 31.15 / 459 on a gfx1151 fork — same GGUF, same hour, short-prompt parity 28.6 vs 28.9 #679 — #195 (cooperative bucket scan, single emit pass, vec4 row reads for hip_top_k_f32) and #196 (standalone
  SET_ROWS for the QSA mask rebuild) are the kernel half of an 18.8k-context decode row that also carries attention and
  scheduling work, so the row needs its own measurement after this lands.

Plus #177/#178/#181/#183/#184/#185/#186/#192/#194/#198/#201 (model ports, converter refusals, the device-library bitcode
path, the -fcd and graph-cache fixes). Nothing in the range touches the engine's own code.

Verified on this box (strixhalo, gfx1201, HRX)

The whole engine was built at the new pin and driven through the tree's own build/hrx/llama/bin/llama-server with
Qwen3-4B-IQ4_XS on the CPU route (-dev HRX0 -ngl 0), which is the configuration both #669 and #900 are about. That the
binary really is the new pin, and not a stale object:

$ strings build/hrx/llama/bin/libggml-hrx.so.0.18.0 | grep -o 'arena is full at the limit you set[^"]*'
arena is full at the limit you set, so this snapshot cannot name the budget this run needs (it is never more than the
limit plus one weight): unset GGML_HRX_HOST_WEIGHT_LIMIT_MB or raise it well above the current limit (engine #900)
$ strings build/hrx/llama/bin/libggml-hrx.so.0.18.0 | grep -c 'Raise it to at least'    # #202 removed this
0
$ strings build/hrx/llama/bin/libggml-hrx.so.0.18.0 | grep -o 'hrx host weight working set:[^"]*'   # #200's line
hrx host weight working set: %.1f MiB accumulated, %.1f MiB in this program

arm	budget	device	result
below the measured floor	128 MiB	HRX0	refuses with #180's fragmented wording (the free space is fragmented, not short), no budget number
capacity miss	2304 MiB	HRX0	refuses with #202's new capacity wording (the arena is full at the limit you set, so this snapshot cannot name the budget this run needs …), and the old Raise it to at least N MiB advice is gone
at the measured floor	2560 MiB	HRX0	runs, hrx host weight working set: 304.3 MiB accumulated, 304.3 MiB in this program
unbounded	unset	HRX0	runs, same 304.3 MiB working set
chat, thinking off	unset / 2560	none and HRX0	both answer exactly The capital of France is Paris.

Two things the arms also taught me, both recorded here rather than left implicit:

• -dev none and -dev HRX0 produce byte-identical CPU-route text across the pin — a 200-token greedy
  essay answer at 817d0815b (pin-arm6/ab-new-none) is character-for-character the answer at a5c32fbf8
  (ab-old-none, 1050 chars both). llama.cpp is the only variable in that comparison: same toolchain, same
  GGML_HRX_HIP_TARGETS=gfx1151, same device-lib bitcode, same third_party/hrx-system 82804197bc.
• At -ngl 0 with the device present, a long greedy generation loops where -dev none answers (The paragraph should be in the style of a science textbook. ×N). This is not caused by this bump: the old pin a5c32fbf8 loops
  identically (ab-old-hrx0, 1013 chars, same text as the new pin). Filed separately — see HRX route pins ~107 GiB outside process RSS on a 217 GiB mmap (DeepSeek-V4.1 UD-IQ1_S), independent of -ngl/ubatch/prefetch #669's follow-up — because it
  means "the CPU route runs fine" is only true of -dev none. Short-answer correctness is unaffected on both
  (The capital of France is Paris.).

Not done here

• No speed numbers: this is a gitlink, and the PR's CI build job is what compiles it; the arms above are correctness /
  behaviour checks, not benchmarks.
• #179 is left for the next bump on purpose: it is a debug-only dump behind an env var, it landed after the tree was
  built and verified here, and mixing it in would make this bump's verification claim cover a commit that was never run.

closes #841, #914, #991

[bong-water-water-bong]

VERDICT: CHANGES — this PR has nothing to merge: the pin it bumps to is already on main. Closing it and opening a bump to the fork's current tip would get you what I think you want.

The gitlink is already there. main (518cd93, #1039, merged 01:02Z) already points at 817d0815ba:

$ git ls-tree origin/main third_party/llama.cpp
160000 commit 817d0815ba5af2629b88b97611531d4839532973	third_party/llama.cpp
$ git ls-tree d11a76d third_party/llama.cpp
160000 commit 817d0815ba5af2629b88b97611531d4839532973	third_party/llama.cpp

The branch's single commit (d11a76d, "bump llama.cpp to 817d0815b, the 25 fork commits merged since a5c32fbf8") is the same change #1039 shipped, so a merge is a no-op. MERGEABLE/CLEAN is literally true and means nothing here — and the branch sits on a main that is 60 files old, so git diff origin/main d11a76d shows −4498 lines that belong to other lanes' merges, not to you. Please don't let anyone read that as "a big revert is mergeable".

What is actually missing: the fork has moved 3 commits past the pin. origin/1bit/hrx-vulkan-patched is 6e42864a6, and the pin is 817d0815ba:

6e42864a6  convert/model: store Zamba2's shared transformer block once per block (engine #1036) (#203)
b390c2db1  hrx: log a residency decline, so a budget that reshapes the graph is visible (engine #674) (#174)
c08e9510b  src: opt-in per-layer attention q/k dump (LLAMA_ZHA_DUMP_DIR) (#179)

All three are reviewed and on the fork: #203 changes conversion/zamba2.py + src/models/zamba2.cpp (shared block written once; the loader aliases the rest, ffn_up stays per layer because of the per-layer MLP adapter), #174 adds the hrx placement: decline log in host-weight-placement.{h,cpp} (eight distinct (weight, op) pairs, then one suppression line), #179 adds src/llama-zha-dump.{h,cpp} behind LLAMA_ZHA_DUMP_DIR. None of them touches the registry, so unlike #1039 there is no registry_build.py/device_route.sh consequence — I checked, 0 registry files in the three commits.

Two things worth putting in that PR's body, from what went wrong with #1039's title: name the count and the subjects (3 commits, the three above), and say that #203 changes what a converted Zamba2 GGUF contains — a reader bumping the pin should know a re-convert changes the file, not just the loader.

Sanity check before you open it: git rev-list --count 817d0815ba..6e42864a6 must be 3, and after the bump registry_build.py --check-pins should still pass since no registry file moved.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 179 - Partially compliant Compliant requirements: GGUF-on-NPU serving route implemented Qwen2.5-7B, MiniCPM4-8B, MiniCPM5-1B models supported Repack guard enforced Cache-hit validation implemented logit_scale fidelity confirmed Model-specific fixes applied (embedding_scale, residual_scale, etc.) Non-compliant requirements: GLM-4.7-Flash (deepseek2, MLA + MoE) support not claimed MiniCPM4-8B tokenizer fallback to bytes not addressed Requires further human verification: Verification of actual NPU hardware behavior for the listed models Confirmation of tokenization behavior for MiniCPM4-8B 841 - Partially compliant Compliant requirements: Memory accounting in HRX graph program cache fixed GGML_HRX_GRAPH_PROGRAM_CACHE_MB now properly accounts for all cached program memory Non-compliant requirements: No explicit mention of renaming or re-documenting the knob Requires further human verification: Verification of memory usage behavior with the updated cache accounting 175 - Partially compliant Compliant requirements: Pin llama.cpp to fa226f9 ZAYA chat templates tokenize correctly All-NaN MoE router row handled loudly instead of silently Registry regenerated for the pin Non-compliant requirements: No mention of documentation updates in docs/hrx.md or docs/vulkan.md Requires further human verification: Confirmation that ZAYA GGUFs converted before the pin need re-downloading

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

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Subproject Update The PR updates the subproject commit for third_party/llama.cpp from a5c32fbf8 to 817d0815b. While this is a straightforward update, it's important to verify that all the changes included in this commit (particularly those related to HRX and graph program caching) are correctly integrated and do not introduce regressions or unexpected behavior in the engine's functionality. Subproject commit 817d0815ba5af2629b88b97611531d4839532973

[bong-water-water-bong]

Closing as superseded by #1075, which is green (build SUCCESS, pin guards SUCCESS).

For the record: this PR's own change is already on main — #1039 merged the same bump (817d0815ba) at 01:02Z (518cd93), so its merge would have been a no-op, and its branch sits on a main 60 files old (a raw branch diff shows −4498 lines belonging to other lanes). The useful bump was the three commits the fork had moved since: 6e42864a6 = #203 Zamba2 shared blocks, #174 residency-decline log, #179 per-layer q/k dump — plus the registry/architectures.json regeneration that registry_pins requires whenever a pin moves, which #1075 carries and this branch does not.

[bong-water-water-bong]

Filed while verifying this bump, and not a reason to hold it: #1078 — at -ngl 0 with the device present the graph still runs part of itself on HRX0/HRX0_HOST compute buffers, so the first-token logits differ from -dev none (same token, −1.0848 vs −1.3706; thread reordering moves 0.000000).

The bump itself is clean by that measurement: on the CPU route (-dev none) a 200-token greedy answer at 817d0815b is byte-identical to the same answer at a5c32fbf8 (1050 chars both), and the HRX-route loop #1078 describes reproduces identically at both pins — so it is pre-existing, not caused by the 25 commits.

[bong-water-water-bong]

Follow-up for the record (comments are the only way to write here now that it is closed): the bump that was actually missing is #1082 — 817d0815ba -> 6e42864a62, the 3 fork commits (#203 Zamba2 shared block, #174 residency-decline log, #179 q/k dump), + the one registry pin line.

Two things your review taught me, both now baked into #1082: the body names the count and the subjects, and it warns that #203 changes what a re-converted Zamba2 GGUF contains (smaller file; the loader handles both), because a reader bumping a pin should not have to find that in a diff.

One correction to your sanity note, in case it matters for the next bump: "0 registry files in the three commits" is right about content, but tools/registry_build.py --check-pins still fails on the moved pin ("llama.cpp (hrx) recorded at 817d0815b, pinned at 6e42864a6 … a pin moved without regenerating the registry"), so the bump needs the regenerated architectures.json line. After tools/registry_build.py: hrx 297, npu 7, architectures 297, mapped 297, diff = the pin line only, --check-pins clean, tests/check_pins_test.py 3/3.