Blog: correct two claims in the HRX race post

[bong-water-water-bong]

Two statements in blog/2026-09-27-hrx-decode-race-solved.md were stronger than the evidence:

• "The window only opens when the GPU preempts the dispatch." Before the fix, quiet-box runs still diverged a few percent of the time (the HRX: decode-split multipass path intermittently faults (HSA_STATUS_ERROR_MEMORY_FAULT) above capacity 2048 #123 session measured 1.7-6.7%). Preemption widens the window; it does not create it. The text now says so.
• "+30-37% at depth 2100" for Pin llama.cpp a34a6b7: HRX decode-split multipass output pass is vectorised (engine#124) #180. That came from a secondary two-round run in Pin llama.cpp a34a6b7: HRX decode-split multipass output pass is vectorised (engine#124) #180's description. Pin llama.cpp a34a6b7: HRX decode-split multipass output pass is vectorised (engine#124) #180's main table (median of 6 interleaved rounds, Qwen3-Coder-30B-A3B) gives +15.4% / +19.8% / +22.0% at depth 2100 / 3000 / 4800. The post now quotes that.

Docs only.

🤖 Generated with Claude Code

[context7]

Docs7 for 1bit-monster/engine

Result	Status	Action
Deployment	➖ Not used	—
Content review	➖ Did not run. This site has no agent runs available this month. Wait for the monthly reset or check your Docs7 plan.	—

Commit 2312241

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 123 - Partially compliant Compliant requirements: The PR correctly addresses the issue by fixing the claims in the blog post, which aligns with the root cause analysis in the ticket Non-compliant requirements: The PR does not contain code changes to fix the actual hardware fault; it only updates documentation and blog post claims Requires further human verification: The actual fix for the memory fault (issue HRX: decode-split multipass path intermittently faults (HSA_STATUS_ERROR_MEMORY_FAULT) above capacity 2048 #123) is not in this PR, but the blog post claims are corrected to reflect the correct performance numbers from the actual fix 180 - Partially compliant Compliant requirements: The PR correctly updates the blog post to reflect the correct performance numbers from the actual fix The blog post now correctly quotes the median performance improvements from the main table Non-compliant requirements: The PR does not contain the actual kernel changes that implement the vectorization Requires further human verification: The actual kernel changes and performance improvements are not part of this PR

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

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Incorrect Performance Claim The blog post previously claimed +30-37% performance improvement at depth 2100, but the actual measured improvement from the main table in the PR description is +15.4%. This change corrects the claim to match the actual measured performance, which is important for accuracy in performance reporting. ([#180](https://github.com/1bit-MONSTER/engine/pull/180)): on Qwen3-Coder-30B-A3B, +15% at depth 2100, +20% at 3000 and +22% at 4800 (median of 6 interleaved rounds), with bit-identical perplexity. `ONEBIT_HRX_DECODE_SPLIT=0` turns the kernel off if you need to compare. Misleading Preemption Statement The blog post previously stated that "The window only opens when the GPU preempts the dispatch in the middle." This was incorrect. The fix now correctly states that the window is narrow on quiet boxes but can be widened by GPU preemption or other system evictions, which is a more accurate representation of the race condition behavior. The window is narrow on a quiet box (a few percent of requests diverged there) and wide when the GPU preempts the dispatch in the middle. Any process's KFD queue eviction does that: page compaction, KSM, memory pressure. That is why the failure rate followed those system settings. For a while it looked like a page-migration bug, but migration was only the trigger. The fix fences both memory spaces at all five places the kernel does this: