8
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
8 points (100.0% liked)
Linux Gaming
23791 readers
21 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.
Resources
WWW:
- Linux Gaming wiki
- Gaming on Linux
- ProtonDB
- Lutris
- PCGamingWiki
- LibreGameWiki
- Boiling Steam
- Phoronix
- Linux VR Adventures
Discord:
IRC:
Matrix:
Telegram:
founded 2 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.