local-ai · review · first seen Nov 1, 10:32 UTC

llama.cpp fixes Hexagon DMA stride handling in b12030

llama.cpp b12030 shipped a Hexagon DMA fix for strides of 16 MB or more. Builders using affected paths should check whether the change addresses their workload before treating the pre-release as a routine update.

L0 · primary1 source3 claims checked4 min read

What shipped

b12030 changes the Hexagon DMA path for strides of 16 MB or more. Instead of relying on the existing 2D fallback, it falls back to one transfer per row. This is a change to how transfers are addressed, not a claim that every Hexagon workload will behave differently. The threshold matters: the release description identifies strides at or above 16 MB as the case the new path handles. [1]

The reason is a descriptor limit on v75+ hardware. Its 2D DMA descriptor stores row_size and strides in 24 bits. Before this fix, dma_queue_push sent oversized strides to fallback_2d, which split nrows but did not split the stride. The release description says that a stride of 16 MB or more could therefore be truncated and produce wrong addresses. The per-row fallback targets that addressing problem. [1][2]

b12030 also adds two CONT tests whose source strides exceed 16 MB. Those tests put the reported boundary into the test suite, rather than leaving the change solely as a code-path adjustment. The source says the tests were added; it does not provide their results across hardware or describe a broader validation matrix. Treat the tests as a concrete way to inspect the intended case, not as proof about every deployment. [1]

Why it matters if you build

For a builder, the first decision is whether the workload reaches this DMA path with a stride at the stated threshold. If it does, the earlier fallback could split rows while still passing a stride too large for the descriptor field, leading to wrong addresses. b12030 changes the fallback at that boundary. If the workload does not use that path or stride range, these claims do not establish a reason to change it today. [1][2]

The trade-off to examine is transfer behavior. The new fallback uses one transfer per row when the stride is 16 MB or more; the previous fallback split nrows. That gives a specific behavior to test in a real workload. The supplied source gives no timing, transfer-count comparison for a particular workload, or resource cost. Do not assume the addressing fix is free, or assign it a performance penalty, without measuring the workload you intend to run. [1]

The added CONT tests are a useful starting point because their source strides are over 16 MB, but they do not cover the entire decision. In particular, the claims do not say how a builder's own shapes, strides, or hardware configuration map to those tests. Use the stated threshold and the tests to choose a targeted check; keep the result of that check separate from what the release description itself establishes. [1][2][3]

How to try it today

1. Check whether the workload uses the Hexagon DMA path on v75+ hardware.
2. Identify any source strides of 16 MB or more in the workload you plan to run.
3. Inspect b12030's per-row fallback and the two added CONT tests with source strides over 16 MB.
4. Run a representative affected workload and check its output against your existing correctness expectation. Do not treat the added tests alone as validation of that workload.
5. If transfer behavior matters to your decision, measure your own workload; the supplied claims give no performance result.

What we checked

Every claim below was walked down the source ladder. The rung is how close the source is to the thing itself; the tense is the source's own.

1. shipped L0 · primary

   llama.cpp b12030 changes Hexagon DMA handling to fall back to one transfer per row for strides of 16 MB or more.

   per GitHub releases · ggml-org/llama.cpp (L0)
2. shipped L0 · primary

   On v75+ hardware, the 2D DMA descriptor stores row_size and strides in 24 bits.

   per GitHub releases · ggml-org/llama.cpp (L0)
3. shipped L0 · primary

   llama.cpp b12030 adds two CONT tests with source strides over 16 MB.

   per GitHub releases · ggml-org/llama.cpp (L0)

What is not confirmed

The sources do not establish a performance change, the number of affected users, or results for any particular model or deployment. They do not say that the two added CONT tests cover every stride or hardware case. They identify the descriptor limit, the previous wrong-address condition, the shipped fallback change, and the tests added in b12030. Anything beyond that needs a check on the builder's own path. [1][2][3]

Who should act, who should wait

Move now if you use the affected Hexagon DMA path and have strides of 16 MB or more: b12030 shipped a fallback aimed at a stated wrong-address condition, and the added tests give you a relevant case to inspect. Wait on adopting it for this reason alone if you have not established that your workload reaches that path and threshold. If performance determines the decision, test first; no performance outcome is confirmed here. [1][2][3]

Sources

• b12030 — GitHub releases · ggml-org/llama.cpp L0 · primary