vulkan: fuse GATED_DELTA_NET state write into recurrent cache

[PrajwalMukatti]

Closes #27193.

What

The CUDA and SYCL backends already fuse the GATED_DELTA_NET → CPY pattern: rather than writing the recurrent-state snapshots into dst and then copying them into the recurrent cache with a separate CPY node, they detect the pattern at graph-build time and write the state straight into the cache buffer from the op itself (ggml_cuda_try_gdn_cache_fusion / ggml_sycl_try_gdn_cache_fusion).

Vulkan was the only major backend missing this, so every decode step runs an extra CPY per GDN layer (48 per token for Qwen3-Next / Qwen3.8-class models). This PR adds the same fusion to the Vulkan backend.

How

• ggml_vk_try_gdn_cache_fusion() — detects a GATED_DELTA_NET immediately followed by a CPY of its state-snapshot tail into a recurrent-cache view, using the same structural checks as the CUDA/SYCL versions, and returns how many nodes to skip.
• gated_delta_net.comp — gains a second storage buffer (binding = 7, CacheBuf) and a state_out_off push constant. When state_out_off > 0 the shader writes the state snapshots directly into the cache at that offset; when 0 it keeps the original behaviour (write into dst at s_off). A +1 sentinel keeps offset 0 unambiguous.
• ggml_vk_gated_delta_net() — binds the cache buffer and sets the offset when the fusion fired; otherwise binds dst as a dummy and leaves state_out_off = 0 (non-fused path unchanged).
• GGML_VK_DISABLE_FUSION=1 forces the non-fused path, mirroring GGML_CUDA_DISABLE_FUSION, for A/B verification and as a driver kill-switch.

The diff is 73 lines across the two files; the non-fused path is byte-for-byte unchanged when the fusion doesn't fire.

Verification status (why this is a draft)

• ✅ Builds cleanly at master.
• ✅ test-backend-ops -o GATED_DELTA_NET passes on the CPU backend.
• ⚠️ The Vulkan-device A/B (fused vs GGML_VK_DISABLE_FUSION=1) has not yet been run on real hardware in CI — the CI runner exposes no Vulkan device (lavapipe did not initialise), so test-backend-ops fell back to CPU. I'm opening this as a draft to (a) get review of the approach, and (b) ask for help verifying on real GPUs. It was developed against a Radeon 890M (gfx1150 / RDNA3.5) but I'd like independent confirmation on other Vulkan drivers/vendors before it leaves draft.

Feedback on the shader binding approach and the sentinel scheme especially welcome.

[ggml-gh-bot]

Hi @PrajwalMukatti, thanks for your contribution!

Per our contribution guidelines, the automated PR checker found the following issue(s) that need your attention:

• PR Template not respected: Please respect the template when creating a new pull request. Make sure to fill out all required sections.

• AI-generated content: While code is allowed to be generated by AI, please write the PR description and commit messages on your own without the help of AI.

---

Please note that maintainers reserve the right to make final decisions on PRs. If you believe there is a mistake, please comment below.

[jeffbolznv]

you should do this in a way that's more consistent with the existing fusions.

[randomm]

Real-hardware test on Strix Halo (AMD Ryzen AI Max+ 395, Radeon 8060S, gfx1151), since this branch specifically wants that.

Built from this PR vs a master baseline build, bench-sweep -r 3 (llama-bench), model Qwen3.8-Flash-Next UD-IQ3_XXS, -ub 2048 -fa 1 --no-mmap -ngl 999:

depth	metric	master	this PR	delta
0	pp	431.82 ± 2.30	422.01 ± 6.27	-2.3%
0	tg	30.54 ± 0.02	30.42 ± 0.11	-0.4%
4096	pp	377.07 ± 0.14	372.10 ± 4.20	-1.3%
4096	tg	24.19 ± 0.04	24.27 ± 0.06	+0.3%

No measurable win or loss here — all deltas are within noise on this quant/workload. Happy to test a different model/quant or config if useful.