Adding a couple keywords for searchability: Shader pre-cache on secondary Steam library folder.
I had the same problem with a non-default library folder, and after linking it to steam folder shadercache it stopped re-downloading it every reboot.
It took a minute of searching how to do it, and was relatively easy. I would honestly encourage any experienced PC users to try it on their own while waiting for a fix.
Steam shader pre-caching is useful, but the current all-or-nothing implementation is causing repeated large shader downloads and background processing for games that have not actually received game updates.
I am not asking for shader pre-caching to be removed. It clearly helps some games. For example, when I disabled shader pre-caching globally and launched Palia, the game was immediately choppy and stuttery. After re-enabling shader pre-caching and allowing Steam to process shaders, Palia ran smoothly again.
The problem is that the same global feature also causes repeated large shader pre-cache updates for games that are already cached and already running smoothly. Users currently have to choose between:
This needs more granular control and better cache management.
Steam showed Overwatch 2 as updating, but the content log showed this was a shader update, not a game content update. The game was already installed, already cached, and already running smoothly.
Steam downloaded and processed shader pre-cache data for Overwatch 2 even though the installed game build did not change.
The update committed into the shader cache folder:
/var/mnt/LINUX_FILES/SteamLibrary/steamapps/shadercache/2357570/
It did not commit new content into the game install folder:
/var/mnt/LINUX_FILES/SteamLibrary/steamapps/common/Overwatch
The Overwatch 2 shader cache folder was approximately 127 GB.
The shader cache folder also shows repeated large FOZ chunks over many days, including multiple large files on the same day.
From Steam content_log.txt, app ID 2357570 entered shader update state:
AppID 2357570 Shader update changed : Running Update
AppID 2357570 Shader update changed : Running Update,Downloading,Staging
Steam downloaded two large shader-cache payloads in one event:
AppID 2357570 update started : download 0/7651001136 ... stage 0/7929288501
Downloading 7562 chunks for depot 2357570 (2990925257385072349)
Then shortly after:
AppID 2357570 update started : download 0/2736801440 ... stage 0/3518479647
Downloading 3361 chunks for depot 2357570 (2223570305417626543)
Steam then committed the data into the shader cache folder:
AppID 2357570 starting commit from "/var/mnt/LINUX_FILES/SteamLibrary/steamapps/shadercache/2357570/downloads/" to "/var/mnt/LINUX_FILES/SteamLibrary/steamapps/shadercache/2357570/" : 1 updated, 0 moved, 0 deleted files
The installed game manifest still showed the game build as unchanged:
"appid" "2357570"
"name" "Overwatch®"
"buildid" "24244212"
After the shader pre-cache download, Steam started fossilize_replay:
Starting replay of FOZ databases for AppID 2357570 with fossilize_replay
Still replaying 2357570
If a game is already installed, already cached, and the game build, GPU, driver, Proton version, and local cache state have not meaningfully changed, Steam should avoid unnecessary large shader pre-cache downloads/reprocessing where possible.
At minimum, Steam should provide more user control so this can be managed per game.
Steam can download large refreshed remote shader blobs and replay/process them even when:
The only user-facing control is global, which is too blunt.
Disabling shader pre-caching globally is not a good workaround. In my testing, Palia immediately became choppy/stuttery when shader pre-caching was disabled, then became smooth again after shader pre-caching was re-enabled and Steam processed shaders.
So this is not a request to remove shader pre-caching. The request is for better control and pruning.
These appear related:
Your system information
Please describe your issue in as much detail as possible:
While my issue is briefly mentioned in this comment of issue 8076, I think it's also worth mentioning as a separate issue. As someone who uses a 5 TB external drive to store my Steam games, I would expect the Steam client to either recognize the contents of the partition's shader cache folder or automatically create a symlink to the main Steam installation's shader cache when installing a new game. Instead, the Steam client tries to scan the main Steam installation's shader cache, downloads to the external partition's shader cache, and starts downloading unnecessary texture cache to it whenever I open a game. I solved this by symlinking the external shader cache back to the main Steam installation's shader cache, but the average consumer should not be expected to set up such a hacky workaround.
Steps for reproducing this issue: