this post was submitted on 31 Oct 2025
96 points (99.0% liked)

Linux Gaming

22273 readers
134 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:

Discord:

IRC:

Matrix:

Telegram:

founded 2 years ago
MODERATORS
monolalia@lemmy.world
96
Do Vulkan shaders need to be processed before every game? (lemmy.world)
submitted 4 weeks ago by ArchmageAzor@lemmy.world to c/linux_gaming@lemmy.world
28 comments fedilink hide all child comments
 

Often when I launch a game through Steam that "processing Vulkan shaders" window appears and loads for a couple minutes. Sometimes it takes no time, sometimes it takes several minutes. But then, for larger games like Dune Awakening or Outer Worlds 2, the game needs to sit and process shaders for another couple minutes anyway. But for some games, like Enshrouded, I can skip the Vulkan processing with no problems in the game (I do that because the Vulkan processing doesn't go anywhere). So what is that Vulkan processing for?

you are viewing a single comment's thread
view the rest of the comments
[–] CaptDust@sh.itjust.works 9 points 4 weeks ago* (last edited 4 weeks ago) (1 children)

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.

[–] skulblaka@sh.itjust.works 7 points 4 weeks ago (1 children)

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.

[–] CaptDust@sh.itjust.works 5 points 4 weeks ago* (last edited 4 weeks ago) (1 children)

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.

[–] skulblaka@sh.itjust.works 5 points 4 weeks ago (1 children)

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.

[–] sp3ctr4l@lemmy.dbzer0.com 1 points 4 weeks ago

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.