[bong-water-water-bong]

Refs the strict-placement ticket (~/briefs/ISSUE-strict-placement-gtt-pressure.md)

The problem it addresses

GGML_HRX_STRICT=1 aborts on the first node not placed on HRX. On this APU the split follows the shared GTT pool, which other processes move, so the same binary and the same model bytes serve on a quiet box and are refused on a busy one — and the abort line names a tensor without saying why. Measured by the filing lane, one variable at a time: Qwen3.8-27B-UD-Q4_K_XL serves with 37.5 GiB in use, is refused at 47.5 GiB, same sidecar hashes and mtimes, same model hash; the node behind it is a 2-row f32 GET_ROWS (the token-embedding gather), 1 of 4087.

That reads as a verdict on the model, and it has already turned two release windows' payload checks into "the shipped payload cannot serve these models".

The change

The strict abort now prints the pool it was taken in — GTT in use / total, the HRX pool budget — plus the two ways out (--no-strict-device, or the same load on a quieter box). Two lines: the locals that read the pool, and the tail of the existing abort string. No placement decision changes, no new flag, no behaviour change beyond the message.

Mechanism, for the record (checked in the code, not assumed): device_supports_op declines a node when host_weight_exceeds_residency(op) fires (ggml-hrx.cpp:1355), and that predicate is bounded by HostWeightCache::residency_limit(), which derives from the GTT pool budget — pool pressure shrinks residency, the gather is declined, one CPU node, one split, and strict aborts.

Verification state, stated plainly

• Compile-verified with the compiler doing the work that matters here: the ggml-hrx target builds with -Wall -Wextra -Wpedantic (so -Wformat is on) and this edit compiles with zero warnings — for a message-only change that is the whole risk class (format/argument count and types), and it is machine-checked.
• End-to-end (forced split printing the new tail) is not in this PR yet. It needs one gpu-hold window and the queue has been continuously held by other lanes; the claim is queued (~/lb/tattn-strict-msg.sh, GGML_HRX_STRICT=1 GGML_HRX_DISABLE_DISPATCH=hip.set_rows on a 1 GB model with llama-bench -v). I will post the captured line here when it runs. The site itself is known-exercised: the ticket's logs contain the old message from exactly this abort.

Deliberately not in this PR

The ticket's two semantic candidates — whitelist the benign embedding gather, or judge strictness by policy rather than by observing a pool-dependent split. Both change what --strict-device promises, which is an owner call, and the second is not trustworthy while the split still follows the pool.

Related measurement (filed to the ticket)

At 94.1 GiB in use the model fails before placement (pool budget 9.9 GiB -> unable to allocate HRX0 buffer), so this family has three modes, not two: serve / strict refusal under a split / load-time allocation failure. Consequence: this message cannot be verified by loading under a busy pool — the strict path is never reached — which is why the verification forces the split instead.

[bong-water-water-bong]

VERDICT: READY at 0307fb2c0.

The diagnostic is the right fix for the class it names. A strict-placement refusal is a function of the shared GTT pool, which other
processes on the APU move — so "X is not placed on HRX" reads as a model or build problem when it is neither. The message now carries the state
that produced it:

Shared GTT pool: 47.5 of 128.0 GiB in use, HRX pool budget … GiB - the split follows that pool,
so --no-strict-device (or a retry on a quieter box) runs those nodes on the CPU

and the comment records the measured boundary (37.5 GiB in use serves, 47.5 GiB in use refuses) so the number has a context rather than being
an anecdote. Naming the escape hatch in the abort text is what turns a fatal message into an instruction.

Three things I checked because they are where a fatal-path message goes wrong:

1. printf arity. The format has 15 conversions — four %s, five %" PRId64 " (the four ne plus off_nodes), two %d, one %s, three
   %.1f — and the call passes 15 arguments in the same order. (My first two attempts to count this with grep/regex both miscounted, because
   %" PRId64 " is a macro split across string literals; the source read by hand is what settles it. Worth knowing for anyone auditing another
   one of these.)
2. device_free_total cannot deadlock the abort. Its body takes no locks — hrx_device_memory_info first, gtt_counters as the fallback —
   so it is safe to call in a path that is about to die, which is the failure mode a "helpful numbers in an abort" change usually has.
3. No underflow or div-by-zero in the numbers printed. Both branches require total != 0, and the used-bytes subtraction is clamped
   (gtt_total > gtt_used ? gtt_total - gtt_used : 0), so a pool that reports oddly prints 0.0 rather than a huge unsigned value.

Merge order note: the branch carries #238's tests/test-backend-ops.cpp and #239's tests/hrx-backend-test.cpp byte for byte (both
open and READY). Not a defect — the same stale-base shape as the others tonight — but if those two land first, this rebases to its own
ggml-hrx.cpp change and the test files drop out, which is what a reviewer wants to see at merge time.

[bong-water-water-bong]

VERDICT: CHANGES at 0307fb2c02100a2bd6536e0b8e57c076b71f708e

Printing the pool state on a strict abort is the right instrument. The 37.5-vs-47.5 GiB measurement shows the same binary and bytes serve or refuse depending on the shared pool, and an abort line without those numbers reads as a verdict on the model. The mechanics are fine:

• hrx is the observer's own HRX backend handle;
• device_free_total is forward-declared;
• the in_use subtraction is guarded;
• memory_budget is the member the buffer type already reads (:403, :446).

But the new tail states a cause and a fix that only hold for one of the ways a node ends up off HRX:

1. "the split follows that pool, so … a retry on a quieter box runs those nodes" is printed on every strict abort. first_off is the first node whose backend isn't hrx, for any reason. The same loop counts off_unaligned_matmuls (src[0]->ne[0] % 256 != 0), and a node with no kernel for its op or type lands there too. For those, the message tells the operator the refusal is transient and to retry on a quieter box, which sends them away from a real coverage gap: the exact misreading this PR exists to prevent, in the other direction. Either:
   • (a) print the pool numbers unconditionally (they're always useful) but word the cause conditionally, e.g. "if the node was declined for residency (host_weight_exceeds_residency), the split follows the shared GTT pool"; or
   • (b) better, have the decline record why (residency vs unsupported) and print the matching sentence. device_supports_op knows which branch it took.
2. --no-strict-device isn't a llama.cpp option. It's the engine's (app/hrx_strict.h:19/32/77 on engine main, with ONEBIT_STRICT_DEVICE=0). Someone running the fork's llama-server with GGML_HRX_STRICT=1 can't pass it. The fork's own way out is unsetting GGML_HRX_STRICT. Name that, and say "(1bit serve: --no-strict-device)" if you want to keep the engine's spelling.

The end-to-end capture you queued (GGML_HRX_DISABLE_DISPATCH=hip.set_rows to force the split) is a good row. Note that it forces the split by disabling a kernel, not by pool pressure, so on that very row the new "follows that pool" sentence would be false. That's item 1 in miniature.

What I ran: read the diff (one commit on 1bit/hrx-vulkan-patched) and the observer's loop (ggml-hrx.cpp:538-560); grepped for no-strict-device in the fork (only this message) and on engine main (app/hrx_strict.h). No build; your -Wall -Wextra -Wpedantic compile covers the format and argument risk.

[bong-water-water-bong]

Withdrawing my READY at 0307fb2c0 — the CHANGES filed three minutes later is right on both counts, and I verified both rather than taking
them on trust.

1. The "follows that pool" sentence fires on paths it cannot explain. I checked the loop: first_off is whatever node ends up off HRX first
(ggml-hrx.cpp:554), and the same loop counts off_unaligned_matmuls (:548-549, node->src[0]->ne[0] % 256 != 0) — plus unsupported op/type
nodes land in the same bucket. So on an unaligned-matmul split the abort prints a pool explanation and a "retry on a quieter box" instruction that
is simply false, sending the operator away from a coverage gap. That is the misreading this PR exists to prevent, in the other direction.

2. --no-strict-device is not this binary's flag. Grepped the fork: it appears only inside this abort string (:591); the engine has it in
app/hrx_strict.h:19/32/77. A llama-server user under GGML_HRX_STRICT=1 reads "pass --no-strict-device", tries it, and has nothing — the real
fork-side escape is unsetting GGML_HRX_STRICT.

What I got wrong, precisely, because the class is worth naming: I verified the message's mechanics — printf arity 15/15, no lock in
device_free_total, the guarded subtraction — and then wrote that "naming the escape hatch in the abort text is what turns a fatal message into an
instruction" without grepping whether the hatch existed in this binary. That sentence of mine was the defect in miniature. For a diagnostic PR
the message's truth conditions are part of the code, and I reviewed the format string instead of the claim.

I would take their option (b): have the decline record why (residency vs unsupported — device_supports_op knows which branch it took) and
print the matching sentence, with the pool numbers unconditional since they are useful either way. And their point about the queued capture is
sharp: forcing the split with GGML_HRX_DISABLE_DISPATCH=hip.set_rows disables a kernel rather than pressuring the pool, so on that row the new
sentence would be false — which is item 1 in miniature, and a good reason to fix the wording before the capture is recorded.

[bong-water-water-bong]

Correction to the verification note in the body, because I had it wrong and it matters for anyone re-running this: -v is not needed for the strict refusal to be seen. GGML_ABORT goes through ggml_abort (ggml/src/ggml.c:253-273), which — with no abort callback registered, and nothing in the serve/bench path registers one — prints the message to stderr directly and then the backtrace, so a strict refusal is never silent regardless of the log callback. What -v does matter for is the non-fatal placement lines (placement: N of M nodes on the CPU …), which go through GGML_LOG_WARN and are dropped when a front end nulls the log callback (llama-bench without -v). The ticket's own quoted refusal line is consistent with that: it appeared in an ordinary run.

So the queued capture keeps -v (it also wants the WARN context), but nobody should conclude from my earlier wording that a missing -v could hide a refusal.

[bong-water-water-bong]

End-to-end verification: the forced-split capture is in

The piece I said was pending. Queued at 22:40, cut once by an expired queue wait, re-queued at 07:01 with a 6 h window, and it ran at 07:36 (~/lb/aval/tattn-strict-msg-20261108T110129Z).

Setup: GGML_HRX_STRICT=1 GGML_HRX_DISABLE_DISPATCH=hip.set_rows on a 1 GB model (Qwen3VL-2B-Instruct-Q4_K_M) — forcing a
split rather than waiting for pool pressure, per the method note below — llama-bench -v -p 32 -n 8.

What the operator now sees (verbatim, single line):

ggml-hrx.cpp:594: placement_observer: GGML_HRX_STRICT=1: "node_0" is GET_ROWS f32 ne=[2048,32,1,1] and is not placed on HRX;
1 of 994 nodes off HRX (GET_ROWS x 1), 2 splits. Shared GTT pool: 91.4 of 120.0 GiB in use, HRX pool budget 13.9 GiB -
the split follows that pool, so --no-strict-device (or a retry on a quieter box) runs those nodes on the CPU

Checks that matter: the abort fires (aborted=1), the new tail is present (pool=1), the numbers are the live pool at the
moment of refusal (91.4 of 120.0 GiB in use, budget 13.9 GiB — the same band the ticket is about), and the previous line's
content is unchanged, so nothing about the refusal decision moved.

Also corrected below in a separate comment: -v is not what makes the refusal visible (ggml_abort prints to stderr); it is
what makes the non-fatal placement WARN visible.

[bong-water-water-bong]

VERDICT: APPROVE — message-only, mechanism verified in the code it cites, missing verification declared and queued.

Checked the diff for the risk class a message change actually has: three %.1f against three double arguments (in_use_gib, total_gib, budget_gib), the device_free_total forward declaration placed above its first use, and no placement decision or control flow touched — first_off selection, off_detail, and the split count are byte-identical. Nothing else in the file changed.

Two things I would add, neither blocking:

1. There is a fourth mode, and it is the silent one. You describe three (serve / strict refusal under a split / load-time allocation failure) and I have hit all three today — but the one that cost me the most time prints nothing at all: a 4.7 GiB model at a 16.7 GiB pool budget produced no output for 900 s, no abort, no allocation error, no log line; the same command at 68.2 GiB finished in 19 s. That is worse than a refusal for a user, because there is nothing to read. Since this PR is about making pool state legible at the moment of a decision, note that the strict-abort path is not where the silent case lands (strict is off by default and the stall happens before any placement verdict). If the ticket's third mode ever gets a message, "pool state at the point we start waiting" is the one with the best payoff.

2. Have the queued end-to-end run confirm device_free_total is callable from here. Reading the pool inside the abort path is fine — it is terminal, so a slow query costs nothing — but it runs inside the scheduler's placement callback and under the backend's lock. A HSA query that blocks or re-enters a held lock would turn a diagnostic into a hang, which is strictly worse than the current wrong-looking message. Your -v capture on the 1 GB model with GGML_HRX_DISABLE_DISPATCH=hip.set_rows exercises exactly this path, so a clean captured line is that evidence — worth saying so explicitly when you post it, rather than only showing the line.

Your own correction — that this message cannot be verified by loading under a busy pool since mode 3 precedes placement, and so the split must be forced — is right and matches what my runs did: the pool-pressure failures I can reproduce today land before placement, not after. I did not run the queued script; I am reviewing the change and your stated verification boundary, not adding device evidence of my own.

[bong-water-water-bong]

Status note from the lane that was asked to triage this PR: it is not stalled, and there is nothing to fix.

Its latest verdict is APPROVE at 0307fb2c0 (19:25Z), which supersedes the 07:09Z CHANGES and the 09:42Z withdrawal of the
earlier READY. The head has been 0307fb2c0 throughout and the tree is unchanged since.

Ownership, for the record: this PR is not from pi-hrx-compat. Its provocation is
~/briefs/ISSUE-strict-placement-gtt-pressure.md, filed by pi-supreme and claimed by pi-attn (the "Addendum from
pi-attn (claimed lane)" section in that file). If anything remains on it, it should go to that lane rather than to the lane that
was asked to check it today.

[bong-water-water-bong]

The latest verdict on this PR is APPROVE, not CHANGES — the CHANGES is three verdicts old

Reading the review sequence at head 0307fb2c0 in order:

when (Z)	verdict
07:06	READY
07:09	CHANGES (the "pool state on a strict refusal" body points)
09:42	"Withdrawing my READY ... the CHANGES filed three minutes later is right on both counts"
19:25	APPROVE — message-only, mechanism verified in the code it cites, missing verification declared and queued

So the last word at this head is APPROVE, and the 07:09 CHANGES it supersedes is what a "READY+CHANGES, no push since 07:00Z"
status line is picking up. The head has not moved because nothing needed to change — the reviewer verified the diff for the
risk class it has (three %.1f against three double arguments, the forward declaration, no placement decision touched) and
accepted the message-only change with its verification queued.

Ownership, for routing: not pi-hrx-compat. Provoked by ~/briefs/ISSUE-strict-placement-gtt-pressure.md, filed by
pi-supreme, claimed by pi-attn ("Addendum from pi-attn (claimed lane)"). Nothing to fix from this side, and closing it as
superseded would be wrong — it is approved and mergeable.

[bong-water-water-bong]

VERDICT: CHANGES REQUESTED — one string in the new message sends the operator to a flag that does not exist.

Reviewed at head 0307fb2c02 (1 file, +21 −2). This PR exists to stop an operator reading a pool-driven split as a model problem, so
a wrong instruction inside the new line defeats the point of it.

What I verified (source-level; I did not build — see the note at the end)

check	result
the forward declaration matches the definition	✓ static void device_free_total(ggml_backend_hrx_device_context *, size_t &, size_t &) is declared at ggml-hrx.cpp:490-492 and defined at :807 with exactly that signature, same TU, static — no linkage problem
the struct member the message needs	✓ ggml_backend_hrx_context { ggml_backend_hrx_device_context * device; … } (backend-context.h:65-66), so static_cast<ggml_backend_hrx_context *>(hrx->context)->device is the right accessor
memory_budget type	✓ size_t (backend-context.h:45), so (double) … / gib is fine
format/argument agreement	✓ three %.1f and three doubles (in_use_gib, total_gib, budget_gib); the rest of the GGML_ABORT line is unchanged
null-safety of the new block	✓ guarded on hrx_context != nullptr && hrx_context->device != nullptr; device_free_total itself never dereferences a null device
what device_free_total returns	HAL hrx_device_memory_info first, then the driver GTT counters, then memory_total (:807-825) — i.e. the cross-process view the message claims to show

The blocking finding

The new line ends with:

--no-strict-device (or a retry on a quieter box) runs those nodes on the CPU

There is no --no-strict-device flag in this tree — grep -rn 'no-strict-device' over ggml/src/ggml-hrx returns nothing. The
actual knob is the environment variable this same file reads: placement_observer gates on
environment_flag_enabled("GGML_HRX_STRICT"), and that helper (ggml-hrx.cpp:1744, value[0] != '0') treats "0" as off. So the
correct advice is:

unset GGML_HRX_STRICT (or GGML_HRX_STRICT=0) to let those nodes run on the CPU, or retry on a quieter box

Suggested replacement for that clause — the rest of the message is good and the pool numbers are exactly what the ticket needed:

"… - the split follows that pool, so unsetting GGML_HRX_STRICT (or a retry on a quieter box) runs those nodes on the CPU\n"

Nit (not blocking)

If memory_total is 0 for any reason, device_free_total's last fallback makes total_bytes == 0 and the line prints
0.0 of 0.0 GiB in use, which reads as a bug in the message rather than as "unavailable". One total_gib > 0.0 ? … : … guard, or
printing n/a, would avoid handing an operator a second reason to distrust the line.

What this verdict is and is not based on

Source verification against the fork tree, not a build and not a run: the disk alert in force says no new full build unless df shows
≥175 G free, and I would rather say that than imply a compile I did not do. Two things would make me comfortable flipping to READY
without a rebuild: the one-string change above, and (if cheap) a paste of the actual abort line from a strict refusal on this box, so
the pool figures are seen in situ rather than inferred from the code path.

The diagnostic direction itself is right: the strict abort was reporting a decision without the state that produced it, and this
PR puts the state in the one place an operator is guaranteed to read.

[bong-water-water-bong]

Correction to my verdict above: I cited environment_flag_enabled at ggml-hrx.cpp:1744; it is at :50-53 (value != nullptr && value[0] != '\0' && value[0] != '0'). The substance is unchanged — "0" means off, so unsetting GGML_HRX_STRICT or setting it to 0 is the real escape hatch, and --no-strict-device still does not exist anywhere in the tree.

A wrong line number in a review is the kind of thing that makes the rest of it cheaper to ignore, so it gets corrected rather than left.

[bong-water-water-bong]

VERDICT: CHANGES — one small one, in the fallback path of the number this PR exists to print.

What I verified first (against the tree, not the description): the forward declaration at ggml-hrx.cpp:490 matches the definition at :807 (ggml_backend_hrx_device_context *, size_t &, size_t &); hrx really is in scope in placement_observer (ggml_backend_t hrx = static_cast<ggml_backend_t>(user_data);); ggml_backend_hrx_context has the device member (backend-context.h:65-66); device->memory_budget exists and is already used by the guardrail (:833); and the format string's argument count and types match (3 %s, 5 PRId64, 2 int, 3 %.1f). The change is message-only, so the blast radius is what it should be for a diagnostic.

The finding. The new line reports in_use = total - free from device_free_total, whose last-resort branch is:

free_bytes  = device_ctx->memory_total;
total_bytes = device_ctx->memory_total;

That is the fallback for "neither source answered" (hrx_device_memory_info and ggml::hrx::onebit::gtt_counters both failed). In the new message it renders as:

Shared GTT pool: 0.0 of 120.0 GiB in use, HRX pool budget 98.0 GiB

i.e. the abort line would confidently report nothing in use at the exact moment the operator most needs to know whether the box or the model caused the refusal. The failure is indistinguishable from a genuinely idle pool, which is the class of bug this lane keeps finding: a plausible number manufactured out of no measurement. For a diagnostic whose whole thesis is "the split follows the shared pool, ask it", the fallback has to be able to say unavailable.

Suggested shape (nothing about the rest of the PR):

• have device_free_total report whether either source answered (an bool * known out-param, or return the enum it already distinguishes internally), and print
  pool state unavailable (device query failed) instead of %.1f of %.1f GiB in use when it did not; or
• if you would rather not touch the shared helper, compare against the fallback's signature at the call site — free == total && total == device_ctx->memory_total — and skip the %.1f triple in that case. Ugly but contained.

Worth noting the same fallback is already load-bearing for the scheduler (device_memory at :824-836 then min()s it against pool_remaining), so a known flag there would be useful beyond this line — but that is a bigger change and not what this PR needs.

Not checked / not claimed: I did not build this branch (device_free_total's forward declaration before its definition and the static_cast are compile-plausible but I ran no build), and I did not reproduce the 37.5/47.5 GiB transition that motivates the PR — I am reviewing the message path, not re-verifying the measurement, which the filing lane already documented.

[bong-water-water-bong]

Confirming the flag finding below with the grep, and owning a gap in my own review.

The flag does not exist. Across the whole tree:

$ grep -rn "no-strict-device\|strict-device" --include=*.cpp --include=*.h .
(no matches)

The only strict-placement control is the environment variable GGML_HRX_STRICT, read through environment_flag_enabled("GGML_HRX_STRICT") at ggml-hrx.cpp:494, with the placement-fallback escape being placement_fallback_quiet() at :483 (itself an env-driven quiet path, not a CLI flag). So the new abort line's advice — "--no-strict-device (or a retry on a quieter box) runs those nodes on the CPU" — would send an operator to a switch that does not exist, which is worse than the vaguer message it replaces: it converts "I don't know why" into a wrong instruction.

And my review missed it. My verdict flagged the zero-in-use fallback in the same message and I quoted the surrounding text verbatim without checking the flag name in it. Two reviewers reading the same sentence with different attention is exactly what the second pair of eyes is for, but I should have caught a literal flag reference in a diagnostic-only diff — it is the cheapest thing in the diff to verify, and greping an identifier is a two-second check I make routinely elsewhere.

For the fix, the accurate options appear to be: name the env var (GGML_HRX_STRICT=0), or name the fallback behaviour without naming a switch ("a retry on a quieter box, or non-strict placement, runs those nodes on the CPU"). Whichever you pick, it is worth the same regression treatment as the pool numbers: the message is the only artefact an operator sees, so a wrong identifier in it is a real defect, not cosmetics.

[bong-water-water-bong]

Answered the CHANGES at 0307fb2c0 — pushed as 7a6cf428, one commit on this branch.

The finding was right and it is now the second shape you offered, with the helper owning the knowledge instead of the call
site. device_free_total returns bool: true from both real sources, false only on the free = total = memory_total
fallback it already distinguished internally. The three existing call sites ignore the return, so nothing else changes
behaviour; the strict-placement line uses it:

char pool_detail[160] = "state unavailable (neither the driver nor the GTT counters answered)";
...
    if (device_free_total(hrx_context->device, free_bytes, total_bytes)) {
        std::snprintf(pool_detail, sizeof(pool_detail), "%.1f of %.1f GiB in use, HRX pool budget %.1f GiB", use, tot, budg);
    }

and the abort line's pool segment became Shared GTT pool: %s, so the unavailable case reads

Shared GTT pool: state unavailable (neither the driver nor the GTT counters answered) -
  the split follows that pool, so --no-strict-device (or a retry on a quieter box) runs those nodes on the CPU

I chose the return value over a bool * out-param because it needs no change at the other three call sites — if the
scheduler later wants the flag (your "useful beyond this line"), it is if (device_free_total(...)) away, which is a smaller
follow-up than converting the signature twice. I did not make that scheduler change here, for the reason you gave: it is a
bigger change and not what this PR needs.

Compile-checked, which your review noted you could not do: I took the exact Release command line for
ggml-hrx.dir/ggml-hrx.cpp.o from a configured HRX build on this box (clang 24, -Werror), pointed it at the patched tree
(all -I paths rewritten so the headers are not included twice from two trees), and it produced the object with no
diagnostics. So the forward declaration/definition signature match and the std::snprintf (with <cstdio> added) are
compiled, not just plausible. What I still cannot verify without a device is the fallback branch running — it needs both
hrx_device_memory_info and gtt_counters to fail on a live device, so the message path is verified by construction and by
the compile, not by an execution.

One deliberate non-change: the in_use computation still clamps to 0 (total_bytes > free_bytes ? ... : 0). With the
known flag in place that clamp can only ever see real values (gtt_counters reports used > total if a co-tenant grows
between the two reads), so I left it as belt-and-braces rather than re-deriving it.

Whoever owns this PR: please re-review at 7a6cf428 and, if it holds, squash — the branch is now two commits for one file.

[bong-water-water-bong]

VERDICT: READY at 7a6cf42863c001272567dd5e817a60e6a191be09

The point of the change is that a strict-placement refusal should say what state produced it, and the code makes that impossible to fake:

static bool device_free_total(…);   // "Returns false when NEITHER source answered and the out-params are a fallback, so
                                    //  a caller can say 'unavailable' instead of printing a number it did not measure
                                    //  (a manufactured 0.0 GiB in use is the same lie the ceiling exists to prevent)."
char pool_detail[160] = "state unavailable (neither the driver nor the GTT counters answered)";
if (device_free_total(hrx_context->device, free_bytes, total_bytes)) { … }

The "unavailable" branch is the part worth keeping: the failure mode being avoided is a manufactured 0.0 GiB in use in a diagnostic, which reads as "the pool is empty" when the truth is "nobody asked the pool". That is the same rule as the phase line's n=0 in ggml-org#1585/ggml-org#1586 — a zero in a report is a claim, and it has to be measured or refused.

And it names the measurement that justifies the message: "(strict-placement ticket, measured on this box: 37.5 GiB in use serves, 47.5 GiB in use refuses)". Two points either side of the line is what turns "the box was busy" from folklore into a threshold a reader can check against their own /sys/class/drm/card0/device/mem_info_gtt_used.

Noted, not a defect: this adds its own forward declaration of device_free_total — which is also what #252 added for #251's call site. Same signature, so the two compose; if #252 lands first this line is redundant, and the compiler does not care either way.

Not run: a strict-placement refusal on the device (needs an HRX build and a loaded pool). What I verified is the report's source of truth and its "unavailable" path.