Repository navigation
Bump HRX: llama.cpp 4a375bf2d36f + hrx-system 82804197bcbe - #1120
Conversation
bong-water-water-bong
left a comment
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: READY at e77f4348 — the bump is one commit, the hold is respected, and I ran the pin checks rather than reading the diff.
$ git ls-tree HEAD third_party/llama.cpp -> 4a375bf2d36f (the fork tip; #207, which I reviewed)
$ git ls-tree HEAD third_party/hrx-system -> 82804197bcbe060b1371d6548337fdc842034cdd
$ python3 tools/check_pins.py origin/main
ok third_party/llama.cpp: 391bad862 -> 4a375bf2d is ahead
$ python3 tools/registry_build.py --check-pins
registry/architectures.json records the committed pins
$ python3 tools/registry_build.py --check-gaps
none of the 28 reviewed significant classes is mapped without a reason
$ python3 tests/check_pins_test.py
Ran 3 tests — OK
hrx-system is held, not moved — gitlink 82804197bcbe0000 unchanged, exactly the pin config/hrx-system-hold.config names, while AMD's tested pair wants 558e5fe2e7af. That is the correct behaviour under the hold rule (a llama.cpp move needs no re-validation; an hrx-system move does), and it is the thing I check first on a bump whose title mentions both submodules.
The registry delta is the one pin line, check_pins agrees the move is forward, and the commit it carries (4a375bf2d = fork #207, batched dense MUL_MAT one dispatch per plane) is one I reviewed at the PR.
What the PR itself asks for and I cannot do: "CI here builds without HRX. Before merging, on Strix Halo run the long-prompt correctness probe and test-backend-ops -b HRX0." That is the same gap as #1104 and my own #1075 — GGML_HRX is off in ci.yml, so no PR-time job compiles ggml/src/ggml-hrx (engine #1077). This bump inherits it; the hw-gate label is the mechanism that exists. GPU and NPU tokens have been held all night, so those rows are not mine to add here.
The device half of this bump, checked as far as the box allows — and one thing already confirmed so the merger does not have to touch itNo verdict here, just the two things the body asks for, one of which is already satisfied. 1. So the only substantive delta is the llama.cpp gitlink ( 2. The gate run itself is queued behind box capacity, not behind this PR. I set up the exact tree ( Two things a merger should know before deciding to wait or not:
I will post the gate's result on this PR when the runner actually gets capacity (it expires after 3 h and will report that instead of hanging). |
…te from #973, and the two traps (#1357) * docs: an adapter (LoRA) page — the lifecycle, the in-place factor write from #973, and the two traps The engine carries no adapter code of its own, so everything about LoRA lives in three lines of llama-adapter.cpp and in facts that have now been re-derived three times (engine#433, #528, #973). This page is the place those facts live instead: - the lifecycle: init (per-model-buft device tensors, keyed by base tensor name), set_adapters_lora, free — with the load line that names the device buffer, because "the factor fell back to CPU" was a real hypothesis once and the log refutes it; - changing a live adapter's factors in place (llama_adapter_lora_set_factors, _multi, and the enumeration helpers), with the measured cost of both paths at bank widths RT 2 and RT 26, and what cannot change in place (rank, alpha) and why; - trap 1: on HRX a zero-factor adapter is not a bit-exact no-op, the offset is per-pin and changes sign (+0.34 % on a5271d9, -0.08 % on 4a375bf2d, Vulkan bit-exact), so adapter-on vs adapter-off loss comparisons must use the zero row of the same build; - trap 2: the factors are the model tensor's buffer type, so ggml_backend_tensor_set is the right primitive and a host copy is written into nothing; - how to check you did not move the forward path: a fixed-prompt known-answer probe with per-build reference rows, which is what caught the #1120 pin moving the HRX base loss by +0.086 %. Numbers are the ones engine#973 measured on this box; nothing here is an estimate. Refs engine#973 (closed as fixed; the API shipped in the pin before this page existed). * docs/lora: name the pin the API and flags were checked at, and the command that re-checks them Review suggestion on #1357: the entry points and flags were quoted without a pin, on a page whose own Trap 1 warns that a conclusion can be a property of a pin. Now named: `third_party/llama.cpp` = `ed43da0b4` (engine main's pin when written), with the line numbers, the fork commit that introduced the factor write (`c729177bc`), and the two greps that re-check a bumped pin instead of a prose claim to trust. Refs #973, #1357. --------- Co-authored-by: bong-water-water-bong <bong-water-water-bong@1bit.gg>
Moves the HRX submodules along our line. AMD's tested pair (ROCm/ggml-staging-automation) is llama.cpp
44ee5710d19f+ hrx-system558e5fe2e7af; the workflow merges it into our branches (a conflict fails the run and names the files).391bad862a404a375bf2d36f82804197bcbe82804197bcbehrx-system HELD at
82804197bcbebyconfig/hrx-system-hold.config(AMD's tested pin is558e5fe2e7af).llama.cpp commits new to the engine:
4a375bf2dhrx: run a batched dense MUL_MAT as one dispatch per plane (engine 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) (docs/serve.md: link the published Qwen3-Coder-30B-A3B Q4_0-H32 #207)CI here builds without HRX. Before merging, on Strix Halo run the long-prompt correctness
probe and
test-backend-ops -b HRX0; record the exact validated hrx-system pin inconfig/hrx-long-prompt-validated-pin.config:python3 tests/hrx_long_prompt.pycmake -B build -G Ninja -DONEBIT_HRX=ON && cmake --build build --target onebit && for d in hrx cpu; do tests/serve_e2e.sh build/1bit <Qwen3-0.6B Q4_K_M .gguf> $d; done