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?
There is a better way. Instead of compiling when you launch the game, you can enable background processing of shaders. This will happen while you’re not gaming. If you don’t do other stuff on that computer while you’re not gaming and it is turned off or asleep instead, it might not help.
The only times my shaders get recompiled is after a Steam game updates or I get a Linux firmware update. I usually run Steam on a second desktop after I boot and am planning to play games later.
I also have the System Info widget, running in the Taskbar on my main desktop, set to show CPU usage. When the CPU usage drops to near zero, I know at a glance when the shaders are done compiling. (It usually doesn’t take more than 5-6 minutes).
Well, you can play the game without it, as others have stated, you should really leave it on. First of all, all of that work needs to happen then later when you’re playing the game, which is just going to lead to a subpar experience with random framerate drops that cannot be explained. From Software’s Elden Ring had a problem at launch with that. Every time a new effect or literally anything in the game was done, you’d wait for half a second and that would sometimes make your game into a slideshow for seemingly no reason. Or the Nier replicant remake wouldn’t play the pre-rendered cutscenes if you didn’t enable it. Most games don’t care, however. But for the sake of stability, my recommendation is to leave it on. It only takes a long time when you boot something up the first time, and with modern games being unoptimised as well, do yourself a favour and leave it on.
It is the first thing I disable after a new Steam installation, I have been dpoig that for years and i don’t see much difference, ay least in the titles i play and the hardware I have (R5 5600X now 7600X with RX6800 and 16 now 32GB RAM)
Shaders are the tiny programs that generate a lot of the graphics you see in modern games. They have to be compiled into machine instructions in order to run on whatever hardware you have. Compiling each one takes a little time. Some games compile them all at once when you launch the game, so that they’re ready to go when needed during gameplay, while others let the graphics driver compile them on demand, which can lead to unpleasant frame rate hitches.
Steam’s Proton tries to help with this process by keeping tabs on the shaders that a game needs, compiling them for your hardware before launching the game, and collecting the compiled versions for use by other players with similar hardware. If someone has played the game with Proton before you, then Steam will give you copies of their shaders, so you don’t have to spend as much time waiting for your machine to compile them. (If this processing step is taking forever, it’s possible that you’ve encountered a bug, or a problem with the network or Steam’s servers.)
You can skip that step and jump right into the game, but then you might find the game’s frame times feeling stuttery or even pausing for seconds at a time while the shaders compile on demand. It won’t harm your system, but it can be annoying and make it hard for you to perform well in competitive action games. If you play through it for long enough, all the shaders that get used will eventually be compiled, and things will run smoothly thereafter.
Well, the problem I have is that the games that need pre-processing do it every time I launch the game.
It wouldn’t surprise me if it processed vulkan shaders briefly every time, to check for recently used ones and upload them to Steam.
If it’s taking more than a few seconds every time, I would guess that either your last play session triggered a bunch of new shaders (for example if you explored a new area that used different visual effects), or you’ve stumbled upon a bug.
If you think it’s a bug, you should consider checking for reports on Valve’s issue tracker entry for that game, or on the Steam for Linux issue tracker if it affects many games. If there are no reports already, consider creating one.
Since you seem to know way more than me about these things, could you tell me why I feel like I’ve never experienced these on a console (Playstation) and I experience it quite often on PC (Steam Deck)?
Console games only have to deal with a fixed set of hardware, so they come with precompiled shaders for that hardware. PC games don’t know what they’re going to run on, so the shaders are compiled on the machine where the game is played.
So how come this is not a thing in Windows? I switched to Linux earlier this year and I see this compilation prompt each time a launch a game. But I have never seen it on Windows.
It’s possible that I have this “use precompiled shaders” feature enabled on my Windows installation but not on Linux i guess. But I have literally never seen it on windows for any game on any launcher.
I am also curious as to why these shaders are not just compiled once with the first installation of the game (or once per update)
Actually, a lot of modern games on Windows suffer from micro stutters and frame hitching because it’s often compiling on demand if shader compilation isn’t built in upfront in the game. A lot of games run smoother on Linux with proton because of the shader precompilation.
Also, a lot of games hide it in load screens and don’t explicitly tell you. If you’ve ever updated a game and first run seems to be slower to load, that’s the game compiling shaders for you.
To add to what the others have said, shader compilation is enough of a problem on Windows that Microsoft is working on a system to deliver precompiled shaders from the cloud for supported games on supported hardware.
I experience it quite often on PC (Steam Deck)?
Because you disabled download of precompiled shaders off Steam after you were annoyed by these 100kb updates that tend to show up on Steam Deck more or less often. The option is only shown in the desktop UI of Steam, not in Game Mode:
I haven’t changed anything on my Steam Deck, so no😅
Edit: I might also be mistaking the vulkan shader step with some other validation step
Oh so that’s what those little updates are that always seem to pop up? Good to know!
Oh so that’s what those little updates are that always seem to pop up? Good to know!
There are others as well but on Steam Deck the shaders are by far the most prominent of those. I’m not sure what the others are and how many of those are because the developer changed anything or if some are autogenerated by something on the Steam store back-end.
Since a console is a lot more standard than a PC the the console/game maker can generate them and you just download that as an update for the game.
Steam Deck usually has precomputed shaders as well, so it’s unclear why you’re having that problem on Steam Deck, unless you are running an unusual os. I suppose they could be less mainstream games, too.
Maybe if you are using a beta of proton or similar that could case it too.
I, for one, enjoy continuing to run every single weird kind of windows program through Proton Expirimental, on my Deck, running on Bazzite.
I may have escaped GlAdOS, but I’ll be damned if I ever stop testing.
Every unit of a given console contains the same graphics hardware, so a single version of a game’s shaders can be compiled and shipped with the game, and they will run on every console of its kind.
(Also, early consoles didn’t use shaders.)
PC graphics hardware varies a lot, so shipping precompiled shaders with the game would require the developers to collect samples of all the world’s PC GPU families, compile the game’s shaders for each one, and ship all those compiled versions of all those shaders with the game. That would be impractical.
(The variance is arguably even greater in Linux gaming, which often involves graphics API translation, which can affect compiled shaders.)
It could be done for the Steam Deck, since every Deck has the same graphics hardware, if game developers & publishers were willing to make and distribute Deck-specific builds. However, that would rather defeat the Deck’s advantage of being able to run just about any PC game unmodified. Steam’s “processing Vulkan shaders” step is designed to more or less accomplish the same thing, at least for popular games.
It could be done for the Steam Deck, since every Deck has the same graphics hardware, if game developers & publishers were willing to make and distribute Deck-specific builds.
Valve does it. They show up as updates and get downloaded off Steam. It’s optional but it’s enabled by default. Parent poster has disabled it at some point and forgot about it.
The last sentence of the comment to which you replied covers this. What Valve does here is not the same thing, since it doesn’t involve the game developer or publisher, and doesn’t work for non-Steam games, and happens as an extra step. But it does come close to achieving the same effect (when it works), and it is pretty cool.
Edit: Graphics software enthusiasts who find the process interesting might want to check this out:
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.
If shaders don’t get preprocessed, then a lot of the same work has to happen later, it just shows up as a seemingly random frame that takes particularly long to render.
(edit to add:) or a section where some of the rendering doesn’t look quite right initially, if they do asynchronous rendering.
In the limit, the sum of all these delays can add up to the same amount of time that the preprocessing WOULD have taken, but you also don’t necessarily use every shader every time you play every game, so YMMV.
When I was on windows I also had to recompile shaders after a driver update. I also experience this, and have just assumed it was from a driver update.
Yeah, I’d be interested in that as well!
