Shader Compilation and Why It Causes Stuttering, Explained

devs are lazy children now who don't know what they're doing.
Nope. There is no free lunch.

More complexity = more costs.

The question is... which of the costs do you prefer to pay the most of. To ease the pain of one of the types of cost, one or more other type will have to be increased in painfulness.
 
Gaming booting for first time...

EULA

Accessibility

Brightness

Pre-compile shaders (recommended) - Yes/No

Main menu

Whats wrong with that?
 
What you need to explain is how games from a short time ago did not require pre-compilation of shaders, yet still ran well and had graphics that were not considerably worse than today's games.

My theory is that having powerful GPUs and consoles, plus FSR and DLSS has made devs lazy about optimization.

That's EXACTLY the issue!!

Game developers now think that huge amount of RAM / VRAM and powerful CPUs available in today's PCs will do the work for them.

Instead of writing tidy, efficient code, they rely on users' hardware and call it a day.

Developers in the 90s were masters at writing amazing code that had to deal with RAM measured in KB not Gigabytes and 286 CPUs!!
 
Developers in the 90s were masters at writing amazing code that had to deal with RAM measured in KB not Gigabytes and 286 CPUs!!
Nothing has changed. The more complexity is added to software, the more it bloats.

That code you cite as being so amazing would have been considered lazy bloated code by 1970s coding standards, which would, in turn, have been considered lazy and bloated by 1940s standards.

Here is the definitive quote, from the leader of the team that created FORTRAN in the 1950s:

.... While the community was skeptical that this new method could possibly outperform hand-coding, it reduced the number of programming statements necessary to operate a machine by a factor of 20, and quickly gained acceptance. John Backus said, 'Much of my work has come from being lazy. I didn't like writing programs, and so I started work on a programming system to make it easier to write programs.' ....

The target market does matter, of course, though. Each target market will bear a different level of code bloat/sloth. Enterprise systems that require responsiveness won't have the kind of code that powered Civ V, regardless of what decade we're talking about.
 
Last edited:
Alright, shader compilation is one of the causes that can contribute to stuttering.

But what about the huge elephant in the room - Windows 10 and later. You may have gotten used to it, but the truth is Windows 10 and later are terrible for gaming and are a huge contributor to stuttering, microstuttering, frame pacing and frame timing issues. For me, it instantly became apparent when I switched from Windows 8.1 to Windows 10, running the same games on the same hardware, I had to deal with a lot more stuttering, microstuttering and frame pacing issues, even after doing lots of advanced optimizations to the OS (disabling services, GPOs, registry edits, etc).

At least I'm glad RTSS (RivaTuner Statistics Server) exists, because for Windows 10 gaming it's a lifesaver. Just have it running with forced framerate and frame timing limits, and nearly all my microstutter and frame pacing issues on all games are gone. When I was on Windows 8.1 I only had to use it for some few problematic games, but on 10 I just leave it running on the background all the time. I have changed and upgraded my hardware since then but the microstuttering and frame pacing issues only became worse when I don't have RTSS on.
 
The developers, like many others, chose it to be this way; others do it at the main menu or in loading screens. It's the best way to ensure that the shaders are properly compiled before running the main graphics engine, as it can't tell if any changes to drivers, hardware, or other system files have taken place since the last time the game was played.

This seems like such a trivial thing ... can't the game or main graphics engine just check the system information to get all the necessary info, and then compare it with the info from when the shaders were compiled last time ?

Additional question:
Is there a noticeable difference in compiling time (or compiling stutter) related to different graphic cards or drivers ? ... could be interesting to do some tests to analyze this :)

What's happening is the graphical detail in games has gotten so complex that shader compilation is actually becoming a performance bottleneck ...
That's an interesting take, the technology used for years is now reaching a point where it is causing issues ... will be interesting to see where this leads to: optimizations of current tech, or something new ?
 
All credit to Nick Evanson, that is by far the best explanation of what shaders are that I've read. Other authors drop in lingo related to the DirectX API leaving the curious reader having to refer to other articles to make sense of what they've read, and those articles then contain more lingo, requiring the reader to reference yet more material. In the end one just gives up in favour of watching Youtube videos.

 
Not really, Old games typically used fixed-function pipelines where the graphics hardware had a limited set of operations it could perform. These operations were hard-coded into the GPU and executed in real-time during the game. There was no need to compile shaders as they were not used in these fixed-function pipelines.
Depends on how old one is talking about. In the first days of D3D or OpenGL, games weren't being written using the fundamental operations, in binary code, that GPUs run on -- it all still needed to be compiled.

However, modern games use programmable pipelines where the graphics hardware can execute custom shaders. These shaders need to be compiled before the game can use them. Pre-compiling the shaders allows the game to optimize the code and reduce the overhead of compiling the shader during gameplay.
In D3D, OGL, and Vulkan, one can choose to compile shaders into binary objects during the build of a project or code it so that it takes place during run time. In turn, these binary objects need to be processed/compiled by the GPU drivers, simply because such objects don't contain the actual micro-op code the processors work with.

I know this is simply a case of semantics, I.e. if a game has been coded in such a way that shader objects are created at run time before the GPU then compiles them, then that could be classed as pre-compilation.

This seems like such a trivial thing ... can't the game or main graphics engine just check the system information to get all the necessary info, and then compare it with the info from when the shaders were compiled last time ?
That's actually quite a lot of info to process and check (drivers, multiple OS files, API dlls, game version, all the shaders compiled so far). It's probably just as quick to compile them again.

Is there a noticeable difference in compiling time (or compiling stutter) related to different graphic cards or drivers ? ... could be interesting to do some tests to analyze this :)
Without access to exactly how and when a game and the GPU drivers are compiling shaders, it would be very difficult to accurately measure that time period. That said, there will be some differences between the performance of AMD, Intel, and Nvidia's driver compiler but probably not to any degree that would be noticeable to the end user.
 
Depends on how old one is talking about. In the first days of D3D or OpenGL, games weren't being written using the fundamental operations, in binary code, that GPUs run on -- it all still needed to be compiled.


In D3D, OGL, and Vulkan, one can choose to compile shaders into binary objects during the build of a project or code it so that it takes place during run time. In turn, these binary objects need to be processed/compiled by the GPU drivers, simply because such objects don't contain the actual micro-op code the processors work with.

I know this is simply a case of semantics, I.e. if a game has been coded in such a way that shader objects are created at run time before the GPU then compiles them, then that could be classed as pre-compilation.


That's actually quite a lot of info to process and check (drivers, multiple OS files, API dlls, game version, all the shaders compiled so far). It's probably just as quick to compile them again.


Without access to exactly how and when a game and the GPU drivers are compiling shaders, it would be very difficult to accurately measure that time period. That said, there will be some differences between the performance of AMD, Intel, and Nvidia's driver compiler but probably not to any degree that would be noticeable to the end user.
I think what you're implying is more a matter of context and language rather than misinformation. At the end of the day we are saying the same thing.
 
I see the problem but dont really understand all the yelling about it.

a game like atomic heart, hogwarts legacy, CoD, whats the big deal letting the game sit for 5 minutes to square away some software?

for the other games just sit back and wait for a performance patch I guess, but that probably wont happen since gamers seem rabid and need to buy every game as soon as the clock strikes midnite.

leave the games to wither on the vine and maybe devs will actually care about releasing quality products but since gamers are dense and clap for stuff like early access and its ilk I'll just get used to dealing with issues like these.
 
For an example of how NOT to manage shaders, one need look no further than Borderlands 3. That game stutters so badly that it is unplayable in either DX11 or DX12. There are countless "fixes" online. None of them work, even an a PC with a 5800X, 32 GB, RX6600-XT, and NVMe.

The game runs just fine for me. You failed to mention what your graphics settings are.

However for me I using 5600x, 32gb ram, rx6800xt, nvme drive,.
Graphics settings:
Dx12, latest drivers, 3440x1440, high settings, and I average 100FPS with jumps as high at 150fps.

How about resetting your settings, updating your drivers, and set your grapics resulution to match your monitor and set the quality to low, see how that works, then bump it up to medium and trying it again.

If you're try to game a 4k and best quality the graphics card simply can't do it. Sorry.
 
What you need to explain is how games from a short time ago did not require pre-compilation of shaders, yet still ran well and had graphics that were not considerably worse than today's games.

My theory is that having powerful GPUs and consoles, plus FSR and DLSS has made devs lazy about optimization.
Pre DX12/Vulkan games also required shader compilation. With DX11 games the most expensive part of the shader compilation could be done ahead of time. Compiling DX11 shaders was not GPU/Driver specific like DX12/Vulkan so they could compile once and ship the cache with the game. Your driver would then still need to do a small amount of work to convert this to work with your specific GPU/Driver but it's mostly unnoticeable.

With DX12/Vulkan the shaders themselves can potentially be much better optimized to perform better once compiled, but a side effect of this is that they are GPU/Driver specific so they cannot be compiled ahead of time and distributed with the game. All it would take is for a new driver to be released and the cache becomes invalid. Consoles don't have much variety in hardware or drivers so it's easy to precompile for all the potential GPU/Driver combinations and distribute the cache with the game.
 
Last edited:
What you need to explain is how games from a short time ago did not require pre-compilation of shaders, yet still ran well and had graphics that were not considerably worse than today's games.

My theory is that having powerful GPUs and consoles, plus FSR and DLSS has made devs lazy about optimization.

Why do you think Mantle or Vulkan was released for?

It would extract the best possible out of the hardware, and not waste resources or unneeded calls like in the case of <DX11 was.

Shaders are required; so does compiling these. But you can tweak the proces; you got options in your drivers for it you know.

 
Does having a faster cpu or nvme drive accelerate the speed of shader compilation process?

It does. The Dead Space remake requires and SSD. The first time I ran it on my new 7900x and 7900xtx build it was a stutter mess. I get pauses anytime I transition to a new area. I have a pci 4 nvme drive.

A recent Moores Law is Dead podcast had a video game console guy on. Consoles are optimized for gaming. GPUs have direct access to storage and shared RAM. This tech means that consoles are much more efficient as a purpose built machine. With the console SOC becoming more powerful with each gen we are really seeing the limits of PC architecture. A PC needs to have the CPU pull from storage, process the data, and then get it to the GPU before anything is actually computed visually. A console on the other hand allows the GPU to do all that work. If. Game is sub-optimally threaded or coded in a way that doesn’t anticipate what’s needed next you get these stutters.

Sony touted its SSD tech as being fast enough to stream from for fast loading on the fly before PS4 launch. Adored TV had a cool video on it.

Basically, we are seeing a big change in gaming. Those with $4k to throw at a system will always do better than consoles but long gone are the days of a budget computer keeping up with a console. I expect that the future will most certainly be consoles plus cloud gaming with only a small minority able to brute force good graphics with a PC. I think my new build is my last high power build.
 
Back