[bong-water-water-bong]

What moves

third_party/llama.cpp: 817d0815ba5a → 6e42864a628a — 3 commits, the fork's 1bit/hrx-vulkan-patched tip
(#1039 already shipped 817d0815ba on main, which is why this is 3 and not 28), plus the one line that records the pin
in registry/architectures.json. Nothing else:

commit	what it does
6e42864a6 #203	convert/model: store Zamba2's shared transformer block once per block (engine #1036); the loader aliases the rest, ffn_up stays per layer because of the per-layer MLP adapter
b390c2db1 #174	hrx: log a residency decline, so a budget that reshapes the graph is visible (engine #674) — eight distinct (weight, op) pairs, then one suppression line
c08e9510b #179	src: opt-in per-layer attention q/k dump behind LLAMA_ZHA_DUMP_DIR (debug only, no default-path change)

$ git rev-list --count 817d0815ba..6e42864a6
3
$ tools/check_pins.py origin/main
ok   third_party/llama.cpp: 817d0815b -> 6e42864a6 is ahead

Read this before bumping: #203 changes what a converted Zamba2 GGUF contains

Not just what the loader does. A Zamba2 converted at the old pin writes the shared attention block once per hybrid layer
(2 distinct sets × 13); after #203 a re-convert writes it once and aliases. An existing Zamba2 GGUF still loads (the
loader handles both), but the file a re-convert produces is different, and it is smaller. Nothing about this affects
Qwen/DeepSeek/Zaya paths.

Registry

No registry content moves in the three commits — checked, not assumed — but the recorded pin does, so it is regenerated in
this PR:

$ python3 tools/registry_build.py
wrote registry/architectures.json: hrx 297, npu 7, architectures 297, mapped 297
$ python3 tools/registry_build.py --check-pins
/home/bcloud/wt/i669-engine/registry/architectures.json records the committed pins
$ python3 tests/check_pins_test.py
Ran 3 tests in 0.000s — OK

The diff is one line ("llama.cpp (hrx)": "817d0815ba…" -> "6e42864a62…"); the 297 architecture rows are unchanged, which is
the same evidence as the reviewer's "0 registry files in the three commits".

Verified on this box (strixhalo, gfx1201)

The engine was built at the new pin and the numbers that identified 817d0815b last night were re-taken, so this is a
"nothing moved" check, not a fresh claim:

check	at 817d0815b (last night)	at 6e42864a6 (this PR)
first-token logprob, -dev none	−1.084810 (" The")	−1.084810
first-token logprob, -dev HRX0	−1.370574 (" The")	−1.370574
chat answer, thinking off	The capital of France is Paris.	same text
2304 MiB	#202's capacity refusal	same wording
128 MiB	#180's fragmented refusal	same wording
#174's decline log	not in the tree	both strings present in libggml-hrx.so

Engine built at the new pin under thermal-run.sh 4: 39/39 targets, no errors. Provenance read out of the freshly linked
objects rather than assumed — and this is a trap for the next lane: the build writes libllama.so.0.0.50 while the
previous pin's 0.0.47 is still in bin/, so grepping the old file says "#179 is missing" when it is not.

libllama.so.0.0.50   (03:20, the symlink target) contains "LLAMA_ZHA_DUMP_DIR"        -> #179
libggml-hrx.so       (03:20) contains "hrx placement: %s is not run on HRX ..."       -> #174
third_party/llama.cpp is 6e42864 (zamba2 shared-block code present)                   -> #203

The two logit numbers being identical to six decimals across the bump is the strongest "nothing moved" statement
available here: the same prompt, the same two routes, the same two numbers, three reviewed commits later.

Not done here

• No speed numbers — a gitlink bump is compiled by the PR's CI build job; the arms above are behaviour checks.
• engine zamba2: shared attention block stored once per hybrid layer (2 distinct sets written 13x) — 7B BF16 is 22.0 GB where the checkpoint is 14.8 GB #1036 (Zamba2 shared block stored once per hybrid layer) is the row #203 fixes, but it needs a convert + load
  of a Zamba2 7B to close, which is a model run I did not do here. Say the word and it is a 20-minute job on this box.
• engine hrx: any graph whose weight ops all run on the CPU computes garbage (1 s reproducer) #674's decline log is a log; it makes the reshaped-graph case visible, it does not change placement.

Refs #1036, #674.

[bong-water-water-bong]

VERDICT: READY on content — but this is byte-identical to #1075 and one of the two must be closed. Trees match exactly:

$ git diff bump/llama-pin-6e42864a6 <this head> --stat      ->  (empty)
third_party/llama.cpp       160000 commit 6e42864a628af8e97bc13b8e3ddb3dc7a72fc6d4   (same in both)
registry/architectures.json "llama.cpp (hrx)": "6e42864a628af..."                    (same in both)

I opened #1075 while reviewing #1073 (its replacement rule) at the same time this lane produced this one, so both did the same correct thing: the gitlink to the fork tip and the registry/architectures.json line that registry_pins requires, with the three commits — #203 Zamba2 shared block, #174 decline log, #179 q/k dump — none of which touches registry/, so no architecture count changes (hrx 297, npu 7, architectures 297, mapped 297, checked).

The only difference between the two PRs is the evidence attached, and it is not symmetric:

	#1075 (mine)	#1082 (this)
content	identical	identical
ci.yml build	SUCCESS	pending
pin guards (hrx-system gitlink agrees…, pinned loom-jit.cpp compiles…)	SUCCESS	pending
hw-gate	ran: build PASS 184s (the HRX compile), ops 1959/1959, kat/needle/placement/kld green on 0.6B and zaya1-8b; 27B row refused by the memory pre-check (gate exit 2 = infrastructure, not this change)	not run

So my recommendation, in the terms that matter for the release: merge whichever you prefer, but if it is this one, label it hw-gate and let the build phase run — otherwise the HRX half of the bump ships unverified, which is exactly issue #1077 (the previous pin bump, #1039, shipped with hw_gate: SKIPPED). The HRX compile is the only check a pin bump cannot get from ci.yml.

If this one is the canonical PR, say so and I will close #1075 in favour of it — I would rather one PR with the evidence than two with half each. If #1075 is kept, this one can close; the content is not in question either way.

Not verified on this PR beyond the tree comparison: I took no GPU/NPU ticket for it, and my gate run belongs to #1075's branch.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 1039 - Partially compliant Compliant requirements: Bump third_party/llama.cpp from a5c32fbf8b to 817d0815ba Update registry/architectures.json to reflect the new pin Include Zamba2, Zamba v1, and BlackMamba architectures in the registry Ensure the registry records the committed pins Non-compliant requirements: None Requires further human verification: None 203 - Partially compliant Compliant requirements: None Non-compliant requirements: Implementation of --long-model feature and related routing logic not visible in diff Tests for routing behavior not visible in diff Requires further human verification: None 1036 - Partially compliant Compliant requirements: Fix Zamba2 shared attention block duplication issue Ensure shared attention block is stored once per block instead of once per hybrid layer Maintain compatibility with existing Zamba2 GGUF files Ensure re-converted Zamba2 GGUF files are smaller Non-compliant requirements: None Requires further human verification: None

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

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Subproject Commit Update The subproject commit for third_party/llama.cpp has been updated from 817d0815ba5af2629b88b97611531d4839532973 to 6e42864a628af8e97bc13b8e3ddb3dc7a72fc6d4. This update includes changes related to Zamba2 shared block handling, residency decline logging, and per-layer attention q/k dumping. Ensure that these changes are correctly integrated and do not introduce any regressions. Subproject commit 6e42864a628af8e97bc13b8e3ddb3dc7a72fc6d4 Registry Pin Update The registry pin for llama.cpp (hrx) has been updated to 6e42864a628af8e97bc13b8e3ddb3dc7a72fc6d4. This update aligns with the new third_party/llama.cpp commit and ensures that the architecture registry reflects the correct pinned commit. Verify that this change is consistent with the intended bump and that all architectures are correctly mapped. "llama.cpp (hrx)": "6e42864a628af8e97bc13b8e3ddb3dc7a72fc6d4"

[bong-water-water-bong]

Closing in favour of #1075, per the review: the two trees are identical, and #1075 carries the evidence this one cannot — the hw-gate run (build PASS 184s, ops 1959/1959, kat/needle/placement/kld on 0.6B and zaya1-8b). One PR with the HRX compile verified beats two with half each.

This lane's record of the same bump, for whoever reads the history: the numbers that identified 817d0815b come back identical at 6e42864a6 (first-token logprob −1.084810 on -dev none, −1.370574 on -dev HRX0, The capital of France is Paris., #202 capacity wording at 2304 MiB, #180 fragmented wording at 128 MiB, #174's two decline strings present), and tools/registry_build.py --check-pins needs the regenerated architectures.json line — the pin moved, the 297 rows are unchanged. No merge from me either way.