102
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 31 Oct 2025
102 points (99.0% liked)
Linux Gaming
28090 readers
182 users here now
Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.
This page can be subscribed to via RSS.
Original /r/linux_gaming pengwing by uoou.
No memes/shitposts/low-effort posts, please.
That includes posts generated by LLMs. It doesn’t matter if you “don’t have the time” or “would’ve written the same anyway”, or if “everyone’s doing it geez get with the times”.
For now it’ll also include “AI”-assisted projects that haven't had at least two months of (public, verifiable) dev time behind them.
Resources
Help:
- ProtonDB
- Are We Anticheat Yet?
- r/linux_gaming FAQ
- Fork of an earlier version of the above
- PCGamingWiki
- LibreGameWiki
Launchers/Game Library Managers:
General:
Discord:
IRC:
Matrix:
Telegram:
founded 3 years ago
MODERATORS
Shaders have to be processed when the video drivers are updated, and time to process will depend from game to game, how many shaders there are. After they are processed, shaders can be cached and recalled without a performance hit. But the cache will be invalidated after a driver update.
If you skip preprocessing, you may see a hitch the first time a shader is used in a game scene. Like if you pick up a gun that shoots blue flames, and the game hasn't used the blue flames before - it has to process that immediately before displaying the blue flames - which takes a split second.
This realtime impact can be small or large, depending how many shaders load into a scene simultaneously. Loading a new map with lots of unique textures and unprocessed shaders is generally when you'll see the big hitches as it scrambles to compile them.
Any idea why this happens constantly without driver updates?
I ended up turning off shader-preprocessing because some games would sit and cook shaders for 10 minutes every time I boot them up, update or no.
I dont know the specific answer unfortunately, I suspect there is another layer to the caching story with Proton/Wine Prefixes/DXVK in Linux. If the translation layer gets an update independent of the graphics driver, that could maybe also cause a cache invalidation to occur. I notice that behavior more often when I'm using Proton Experimental.
Huh, that could be exactly it, actually. Experimental is usually my default Proton fork that I try first. Makes sense that it would catch frequent updates and then invalidate the cache. I'll try this again with GE-Proton and report back later if I remember to.
Experimental gets updated waaay more often than the other, stable branches, they don't push out a whole announcement every time.
So, every time one of those updates comes in, even if its just like 2.6 mb?
Time to potentially recompile all your shaders, for potentially everything.
I also use Experimental, but you gotta realize that by using it, ... you're a guinea pig.