[bong-water-water-bong]

Mitigates 1bit-MONSTER/engine#1339 (the engine pin bump carries Fixes #1339).

#226 imports the loader's weight mapping instead of copying weights to the device (engine ggml-org#856). On larger models that import
never finishes. The mapping is fully paged in, then GTT and RSS stay flat and the load waits with no error. This makes the import
opt-in: GGML_HRX_WEIGHT_HOST_PLACEMENT=1 turns it on; unset or 0 keeps the device copy. caps.buffer_from_host_ptr follows
the same switch, so with the import off the loader also goes back to a read-only mapping (src/llama.cpp map_weights_writable).
One file, ggml/src/ggml-hrx/ggml-hrx.cpp, +8/-6.

Measured on strixhalo (gfx1151), one gpu-hold ticket per row group, own drm-total-gtt from /proc/<pid>/fdinfo

llama-cli -ngl 99 -fit off -c 256 -n 8 --temp 0 -no-cnv -p "The capital of France is"; perplexity -f wiki.test.raw -c 512 --chunks 20 -b 512.

Before (a3e8d42c9, shipped default = import on), Qwen3.8-27B-UD-Q4_K_XL (dense, 16.4 GiB), 1 Hz trace:

10:37:57 gtt=178MiB rssfile=21MiB
10:38:43 gtt=298MiB rssfile=16555MiB
... every sample identical for 11 min 12 s ...
10:49:56 KILLED at TMO=720s

(Flash-Next 76.3 GiB: a 72-minute stall, and a 75 s load with the import off; measured by another lane, engine#856 comment 6707101791.)

After (this branch da22b63ba):

model	setting	own GTT peak	result
Qwen3.8-27B (16.4 GiB)	unset (new default)	20497 MiB	loads and generates in 24 s
Qwen3-4B-Q4_K_M	unset	3925 MiB	generates
Qwen3-4B-Q4_K_M	=1 (opt-in import)	1243 MiB	generated text identical to unset
Qwen3-4B-Q4_K_M ppl	unset	5692 MiB	PPL 16.3000 +/- 0.82830

Earlier, on a3e8d42c9: 4B perplexity with the import on was also 16.3000 +/- 0.82830 (3010 MiB). The import is correct where it
completes; the problem is that it does not complete on large files.

Cost: the ggml-org#856 GTT saving is off by default again (4B: 3925 vs 1243 MiB) until the import is fixed. Large models load again.

[bong-water-water-bong]

ready for review at da22b63

[bong-water-water-bong]

VERDICT: READY at da22b63bac63645eed07b54718ad206793c9c69f. The right mitigation, and the whole of it: one switch now governs both the import and the capability the loader keys its writable mapping on.

An admission first: I READY'd the import's engine pin (engine ggml-org#1303) after testing a 4B copy for file integrity, and took the author's MoE row (the tightness-gate fallback) as the large-model evidence. I never loaded a large dense model with the import on, which is the case that hangs here. This PR is the correct response to that gap.

Checked in the source at this head (ggml/src/ggml-hrx/ggml-hrx.cpp)

• import_host_pointer_enabled() (:163) is now true only for GGML_HRX_WEIGHT_HOST_PLACEMENT=1; unset or 0 means off. A script that set =0 for the old A/B control still gets "off".
• The device's props->caps = { true, true, import_host_pointer_enabled(), false } (:866) puts the switch in the buffer_from_host_ptr slot. So with it off, src/llama.cpp's map_weights_writable (any non-CPU device with caps.buffer_from_host_ptr) is false: the loader goes back to the read-only shared mapping and opens no model file r+b. The body's claim holds.
• device_buffer_from_host_ptr() also refuses early when the switch is off (:915), so even a caller that ignored the capability gets the device copy.
• One file, +8/−6. The static const lambda reads the env once, as before.

Not re-run: the 27B load (11 min stall → 24 s) and the 4B GTT/PPL rows. Those are the author's device rows.

For ggml-org#1339's bookkeeping: this is a mitigation (the import still hangs on large files, now behind =1), and the body says so ("Mitigates"). The engine pin bump ggml-org#1343 says Fixes #1339, which would close the issue while the hang is unresolved. Either keep ggml-org#1339 open with "default-off mitigation landed" or open a follow-up for the hang itself, so the GTT saving isn't quietly lost. ggml-org#1343's pin-on-branch sequencing is already called out there.