vulkan: keep the VK_TEST harness clean under synchronization validation

[crichalchemist]

Ran the Khronos validation layer's synchronization validation (validate_sync, SDK 1.4.357.1) over backend_vulkan.c on a Radeon Pro 580 through MoltenVK (macOS 13, x86_64), with duplicate suppression off so nothing past the first message ID was hidden. The production paths came back with zero hazards — matmul, fused gate_up, the expert group both sync and issue/take, the matmul pair, attn_qprep, absorb — and so did the qwen36 tier tests and four token-exact oracle runs through the tier on #1338. What the layer did report is confined to the VK_TEST harness, and that is what this PR fixes, so the harness can be a clean regression tool under the layer rather than 300 lines of noise.

c/backend_vulkan.c, harness throughput loops — bench_batched, bench_gu_batched and bench_experts_fair record 64 dispatches into one command buffer, each rewriting the same output, with a SHADER_WRITE → SHADER_READ barrier between them. That orders the reads, not the next write, so the layer reports a write-after-write hazard on every dispatch after the first: 315 in all (63 + 63 for the two matmul benches, 63 for the fused bench, 126 for the two fair-cycling benches). Harmless for a timing loop — nothing reads those outputs — but the fix is one bit: the destination mask now also carries SHADER_WRITE. The production dispatch loops (coli_vk_expert_group, the second-device path) bind distinct slices per expert and were not flagged.

c/backend_vulkan.c, coli_vk_shutdown — at vkDestroyDevice the layer lists 6 VkBuffer + 6 VkDeviceMemory the harness never freed: the two qprep scratch buffers G.qp1 / G.qp2 and the per-layer resident norm weights G.lnbuf[] / G.lnmem[] that coli_vk_attn_qprep uploads once per layer. None were destroyed at shutdown; they are now, next to the other scratch buffers. Eight more objects remain on dev — the rmsnorm pipeline set, its layout, shader module and two descriptor pools — and those are already fixed in #1338 (cb70b7a), so this PR leaves them to it rather than carry the same hunk twice; the two touch different lines of the function.

c/backend_vulkan.c, harness — only shaders/qmatmul.spv is tracked; the sibling .spv files come from make … VK=1. In a fresh checkout without them coli_vk_init succeeds, run_gate_up reports the missing shader and returns, but the two fused benches then bind G.pipe_gu == VK_NULL_HANDLE directly — the layer flags VUID-vkCmdBindPipeline-pipeline-parameter and MoltenVK segfaults on the next descriptor bind. Both benches now return −1 when the pipeline is absent, matching what run_gate_up already does.

docs/vulkan.md — one bullet under Correctness: how to enable the core and synchronization checks from the loader (nothing in the backend enables layers), the fact that a settings file is only read from a directory holding a file named exactly vk_layer_settings.txt, and a known layer defect: with submit-time synchronization validation on, this SDK segfaults inside the layer at vkDeviceWaitIdle during shutdown — after all work is done, but inside an atexit handler, so buffered stdout is lost with it. The workaround (disable that one setting, or run under a pty) is in the docs because it cost an hour to see through.

Verified on the Radeon Pro 580 via MoltenVK, harness built with clang -O3 -DVK_TEST against /opt/local:

run	before (dev @ cc756a6)	after
harness under core + sync validation, duplicates unlimited	315 SYNC-HAZARD-WRITE-AFTER-WRITE, 20 leaked objects	0 hazards, 8 leaked objects (the #1338 set)
harness, no layer	50 cases, same values	50 cases, same values to the printed digits
harness with qmatmul_gate_up.spv moved away	SIGSEGV in vkCmdBindDescriptorSets	completes, reports gate_up failed and the fused benches as −1
make colibri VK=1	—	0 warnings
make check	—	exit 0, Python suite OK

Two things this did not do. It ran only on MoltenVK, not RADV, and the VK_KHR_portability_subset error the layer also reports on MoltenVK is #1338's. And the harness still ends in FAIL on this box before and after: qprep fmt=1 S=11 reports a kv maxrel of 2.9e-3 against the 1e-3 gate, deterministic across runs and unchanged with MoltenVK's fast-math disabled, while the S=1 and S=2 cases pass. I have not chased it; if the RX 580 rows in the docs passed that case, it is MoltenVK-specific and worth a line in the docs, and if they did not it is a gate calibration question. Separately, the fresh device-local-block nondeterminism the docs describe on the RX 580 does not reproduce here: staged and mapped are byte-identical on all 50 cases over three runs, with the fill-once workaround and with it compiled out.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NJcbVYkasdfXg5DEsHdSCt

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.