perf(vulkan): drain the batch only on a real dependency — decode 2.74 → 2.99

[localai-bot]

Decode 2.74 → 2.99 tok/s on Qwen3.6-27B, toward llama.cpp Vulkan's 4.35.

The bottleneck, measured rather than guessed

Both decode GEMMs are already near the bandwidth roof (vt_matmul_vec 90%, lm_head 74%) and GPU busy was only 56% of wall — so the whole gap is host-side.

Attributing every command-buffer flush to its trigger found it in one run: 212 flushes per token, most carrying 1-2 dispatches.

trigger	flushes	avg dispatches
copy	2081	3.2
reference-tier	112	10.0
ring-full / batch-cap	0	—

The ring depth and batch cap — the two knobs previously tuned, including the one that won 1.51× on the 0.6B — never fired once. Backend::Copy drained unconditionally, so every host memcpy paid a submit-plus-blocking-fence round trip and batching was almost entirely defeated.

The fix

A drain is required only when the copy touches memory the open batch bound: reading a buffer the batch writes would see bytes the GPU hasn't written; writing one it reads would change operands mid-flight. If the batch never bound the buffer — the common case, since activations flow forward into freshly allocated ones — neither hazard exists.

A pointer outside every Vulkan allocation is plain host memory and cannot alias a bound buffer, so it never drains. TryResolve is added for that question, because Resolve treats a host pointer as an error.

Flushes 212 → 114 per token; decode 2.74 → 2.99.

What remains, and it is architectural

copy-src and copy-dst still account for 98 of the 114 flushes: the 27B forward moves activations through host vectors between ops, round-tripping ~100 times per token. llama.cpp never does this — its whole graph runs and one readback happens at the end, so its mid-graph submits carry no fence at all (ggml-vulkan.cpp:15709, :16344). Closing that is a device-resident forward in qwen3_5.cpp, a model-level change, and it is the remaining 1.45×.

Gates

test_vulkan_backend 26/26 (1020 assertions), opt-125m STRICT 6/6 token-exact, 0 declines, clean -Werror, full preflight green — all re-run on a clean rebuild after rebasing over 21 commits of main.

The flush-trigger attribution ships behind VT_VULKAN_DISPATCH_STATS. It is the third diagnostic this session that answered in one run what reading the source had gotten wrong.

🤖 Generated with Claude Code

[localai-bot]

LANDED on main in merge commit f9a58ba8.

Rebased over 21 commits of main and re-gated on a clean rebuild before merging, not on the pre-rebase build: test_vulkan_backend 26/26 (1020 assertions), opt-125m STRICT 6/6 token-exact with 0 declines, agent-preflight green, check-role-discipline OK, commit-trailer contract OK against the current cutover.

Pre-existing red, not from this branch: test_agent_role::test_landed_detached_commit_remains_strict_without_pending_evidence fails identically on origin/main — verified before attributing.

Closing per POL-PR-DISPOSITION.