Pre-compiled shader cache cleaned by nvidia driver, causing stutter when launching vulkan apps

Graphics / Linux Linux
1

This is basically referring to an existing report: https://github.com/ValveSoftware/steam-for-linux/issues/11392

When launch steam games, game itself compiles shader cache at first launch and cache were stored. However, when launching the game again, the existing shader were deleted by nvidia driver due to exceeding driver’s openGL/vulkan shader cache size limit, back in driver 460 this was increased from 128 M to 1024 M, but modern games with dxvk or vkd3d tends to ahve bigger shader cache, leading to this problem.

In this forum article https://forums.developer.nvidia.com/t/opengl-shader-disk-cache-max-size-garbage-collection/60056/18, __GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1 was mentioned, also __GL_SHADER_DISK_CACHE_SIZE= mentioned in the github issue above, these 2 environment variables should able to change driver’s shader cleanup behavior, but they didn’t work.

Here are my test steps:

  1. Start the game for the first time. Game compiles shader.
  2. Close the game and start it. The shader compiled before was deleted then being compiled again.
  3. Repeat step 2, same beahvior.

This result happens with conditions below, or in other words, these condition leads to the same result above:

  1. launch the game with no env;
  2. launch the game with __GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1;
  3. launch the game with __GL_SHADER_DISK_CACHE_SIZE=10737418240;
  4. launch the game with __GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1 __GL_SHADER_DISK_CACHE_SIZE=10737418240

From the github issue above, this was tracked by nvidia internal bug 4932793 and 4934720.

Here is my nvidia bug report log:
nvidia-bug-report.log.gz (506.2 KB)

I hope this could help you resolve the problem why shader cleanup beahvior cannot be changed.

2

Update:

When env __GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1 is being set system-wide (for example, /etc/environment), it do make nvidia driver not to chean shader cache. (I forget to note above in my post that, I set these env in steam’s game launch command)

Is this behavior expected?

3

I saw this issue was still open and I wanted to post because this is still happening in 2026. I will post both here and the related NVIDIA forum. (ValveSoftware/steam-for-linux#11392 | internal NVIDIA bug 4932793)

I think this must be happening to most people attempting to play Overwatch, or any game with really large shaders, on most linux distros with NVIDIA gpus. From my research, AMD gpus have a bigger shader cache allocation by default and don’t have this issue. I tried many launch options, using DX12, and different proton versions and other things in a attempt to get this working. The solution below (See “Fix:”) was the only thing that worked.

System:

  • GPU: RTX 3060 Ti
  • Driver: 610.43.03 (also happened on earlier 5xx drivers)
  • OS: Fedora 44 (x86_64)
  • CPU: Ryzen 5700G
  • Game: Overwatch 2 via Steam, GE-Proton11-1
  • Steam Launch Options: DXVK_HUD=compiler - Displays a message when shaders are compiling
    DXVK_CONFIG=“dxvk.trackPipelineLifetime = True” - Fixes a separate memory leak issue
    PROTON_ENABLE_NVAPI=1 - DLSS Compatability
    gamemoderun - for linux gamemode
    %command%

Reproduction:
Every game launch triggers a full shader recompile — 100% CPU for 15+ minutes on all cores. The game is unplayable during this period. After the compile finishes, gameplay has occasional hitching as additional shaders compile on-demand. This happens on every boot, not just after driver/game updates.

Steam’s shader pre-caching also does not work: it takes ~3 hours to complete, has zero effect on the in-game compile, and re-runs the full 3-hour process on every subsequent boot. Steam’s precache was about 20GB on my machine and persisted, but it still wanted to rerun the preaching each time the game started.

What I believe to be the root cause:
The NVIDIA driver’s shader disk cache (~/.cache/nvidia/GLCache/) is limited to 1GB by default. Overwatch has a lot of shaders, which may or may not exactly be optimized, and it’s shader cache exceeds this limit. From my monitoring of the folder during shader compilation, it builds until it reaches exactly 1GB and then is capped there (even though the game reports shader compilation). My guess is it continues to replace existing shaders as it continues to compile. The game then runs with poor performance and frequent hitching. My guess is it continues to compile missing shaders, and replacing old ones at the same time, staying in a bad loop.

I was also able to capture the deletion of the shaders upon game boot with: inotifywait -m -r ~/.cache/nvidia/GLCache/ -e delete --format ‘%w%f %e’
I’m assuming the cache is invalidated due to it not being imcomplete and rewritten over in the above mentioned loop, so the game just recompiles from scratch.
System reboots seemed to mostly clear out the shader directory when I checked on the folder.

Fix:
Setting this system-wide in /etc/environment and rebooting fixed the issue completely:
__GL_SHADER_DISK_CACHE_SIZE=10737418240
__GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1
The game had to compile shaders for about 15 minutes as usual, but now there are no issues and no hitching in the game. This fix persists even when restarting the game, or rebooting the machine. I also tested afterwards removing this entry and it reproduced the problem.

Note: This must be set system-wide. Setting them in Steam’s per-game launch options had did not have the same effect. The __GL_SHADER_DISK_CACHE_PATH variable in launch options also did not help. Additional details below:

Steam Launch Options Effects:
10 gb cache size only - Would grow above 1GB but be cleaned out between game startups and system reboots.
10 gb cache size and skip cleanup - Would grow above 1GB and persist between game startups. Gets cleaned with system reboot though.

/etc/environment effects:
10gb cache size only - grows above 1GB and persists between game start ups. Restarting the machine left the cache in place, but booting the game caused it to compile shaders again. The old shaders seemed to remain, but they were ignored.
10 gb cache size and skip cleanup - Fixes the issue as described above

4

I am very interested in this because I use DX12 in Overwatch and only recent saw the game become unplayable on an old CPU. I even tried leaving it running in Vulkan shader precompile for around 9 hours (got stuck at 99% near the end), and on the main menu idling (used 60% or more CPU for like 8 hours and still seemingly didn’t compile everything).

I wonder if there’s something in the game code that uses high CPU even on the main menu. There are lots of recent Overwatch bug forum posts about players having freezes or very low performance.

Thank you for the note about /etc/environment because I normally use Steam game launch options to try to expand the cache and prevent cleanup, and now I’m wondering if that isn’t working.

5

An update for whoever owns the internal bug for this thread. The shrink of Steam’s precompiled cache turned out to be more than size-based pruning. It is a 4 GiB offset wraparound in the file Steam’s merger builds:

  • A .toc entry is a 16-byte key + u32 offset + u32 size. Steam merges NVIDIA cache fragments into a single steamapp_merged_shader_cache.bin that grows past 2^32 bytes, so later entries get wrapped offsets. Overwatch 2, RTX 4090, 615.78.08: 5,370,772,223 B merged file, 50,673 of 262,547 entries match only at stored offset + 2^32, 0 unmatched. Same result on CS2 (native) from another user.
  • With __GL_SHADER_DISK_CACHE_PATH pointed at a private dir, out of reach of Steam’s merger, the cache stays warm across relaunches (0 bytes of new cache in the first 3 minutes).

Details and the checker: NVIDIA shader cache: shadercachemanager merge logs "Mismatching key!" and shrinks steamapp_merged_shader_cache.bin (cold cache after every exit, follow-up to #11392) · Issue #13622 · ValveSoftware/steam-for-linux · GitHub and GitHub - yotamleo/nvidia-steam-shader-cache: Diagnostic toolkit for Steam's NVIDIA shader-cache merge bug on Linux (4 GiB TOC wrap, steam-for-linux#13622) · GitHub

Two questions for NVIDIA, since Valve labeled the Steam issue NVIDIA drivers:

  1. Is the u32 offset a hard limit of the cache format, so that any single cache file must stay under 4 GiB? A confirmation here would let Valve fix the merger on its side.
  2. Is the list separator for __GL_SHADER_DISK_CACHE_READ_ONLY_APP_NAME officially ;? It is undocumented; a comma list is silently ignored (tested with vulkaninfo --summary and inotify: a,b, a:b, a b open nothing, a;b opens both).