perf(vk): FSR 3.1's passes go through the pipeline cache kept across runs #1574

Merged
NotRexed merged 2 commits from perf/fsr3-pipeline-cache into main 2026-11-10 16:52:56 +00:00
NotRexed commented 2026-11-10 09:14:08 +00:00 (Migrated from github.com)

FSR 3.1 made its dozen compute passes with no pipeline cache (VK_NULL_HANDLE), so they were compiled again on every start, inside the first upscaled frame. In tonight's proof run on an RTX 4060 Ti at 2560x1440, the first frame of play took 2,690 ms with FSR 3.1, against about 1,020 ms without it (the same area-load uploads in both).

They now go through the pipeline cache the game's own pipelines use, which is saved across runs (mkw_vk_pipelines.bin), via a small accessor, shared_pipeline_cache(), in vk_draw.cpp. That cache is internally synchronized (it isn't created with the externally-synchronized flag). Before it's loaded, the accessor returns VK_NULL_HANDLE, as before.

Tested so far: the change is mechanical (two calls and an accessor). CI compiles it. The in-game check, the second start's first FSR frame, is queued tonight.

🤖 Generated with Claude Code

FSR 3.1 made its dozen compute passes with no pipeline cache (`VK_NULL_HANDLE`), so they were compiled again on every start, inside the first upscaled frame. In tonight's proof run on an RTX 4060 Ti at 2560x1440, the first frame of play took 2,690 ms with FSR 3.1, against about 1,020 ms without it (the same area-load uploads in both). They now go through the pipeline cache the game's own pipelines use, which is saved across runs (`mkw_vk_pipelines.bin`), via a small accessor, `shared_pipeline_cache()`, in `vk_draw.cpp`. That cache is internally synchronized (it isn't created with the externally-synchronized flag). Before it's loaded, the accessor returns `VK_NULL_HANDLE`, as before. Tested so far: the change is mechanical (two calls and an accessor). CI compiles it. The in-game check, the second start's first FSR frame, is queued tonight. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
hckrman101 (Migrated from github.com) approved these changes 2026-11-10 16:39:30 +00:00
hckrman101 (Migrated from github.com) left a comment

Looks good. The accessor sits in namespace mkwvk, outside the unnamed one, and matches the forward declaration in vk_fsr3.cpp. Both vkCreateComputePipelines calls now get the shared cache. It's created without the externally-synchronized flag, so passing it from the FSR path is fine, and before pcache_init it falls back to VK_NULL_HANDLE as before. CI is green on Linux and Windows.

Nit: FSR builds don't bump pcache_built_since_save, so the 32-pipeline threshold in the save path won't count them. They'll only reach the .bin if the game's own pipelines push it over the threshold or a forced save runs at exit. Worth checking on the second-start FSR frame you have queued. If it's still slow, bump the counter after these two calls.

Looks good. The accessor sits in namespace mkwvk, outside the unnamed one, and matches the forward declaration in vk_fsr3.cpp. Both vkCreateComputePipelines calls now get the shared cache. It's created without the externally-synchronized flag, so passing it from the FSR path is fine, and before pcache_init it falls back to VK_NULL_HANDLE as before. CI is green on Linux and Windows. Nit: FSR builds don't bump pcache_built_since_save, so the 32-pipeline threshold in the save path won't count them. They'll only reach the .bin if the game's own pipelines push it over the threshold or a forced save runs at exit. Worth checking on the second-start FSR frame you have queued. If it's still slow, bump the counter after these two calls.
Commenting is not possible because the repository is archived.
No description provided.