perf(vk): FSR 3.1's passes go through the pipeline cache kept across runs #1574
No reviewers
Labels
No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
No milestone
No assignees
1 participant
Due date
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot!1574
Loading…
Reference in a new issue
No description provided.
Delete branch "perf/fsr3-pipeline-cache"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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(), invk_draw.cpp. That cache is internally synchronized (it isn't created with the externally-synchronized flag). Before it's loaded, the accessor returnsVK_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
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.