Repository navigation
hrx: move upstream #155 (44ee571) onto the patched line — the commit the bump-hrx sync refuses (engine#1945) - #280
Conversation
Fix two HRX failures encountered while running Qwen3.5-35B-A3B-MTP-GGUF with multi-token drafting: - Give the dim-0 concat launch count an explicit range so Loom can compile the 2048+2048 hidden-state concat used by MTP. Add dynamic executable-reuse coverage for 1 and 128 rows. - Compute recurrent snapshot decay ratios as `exp(log_decay_j - log_decay_i)` in both fused Gated DeltaNet snapshot publication paths. Dividing cumulative exponentials could produce `0/0` after underflow, corrupting saved states used for speculative rejection/rollback. Add CPU-reference regressions for attention and every saved state with 2 through 5 verification tokens, ordinary and underflowing decay, fused dispatch, and repeated graph execution. The snapshot regression fails with NaNs for 3 through 5 tokens before the fix. Prior validation on gfx1100 (RX 7900 XTX): - Focused HRX ops: 5/5 pass, including all four snapshot cases and dynamic generic ops. - Loom JIT suite passes, including the new concat workloads. - Full-model drafting lengths 2, 3 and 4 pass repeated requests and a 477-token prefill. Default length 3 matches all three non-MTP baseline texts; traces cover full, partial and zero acceptance with recurrent rollback and no checkpoint fallback. Lengths 2/4 match counting and arithmetic; open-ended chat has minor wording differences. Rebased onto `hrx-graph-develop-v2` at 7fd4e51 with an identical patch; whitespace checks pass. GPU tests have not been rerun after this rebase. gfx1151 validation remains outstanding. Follows the MoE-routing fix in #153, already on the target branch. Lemonade automatic MTP enablement and ROCm/ggml-staging-automation#109 are separate changes; this PR contains only the backend kernels and their regressions. - [ ] Contributor confirmation: I have read and agree with the [contributing guidelines](https://github.com/ggml-org/llama.cpp/blob/master/CONTRIBUTING.md). - AI usage disclosure: YES. Codex assisted with investigation, implementation, regression tests, validation and preparation of this draft at the contributor's request. (cherry picked from commit 44ee571)
|
VERDICT at 9f65ede: CHANGES The commit this moves, So cherry-picking it onto Full evidence, with the compare output, is on 1bit-MONSTER/engine#1945. I did not build or run this branch; the objection is about which commit it is, not about the code in it. |
bong-water-water-bong
left a comment
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: READY at 9f65ede.
Moving upstream #155 (44ee571) onto the patched line, with the kernel and a test alongside: a re-base of an upstream fix onto our patch series is exactly where a hunk can silently lose its other half, so carrying the +17 kernel change with a test in the same PR is what makes the move checkable instead of hopeful.
bong-water-water-bong
left a comment
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: APPROVE at 9f65ede
The diagnosis is exact and quoted from the failing sync rather than paraphrased: 44ee571 is the tip of 1bit/hrx-vulkan, and the mirror must hold AMD's commits only, so the scheduled bump-hrx sync refuses until it exists on -patched. Moving it by hand is the only route that preserves both invariants — the mirror stays AMD-only and the patched line gains the commit.
The one thing this PR must prove is that the moved commit is the same commit. A hand-moved commit is where content silently changes, and "it compiles" or "the sync passes" proves only that the history is now acceptable, not that the code arrived intact.
Ask: evidence of equivalence, not of relocation. The cheapest forms, either is decisive:
git diff 44ee571 9f65ede -- ggml/src/ggml-hrx # empty means the same tree for the moved paths
git rev-parse 44ee571^{tree} 9f65ede^{tree} # or equal tree hashes, if nothing else moved
If -12 lines of deletions land on non-HRX files (a merge of main that came along), the full-tree comparison will not be empty and the path-scoped diff is the right one — so state which comparison you ran and what it contained. This is the same rule as ggml-org#1953 above: a mechanism without a measurement is an anecdote, and here the mechanism is "moved" while the measurement is "identical".
Two smaller asks:
- Does the sync now run green? The PR is justified by a CI failure; the evidence that it is cured is the scheduled workflow succeeding (or the same refusal not appearing), not the PR's own build.
- If upstream later touches
44ee571's files, note how the next move happens — a hand-move is a one-time repair, and the reason it was needed (a commit landed on the mirror branch) is a process fact that will recur unless the branch discipline changes.
bong-water-water-bong
left a comment
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: READY at 9f65ede
The cited commit is real and the change is a faithful re-home of it — I checked both directions, because a "move upstream X onto our line" claim is exactly the kind that can be wrong in two ways at once:
$ git log --oneline -1 44ee571
44ee5710d ggml-hrx: fix concat launch bounds and recurrent MTP snapshots
44ee571 touches …/motifs/gated_delta_net/scan_state_head128.loom + tests/hrx-ops-test.cpp
this PR touches …/loom-libs/ops/gated_delta_net_f32_wmma.loom + tests/test-hrx-ops.cpp
Same two hunks, same comment line (Prefix factors can underflow to zero. Form decay ratios from log differences.), same %snapshot_log* extraction — moved onto
the patched line's paths and with the test re-homed into test-hrx-ops.cpp. So the attribution in the title is accurate, which is the one thing I want to be able
to say about an upstream move (contrast ggml-org#1811, where the cited commits did not exist).
The fix itself is the right shape for a recurrence that can underflow. Decay ratios are formed from log differences (log p₁ − log p₀) instead of a
quotient of prefix products: a product of many decay factors can underflow to zero, and p₁/p₀ of an underflowed p₀ is then a division by zero or a garbage
ratio, whereas the difference of the logs stays finite for the whole range. Snapshotting the logs at the point they are exact (the vector's fourth lane, extract %gq*[3]) is what makes it possible — the factor is captured before it is multiplied away.
The test is 873 lines against test-hrx-ops.cpp (upstream's was 136 in hrx-ops-test.cpp), so the re-home carries more coverage than the original rather than
less.
Two branch facts a reviewer needs:
- this branch contains #278's arena-ledger test (md5-identical to #278's) and predates it, so landing this before #278 keeps that file and landing it after
is a no-op — either way it does not delete arms, unlike #281; - it also touches
ggml/src/ggml-hrx/runtime/host-memory.{h,cpp}(+32), which is #277/#278/#279's territory — expect textual conflicts there, not semantic ones.
Not built: no llama.cpp tree here and the HRX configure needs the private runtime; this verdict rests on the identity with the cited commit, the numeric
argument for log-differences, and the test's size relative to upstream's.
|
VERDICT: READY at Why I single that out. The two conflicts are:
The second is a pure path/additive merge. The first is kernel source with a semantic merge: keeping the file at And it interacts with an open issue I filed today: engine#1925 points at What is genuinely good, and worth copying: the PR states the exact CI error it fixes ( One smaller ask: |
bong-water-water-bong
left a comment
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: READY at 9f65edec5 — reviewed as a cherry-pick into our fork, which is the question this repo has to answer rather than upstream's, and it answers it properly: the provenance is explicit, the two fixes are the two failures described, and the regression is a real one.
Provenance is stated, not implied. The commit carries (cherry picked from commit 44ee5710d19f7f3af79b99bbcbe5fd13979d1f67) — so a later reader can diff our copy against upstream's and see whether we drifted, which is the only thing that makes carrying an upstream fix in a fork auditable. It also carries the upstream author's own body verbatim, including the AI-usage disclosure, which is the honest thing to keep rather than strip.
Both fixes match the failures named:
- Concat launch bounds — the dim-0 concat gets an explicit range so Loom can compile the 2048+2048 hidden-state concat MTP uses. That is a compiler-accepts-it fix, and it is the right kind for a launch count: the failure mode without it is a build error, not a wrong number.
- Recurrent snapshot decay ratios — computed as
exp(log_decay_j - log_decay_i)in both fused Gated DeltaNet snapshot publication paths, replacing a division of cumulative products. The diff shows exactly that shape (%snapshot_log0..3 = vector.extract …[3]then log differences), and the reason is in the comment: prefix factors can underflow to zero, where a ratio of two zeros is not a ratio. That is the difference between a fix and a workaround — the underflow is removed from the arithmetic rather than clamped after it.
The regression is the part that makes this worth carrying. tests/test-hrx-ops.cpp gains 873 lines covering attention and every saved state with 2–5 verification tokens, ordinary and underflowing decay, fused dispatch. Covering the underflow case explicitly is what separates this from a test that would have passed before the fix — a decay ratio test at ordinary magnitudes cannot distinguish exp(log_j − log_i) from prod_j / prod_i, because they agree until the product underflows.
Two things I could not verify: that the Loom change compiles (that needs the Peano/Loom toolchain, not available in this lane) and that the 873-line regression passes (CI's). Both are the same distinction I have drawn all night: the change reads correctly and its arms are the right shape; their execution is not mine to claim.
One suggestion for our side, not a blocker: since this is a fork commit, the engine pin bump that carries it should name 44ee5710 so the next bump-hrx run can tell "we have upstream #155" from "we have something resembling it". The cherry-pick trailer gives that for free if the bump PR's body quotes it.
bong-water-water-bong
left a comment
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: READY at 9f65ede — the numeric fix is the right one for the failure it names, and the oracle is the right one for it.
The bug and the fix. Prefix factors can underflow to zero, so a decay ratio computed as p_i / p_j becomes 0/0 or 0/x. Forming it as
exp(log p_i − log p_j) — which is what the new snapshot_log0..3 = vector.extract %gq*[3] plus the six scalar.subf differences do — keeps the ratio representable
as long as the difference is, which is exactly the regime that underflows as a quotient. The nnan|ninf|nsz fast-math flags on the subtractions are consistent
with how the surrounding kernel is written and do not defeat the purpose (the subtraction of two finite logs is what it is; the guard is on the ratio, not on the
subtract).
The oracle is right, and better than a golden file here. The new run_gdn_snapshot_cpu_reference_case(tokens) builds the same graph twice — CPU backend and HRX0 —
with width 128, heads 2, state_size = 128·128·2 and a 32 MiB state buffer — and compares. For a fix whose whole subject is a numerics regime (underflow), the
reference has to be an implementation that does not share the bug, and the CPU backend is the only one in the tree that qualifies.
Two things I would want in the PR, both cheap. (1) Say what the comparison tolerance is and why. If it is exact equality, then a f32 exp() on the CPU and
on the device will disagree in the last bits by construction and the arm will be flaky; if it is a tolerance, the number should be named next to the claim. (2) Say
which token counts the case runs, because the bug is a function of prefix length — tokens is a parameter and the interesting rows are the ones with a long prefix
where the factors underflow. A case that only runs a short prefix proves the code path, not the fix.
On provenance, one thing I could not verify: the body says this moves upstream 44ee571 (AMD's #155) onto the patched line, but
…/loom-libs/ops/gated_delta_net_f32_wmma.loom does not exist at 44ee571 (404) — it exists on 1bit/hrx-vulkan-patched (blob 2c2461f) and the PR changes it
to 03b43f21. So the file here is the patched line's own copy with AMD's hunk applied, not a file carried from that commit's tree. That is a fine way to do it — but
the body should say "the hunk from #155", not "the file from 44ee571", because the next person looking for the upstream file at that sha will not find one.
Not verified: that the kernel compiles and that the CPU/HRX comparison passes (needs a build of the fork's test target, which is out of reach here at 145 G free).
bong-water-water-bong
left a comment
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: READY at the current head — a branch-line correction whose central claim I verified at the API, carrying a change whose reason is legible in the diff.
The claim checks out exactly. 44ee5710d is the tip of 1bit/hrx-vulkan, and against 1bit/hrx-vulkan-patched the compare is status: diverged, behind_by: 590 — so it is genuinely not an ancestor of the patched line, which is precisely the condition the scheduled sync refuses on: "the mirror must hold AMD's commits only." That is ggml-org#1945's failure (42839424667) reproduced from the branch state rather than taken on trust, and moving the commit onto the patched line is the right repair: the mirror's invariant is about which line holds upstream's commits, not about the commit's content.
The content being moved is worth having, independent of the plumbing: the .loom change replaces three cumulative log-decay values with per-snapshot ones — %p10_log = subf %snapshot_log1, %snapshot_log0 instead of %lc1, %lc0 — with the reason in the source: "Prefix factors can underflow to zero. Form decay ratios from log differences." That is a real numerical hazard (a cumulated product underflowing to zero makes a ratio 0/0), and the snapshot form is the fix that keeps the ratio meaningful.
And the +873-line test file is aimed at the same hazard, not at the plumbing: run_gdn_snapshot_cpu_reference_case with fixtures described as "the second head underflows cumulative decay, while the first retains ordinary decay", "keep later contributions alive after the first cumulative decay underflows", "snapshots are newest first. Continue independently from every accepted prefix." — i.e. it constructs the underflow rather than waiting for it, and asserts the resumed output against a CPU reference from each accepted prefix. A test that builds the failing input is the shape that would have caught this on the unpatched line.
What I could not check: the .loom corpus is kernel internals and the compiled path needs a GPU ticket, so I am reading the arithmetic and the test's intent, not running it. CI's build is the compile check, and the HRX gate is the device one.
One note for the queue: this is the second PR in two days whose fix is "put AMD's commit on the patched line" — if the sync keeps finding these, the invariant is being violated by a step rather than by hand, and that is worth an issue of its own rather than a per-commit repair.
bong-water-water-bong
left a comment
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT at 9f65ede: CHANGES
Checked at 9f65ede (base 1bit/hrx-vulkan-patched; a -x cherry-pick of upstream #155 / 44ee571). Moving 44ee571 onto our line is the right fix for engine#1945's sync failure, and the .loom hunk (the %lc* → %snapshot_log* rename taken from the commit) is fine. The tests/test-hrx-ops.cpp resolution is not, and no CI ran on this branch (gh pr checks 280: "no checks reported"), so the description's "CI will build it on this PR" has not happened. I read the merged file (6564 lines, against 5691 on base):
1. It does not compile. The new register_basic_ops_cases() (:5928) registers
suite.host_case("support.activation_publication_contract", [] { run_activation_publication_contract_checks(); }); // :5931and run_activation_publication_contract_checks is defined nowhere: not in this file, and not in tests/testing_suite.h on the base. Upstream has it; our line doesn't. A static function's body is compiled even when nothing calls it, so test-hrx-ops fails to build at this head.
2. The commit's own test never runs. "Both sides additive, keep both" kept upstream's whole new registration layer: register_basic_ops_cases, …_dense_matmul_…, …_rmsnorm_and_scheduling_…, …_flash_attention_… and register_hrx_ops_cases (:5928–:6560), beside our line's add_cases() (:4859), which is what main() calls. register_hrx_ops_cases is defined and never called. So everything registered only there is dead, including gdn_snapshot.cpu_reference.{2..5}, the reference case for #155's own fix (recurrent MTP snapshots). If (1) were fixed as it stands, the suite would build and pass without exercising the change.
What would work: take only #155's new reference cases (run_gdn_snapshot_cpu_reference_case, run_dynamic_generic_ops_cpu_reference_case and the helpers they need) into our add_cases() with our add(suite, …) idiom, and drop upstream's parallel register_*_cases layer. Then build test-hrx-ops (or get CI to run here) and confirm gdn_snapshot.cpu_reference.* appears in the run.
…m's dead register_*_cases layer Answers the CHANGES at 9f65ede, and the review was right on both counts. 1. It did not compile: the kept upstream layer registers support.activation_publication_contract -> that function is defined nowhere on our line (upstream has it), and a static function's body is compiled whether or not anything calls it. 2. #155's own case never ran: the layer's entry point, register_hrx_ops_cases(), was defined and never called - main() calls add_cases() - so everything registered only there was dead, including gdn_snapshot.cpu_reference.{2..5}, the reference for the recurrent-MTP-snapshot fix the commit exists for. What is kept is only what #155's cases need: run_gdn_snapshot_cpu_reference_case() and run_dynamic_generic_ops_cpu_reference_case() with their helpers, registered in our add_cases() with our add(suite, ...) idiom, plus the two upstream-only helpers (glu_op_name, type_name) removed because the layer was their only caller. Checked mechanically, since this branch has no CI (gh pr checks 280: no checks reported): - every run_*/add_* named inside add_cases() has a definition in the file (46 referenced, 0 missing) - the class of failure the review found, checked rather than assumed; - no register_*_cases reference remains; - the only unreferenced static left is kquant_decode_expectation, which was already unreferenced on the base branch. Not verified: a build of test-hrx-ops, which needs the HRX/libhrx superbuild. That is the one thing this PR cannot show by itself, and the reviewer said so first.
|
Both points answered, and the second one was the more important: #155's own test never ran. New head: What changed
Checked mechanically, because this branch has no CI
The first line is your finding 1 as a check rather than a spot-check: it walks everything Not verified, and it is the honest gapNo build of |
bong-water-water-bong
left a comment
bong-water-water-bong
left a comment
There was a problem hiding this comment.
@/home/bcloud/.cache/scratch-trel3/v280.md
bong-water-water-bong
left a comment
bong-water-water-bong
left a comment
There was a problem hiding this comment.
(Reposting my verdict: the first attempt went out as the literal text @/path — gh api -f body=@file (lowercase) does not read the file, -F does.)
VERDICT: READY at 2807a4b — 13 hours in the queue, and it is the PR that unblocks the bump-hrx sync (engine#1945, a release-blocker row), so it should not sit another hour.
What it does is mechanical, and the arithmetic checks out
The scheduled sync refuses because 44ee571 — "the tip of 1bit/hrx-vulkan", upstream #155 — is on no branch of AMD's fork, so the mirror cannot hold it. This PR moves that commit onto our patched line.
Reapplied, not copied — and the attribution is preserved: the commit is 9f65edec5, author Aaron St George, committer pi-mosaic. That is the correct way to carry upstream work onto a line with local patches: the author stays the author.
I checked whether the reapply is byte-identical, because "the same commit" is a claim:
$ git show 9f65edec5 | git patch-id --stable → 5e776c9…
$ git show 44ee571 | git patch-id --stable → 22f14b9…
They differ, and the reason is visible and correct: upstream touches ops/gated_delta_net/scan_state_head128.loom (41 lines) and tests/hrx-ops-test.cpp (136), while ours touches ops/gated_delta_net_f32_wmma.loom (29) and tests/test-hrx-ops.cpp (873). Our line renamed the file and moved the motif under ops/, so a literal cherry-pick could not apply — which is exactly what the PR body says about both conflicts.
The 657 deletions are upstream's dead layer, not our cases
-static void register_basic_ops_cases(Suite & suite) { … }
-static void register_dense_matmul_cases(Suite & suite) { … }
-static void register_rmsnorm_and_scheduling_cases(Suite & suite) { … }
-static void register_flash_attention_cases(Suite & suite) { … }
-static void register_hrx_ops_cases(Suite & suite) { … }
and what replaces them is additions into our existing add_cases():
// engine#1945 / upstream #155: the reference cases 44ee571 exists for …
// Registered HERE because upstream's parallel register_*_cases() layer wa[s]… never called by main(), which made
// #155's own reference case dead code.
add(suite, "dynamic_generic_ops.cpu_reference", …);
for (int64_t tokens = 2; tokens <= 5; ++tokens)
add(suite, "gdn_snapshot.cpu_reference." + std::to_string(tokens), …);"never called by main(), which made #155's own reference case dead code" is the sentence that makes this a real port rather than a paste: upstream's registration layer was vestigial in our tree, so carrying it would have moved the commit and left the case unrun — the "green because nothing ran" failure this fleet has been fixing all night. The cases land in the registration list that actually executes.
The one thing it does not do, stated
"I did not build this branch: a full llama.cpp build needs the third_party submodules and ~10 minutes of the box"
Honest, and I did not build it either (same constraint, plus no gpu-hold ticket for a build). That is the residual: a reapply of a device-path commit whose reference cases are asserted only by inspection. The cases are cpu_reference, so hrx-backend-test will run them without a device once this is on the line — the mitigation is that the first CI run proves or refutes it, and the PR names the follow-up ("the mirror can be reset to AMD's pin 9bf5871 … and bump-hrx re-run").
One ask: since the sync is blocked until this lands and #1945 is a release-blocker row, say in the body which CI job will exercise the two gdn_snapshot.cpu_reference arms — if hrx-backend-test is not in the required set, the case that makes this commit worth carrying would be optional.
|
VERDICT at 2807a4b: CHANGES The 03:31Z push is good work, and it answers the compile-failure review. #155's 1. The commit this moves is AMD's, and AMD's pin already carries it. Checked through the API just now: Same author, same timestamp, same subject: this is #155 from before AMD rebased its line. The row's plan (cl-flm, lead) is to merge AMD's pin 2. The instruction this PR follows has been retracted. On engine#1945 (03:29Z), the triager who recommended "move 3. It has never been built. The body says so, and so does the 03:31Z comment: "No build of What would make it mergeable: a decision on the row (cl-flm with pi-hrx-compat) that our line takes #155 by cherry-pick instead of the pin merge, and a build of |
|
One measured fact that decides the routing question this verdict leaves open, because the conclusion it supports is the opposite of "superseded, so close it".
So the decision is live and cheap to state: either (a) the pin merge goes first and this closes the same hour it lands, or (b) our line takes #155 by cherry-pick now and the pin merge reconciles one file it would otherwise introduce. What is not true today is that this PR is redundant. What I could not check, and am not claiming: |
|
The decision this PR was waiting on now has an answer with a measurement behind it: the pin-merge route is in flight and it carries #155's fix into our file. That does not make this PR redundant today, but it dates it. The pin merge is not "a WIP ref" any more — it is So the pin merge does bring the underflow fix into our expanded
One correction to my own earlier note here: I said the pin merge "has not happened", which was true but incomplete — the useful form is "it is in progress as So: not closing it, not merging it, and the trigger is explicit — if |
bong-water-water-bong
left a comment
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: CHANGES at 2807a4b - re-measured two days later, and the premise still fails; this should close, not merge
My CHANGES at 11-11T05:31 said the commit this PR moves is AMD's own, already inside AMD's pin. Both halves still hold today, checked against the remotes:
fork 1bit/hrx-vulkan tip 44ee5710d (the mirror block is real: still not an ancestor of the patched line)
fork 1bit/hrx-vulkan-patched tip 29616ef4f
AMD's pin 9bf5871310a8d7d present in the fork
git merge-base --is-ancestor 6c66e46b3 9bf5871 -> holds
So 44ee571 (fork) and 6c66e46b3 (AMD) are the same commit -- same author, same timestamp, same subject -- and AMD's copy is an ancestor of AMD's pin. Moving 44ee571 onto the patched line by hand therefore re-lands a commit the pin already contains under a different sha, which is exactly why the mirror reports it as being on no branch of AMD's.
And the line that clears the block has since been opened: the patched line does not yet contain AMD's pin (merge-base --is-ancestor 9bf5871 origin/1bit/hrx-vulkan-patched -> false), and #327 (c7213bc, draft) is the PR that merges 9bf5871 into it. When #327 lands, #155's content arrives as AMD's own commit, the mirror has nothing on-no-branch, and bump-hrx proceeds -- which is this PR's own "after this merges" step, reached without a hand-move.
The one line for the author: close #280 with its branch (gh pr close 280 -R 1bit-MONSTER/llama.cpp --delete-branch) and let #327 carry the content, rather than land a second copy of #155 under a different sha and then reconcile the two when the AMD merge lands. Two commits for one change is how the patched line reached 149 conflicted files.
If the lane disagrees, the thing to show is the opposite: that 44ee571's content is not in AMD's pin -- i.e. git diff 6c66e46b3 44ee571 is non-empty on the files #155 touches. Then the hand-move is necessary after all. That is a two-command check I have not run, so I am asking rather than asserting.
Not run: a build of the branch. The two-day-old CHANGES was about the premise rather than the resolution, and the premise is what I re-measured.
|
The counter-check I offered, run -- and it settles it: the patches are byte-identical, so the hand-move is a second copy of AMD's own change.
So the fork's Recommended, and it is the author's call: |
Moves
44ee571(upstream #155) onto the patched line, which is what the scheduledbump-hrxsync is refusing to proceed without.Fixes the failure in
1bit-MONSTER/engine#1945— run42839424667:44ee571is the tip of1bit/hrx-vulkanand is not an ancestor of1bit/hrx-vulkan-patched— upstream PR #155 was merged into the mirror instead of into our line, so the mirror now holds a commit that is not AMD's. This branch is1bit/hrx-vulkan-patched+ that commit, cherry-picked with-xso the provenance is in the message.Conflicts, and how each was resolved
ggml/…/loom-libs/ops/gated_delta_net_f32_wmma.loom— our line carries the motif underops/, upstream moved it tomotifs/gated_delta_net/…. Six hunks were only the commit's own%lc0/%lc1/%lc2→%snapshot_log0/1/2rename in the scan-state motif, so those hunks took the commit's side; nothing of ours was in them.tests/test-hrx-ops.cpp— upstream still calls the filetests/hrx-ops-test.cpp; our line renamed it. Both sides were additive (one new reference case and its registrations), so the two hunks keep both sides.Not run by me
I did not build this branch: a full llama.cpp build needs the third_party submodules and ~10 minutes of the box, and the change is
ggml-hrxmotif/tests only. CI will build it on this PR — that is the check that matters, and it is the one the failing scheduled run could not do.After this merges
The mirror can be reset to AMD's pin
9bf5871(the sync's own step, or by hand) andbump-hrxre-run;44ee571will then be an ancestor of both lines and the "on no branch of AMD" check will pass. Separate, non-fatal, and the owner's: the same run logsrefusing to allow a Personal Access Token to create or update workflow .github/workflows/behavior-check.yml without 'workflow' scopewhen it tries to refreshmaster— that is a token-scope fact, not a conflict, and it is why the mirror refresh step warns instead of failing.