feat(vulkan): both GDN recurrences go native; prefill amortises the state tile

[localai-bot]

Both GDN recurrences go native. Vulkan modules 22 → 24, GDN family 6 → 8, 27B reference-tier ops 5 → 3.

Ported, not derived

Per-step arithmetic 1:1 from cpu_ops.cpp:1280-1311 GdnHeadTokenStep. Dispatch shape and state handling from the existing CUDA kernel cuda_gdn.cu:2417-2503 GdnDecodeFusedKernel: one workgroup per (sequence, value-head, BV-tile), the [BV,Dk] state slice staged into shared memory by a coalesced load and written back once, NW lanes per value row splitting the Dk contraction.

BV=16 / NW=8 is forced by Vulkan's guaranteed 16 KB shared budget at VT_TG=128 (BV=32 would need 18,048 B); the footprint is 10,304 B. Both .comp files share one step body so they cannot drift.

The one structural addition

CUDA's fused kernel is a decode kernel — its load/store pair brackets a single step. Prefill runs the same staged tile through the whole token range, so a 512-token prompt touches the [Dv,Dk] state twice instead of ~2048 times.

That is legal because the value row is an independent axis — row vi of S depends only on itself, k, q, decay, beta, v[vi] — which CUDA already exploits as its grid.x value tiling. Only sequence position is sequential, and it stays sequential inside the workgroup.

A latent seam defect fixed on the way

GetOpFallback threw for any native kernel that declines per-call: the reference tier installs only on a GetOp miss, and an op with a native kernel never misses. So a declining kernel had nothing to fall back to — defeating the entire point of decline-and-fall-back.

op_provider.cpp now installs the tier on that path and drains the backend before handing a host kernel device memory (GetOp's own drain keys on the selected provider, which here is the declining native one, so it never fired — a silent stale-read under command-buffer batching).

The pre-existing vt_paged_attn fp8-KV decline has the identical hole and had simply never been exercised.

Gates — re-run independently, not taken on report

test_vulkan_backend 25/25, 1020/1020 assertions. NMSE vs the CPU oracle (tolerance 5e-4):

case	NMSE
gdn_prefill out	1.47e-14
gdn_prefill carried state	6.43e-15
gdn_prefill bf16 q/k/v + bf16 out	0
gdn_decode (indexed cache) out	1.64e-14
gdn_decode (compact state) out	1.75e-14

Shapes are chosen against the tile: Dv=19 (3-row second tile), Dk=20 (lane 7 contributes an empty partial), one zero-length sequence, a negative state_idx, untouched cache slots memcmp'd. Every case asserts the mechanism as well as the numbers.

• opt-125m STRICT 6/6 token-exact (96/96), 0 declines
• Clean -Werror, 0 warnings; SPIR-V reproduces byte-for-byte

What is NOT claimed

• No speed number. llvmpipe only — no GPU here. The design's motivation is arithmetic from shapes (~100 GB of state traffic per 512-token prompt across 24 GDN layers, essentially all removed by the tile amortisation), not a profile.
• The chunked WY-representation prefill was NOT ported. llama.cpp turns the recurrence into batched matmuls over 64-token chunks; this does not. If the 27B re-run shows prefill still far off, that is the remaining lever and a separate row.
• Rejected: reassociating the two passes to read the state once — it moves numbers off the CPU reference's rounding for a saving that cannot be measured here.
• No maxComputeWorkGroupCount guard — decode passes 65,535 workgroups at batch ≳ 256. Flagged as a backend-wide gap (FlatGroupCount has the same hole), not fixed in this row.

Pre-existing red, not from this branch: check-fusion-consistency on gemma4_moe.cpp — verified identical on origin/main.

🤖 Generated with Claude Code

[localai-bot]

LANDED on main in merge commit 502bd779.

Gates re-run independently on a clean reconfigured build before merging, not taken on report: test_vulkan_backend 25/25 (1020 assertions), opt-125m STRICT 6/6 token-exact, 0 declines, clean -Werror. The op_provider.cpp seam change was read line by line — VT_CHECK(next != nullptr) at :389 does guard the deref at :399.

docs/BENCHMARKS.md is a keyed table and needed merge-by-key twice: this branch predates the ROCm row on main, so a union would have dropped it while a take-theirs would have reverted the new Vulkan counts. Kept main's rows and swapped in only the Vulkan one.

Pre-existing red, not from this branch: check-fusion-consistency on gemma4_moe.cpp — verified identical on origin/main before attributing.

Closing per the PR-disposition protocol.