System: Arch Linux, RTX 4060 Laptop, NVIDIA 615.71.09, Steam 1.0.0.87. THE FINALS (2073850) on GE-Proton10-34.
__GL_SHADER_DISK_CACHE_SIZE=48000000000 and __GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1 are set system-wide in /etc/environment, so driver-side pruning (#11392) is ruled out.

What happens

The game's NVIDIA cache was already warm: shadercache/2073850/nvidiav1/.../steamapp_merged_shader_cache.bin, 4.3 GB. On client start Steam committed updated swarm manifests (shader_log.txt):

[2026-09-25 16:43:08] Committed bucket 70016911 (AppID 2073850) from 5598895753320162954 to 2120673634056925331   671869244 -> 698948452 bytes
[2026-09-25 16:43:28] Committed bucket 58939956 (AppID 2073850) from 1103862913764927276 to 3435466674086516885  2150571935 -> 2155141088 bytes

That is about 31 MB of new Fossilize data. On game launch Steam then replayed the whole database:

[2026-09-25 16:55:03] Starting processing job for app 2073850!
[2026-09-25 16:56:08] Still replaying 2073850 (66%, 0/317613).
[2026-09-25 17:02:00] Still replaying 2073850 (83%, 114315/220811).

In those 7 minutes (I stopped it at about half), the driver wrote about 1.2 GB of new cache (steamapp_shader_cache0..14.bin) next to the existing 4.3 GB merged file. On this machine the whole Fossilize database (~2.85 GB) compiles to ~4.3 GB of driver cache, about 1.5×. So ~31 MB of new Fossilize data should yield on the order of 50 MB, not 1.2 GB in half a run. That looks like pipelines already in the cache being compiled again.

The day before, Steam's own merge of this cache logged Mismatching key! 15,039 times (Processing NVIDIA cache file ... steamapp_merged_shader_cache.toc, 2026-09-24 15:19 and 20:00). I can't tell whether those entries are dropped.

To the user this looks like: switch games, restart Steam, and the game you already warmed up is "processing Vulkan shaders" again for roughly a quarter of an hour.

Evidence that the existing cache is enough

I disabled pre-caching and pointed the driver at a copy of the same nvidiav1 directory through a launch-option prefix, using Steam's own cache names:

export __GL_SHADER_DISK_CACHE_PATH=~/.local/share/shader-keep/$SteamAppId/nvidia   # copy of shadercache/<appid>/nvidiav1
export __GL_SHADER_DISK_CACHE_APP_NAME=steamapp_shader_cache
export __GL_SHADER_DISK_CACHE_READ_ONLY_APP_NAME=steamapp_merged_shader_cache

The game opens steamapp_merged_shader_cache.bin read-only. Its own PSO preload then wrote 0 bytes of new cache. The same preload wrote 413 MB when APP_NAME was wrong and the old cache wasn't seen. Switching between two games no longer triggers anything.

Request

Not new behaviour: please stop re-doing (or possibly invalidating) shaders that are already compiled locally. Fossilize can already skip known pipelines: the fossilize_replay bundled with Steam has --on-disk-replay-whitelist, and Steam keeps replay_cache.*.foz next to the database. A bucket update should cost the replay of what changed, not a full re-run over a warm cache. Until then the only reliable option on NVIDIA is to turn pre-caching off, which gives up its benefit for new content.

Related

• #8076 covers the symptom ("downloaded and compiled after every reboot"). This issue narrows it to one mechanism, with log lines and a byte-level measurement: a small bucket commit leads to a full replay over a warm cache.
• #11392 is NVIDIA driver pruning. Ruled out here (48 GB limit + SKIP_CLEANUP system-wide, merged cache intact), so the remaining cost is on the Steam side.
• #9803 reports precompiled caches landing where the NVIDIA driver never reads them. It's the same class of problem: the driver only reads files whose names match __GL_SHADER_DISK_CACHE_APP_NAME / READ_ONLY_APP_NAME, and a mismatch there produced the 413 MB recompile above.
• ValveSoftware/Proton#7176 ("Processing vulkan shaders every time I launch a game") was closed, but the behaviour still reproduces with Steam 1.0.0.87.

Happy to provide full shader_log.txt excerpts or run test builds.