[bong-water-water-bong]

Gate hardening:

• Two new rows: qwen3-0.6b with -fa on -ctk q8_0 (V f16) and with -ctk q8_0 -ctv q8_0; kat + the 7.1K needle + placement (no kld: bases are per model file, f16 cache). Their long prompts pass 1,024 KV cells, where the split q8 decode kernel takes over (the HRX: follow AMD's live ggml-hrx, pinned to AMD's tested pair and kept current #11 f16-V bug lived there; test-backend-ops has no mixed K/V FA case). Goldens recorded with our kernels.
• ops phase runs the add-on's ggml-hrx-fa-decode-bench q8 check (KQ8=1, VQ8 0/1, Hq/Hkv 16/8 and 32/8, n_kv 1031/2048/4103).
• The gate takes ~/GPU-TOKEN (waits up to HW_GATE_TOKEN_WAIT, default 3600 s, logging holders; releases only its own content on exit/TERM/INT/HUP; gpu-token FAIL exit 2 on timeout; HW_GATE_TOKEN=none for a caller that holds it). Today two Pin gpu-kernels fcf526ea: jina attention (G10), softmax sinks fix, startup ABI check - census 43/43 on HRX #481 gate runs died with rc 137 loading models while Hyperloom held the GPU.

Evidence (strixhalo, f932d52 pins + the add-on): full gate PASS 592 s: build, ops 618/618, fa-decode-q8 6/6 (NMSE <= 2.3e-13), kat/needle/placement/kld on the 5 models, kat/needle/placement on both new rows; the token tests (timeout -> exit 2, TERM -> token removed, real waits of 960 s for Hyperloom and another gate).

🤖 Generated with Claude Code

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit 8fce031)

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 11 - Partially compliant Compliant requirements: The llama.cpp source now points at the new org fork 1bit-MONSTER/llama.cpp (fork of ggml-org/llama.cpp), branch 1bit/hrx-vulkan = AMD's f1a0aca The HRX runtime: third_party/hrx-system = fab1624, AMD's pin. The separate third_party/hrx (ROCm/hrx) submodule and patches/hrx/ are removed The build (cmake/hrx.cmake): a single external project. llama.cpp's ggml-hrx builds hrx-system itself (HRX_SOURCE_DIR) with TheRock's amdclang The HSA runtime: the distro's libhsa-runtime64 rejects gfx1151's PM4_EMULATION probe, so HRX then registers no device. CMake now finds TheRock's copy, and 1bit lemonade passes it to llama-server as IREE_HAL_AMDGPU_LIBHSA_PATH (unless you've set it yourself) The device name: HRX20 → HRX0 in the app defaults, tests/hrx_lemonade_e2e.sh and the docs Keeping current: a new daily workflow, .github/workflows/bump-hrx.yml. When AMD moves its pair, it syncs the fork (master to ggml-org, 1bit/hrx-vulkan to AMD's pin) and opens a PR moving both submodules. It needs a secret HRX_BUMP_TOKEN: a fine-grained token with Contents read/write on 1bit-MONSTER/llama.cpp and 1bit-MONSTER/engine, and Pull requests read/write on 1bit-MONSTER/engine Verified on Strix Halo: End to end: tests/hrx_lemonade_e2e.sh PASS. Qwen3-0.6B Q4_0 answers "Paris" through both recipes, served by this build's llama-server on Vulkan0 and HRX0. Speed: llama-bench, Qwen3-0.6B, pp512 / tg128: Vulkan0, Q4_K_M 10627 / 306 vs 13905 / 338; HRX, Q4_K_M 1046 / 68 (HRX20) vs 21702 / 303 (HRX0) Non-compliant requirements: The previous build is kept as 1bit/hrx2-archive in the fork (our Q4NX kernels, zaya, MoE grouping) for a later port to ggml-hrx Requires further human verification: None 481 - Partially compliant Compliant requirements: Pins gpu-kernels ZINC: pin upstream, serve it through Lemonade, NVIDIA verified on an RTX 5090 #14 (strided batched matmul + ALiBi softmax for jina-bert) The 20 Oct HRX census closes: 43 of 43 runnable cells (chat, long, q8 KV, --parallel 4, MTP, embedding, rerank across Qwen3 0.6B/4B, LFM2, MiniCPM, ZAYA, Coder-30B, GLM, Qwen3.8-27B, nomic, jina, bge) with 0 nodes off HRX, 1 graph split, every request answered Non-compliant requirements: None Requires further human verification: None

⏱️ Estimated effort to review: 4 🔵🔵🔵🔵⚪

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review GPU Token Handling The GPU token handling logic in scripts/hw-gate.sh introduces a new mechanism for acquiring and releasing GPU access via a file-based lock (~/GPU-TOKEN). While this is a good approach for coordinating GPU usage, the implementation has a potential race condition during token acquisition. Specifically, the check if ( set -o noclobber; printf '%s\n' "$mine" > "$TOKEN" ) 2> /dev/null can be bypassed if another process manages to create the file between the check and the write. This could lead to multiple processes incorrectly believing they hold the token, potentially causing conflicts in GPU usage. local mine waited=0 holder last="" while :; do mine="hw-gate ${GITHUB_RUN_ID:+run $GITHUB_RUN_ID }pid $$ $(date -Is)" if ( set -o noclobber; printf '%s\n' "$mine" > "$TOKEN" ) 2> /dev/null; then TOKEN_HELD=$mine note "took $TOKEN ($mine) after waiting ${waited}s" return 0 fi holder=$(cat "$TOKEN" 2> /dev/null || true) if [ "$holder" != "$last" ]; then note "waiting for $TOKEN, held by: ${holder:-?}"; last=$holder; fi if [ "$waited" -ge "$TOKEN_WAIT" ]; then note "::error::$TOKEN is still held after ${TOKEN_WAIT}s (by: ${holder:-?}); the gate did not run its GPU steps" return 1 fi sleep 15; waited=$((waited + 15)) done Incorrect Model Table Entry The model table entry for qwen3-0.6b-kq8 in scripts/hw-gate.sh has an incorrect format. The entry qwen3-0.6b-kq8|Qwen3-0.6B-Q4_K_M.gguf|2|1|-fa on -ctk q8_0 is missing the srvargs field in the table structure. This could lead to incorrect parsing of the model table and potentially incorrect server arguments being passed to the llama-server. qwen3-0.6b-kq8|Qwen3-0.6B-Q4_K_M.gguf|2|1|-fa on -ctk q8_0 qwen3-0.6b-kvq8|Qwen3-0.6B-Q4_K_M.gguf|2|1|-fa on -ctk q8_0 -ctv q8_0"

---

⚠️ Review coverage: The following files were not included in this review because of the token budget:

• docs/hw-gate.md

[github-actions]

Persistent review updated to latest commit 8fce031