Shader Compilation on PC: About to become a bigger bottleneck?

Yea, Epic getting UE shader compilation in order will help a large swath of games right there. But there's plenty of work to be done yet.

And yes, the other content creators need to step up. They make large amounts of money off the back of hardware used for PC gaming... They should actively be trying to improve the medium with their influence. However, regarding Digital Foundry.. while I agree with you, the reality is that they have finite time and resources.. and they need to release videos regarding specific hardware and topics when it can maximize their engagement. Totally understandable. Despite the pressing issue.... there will be plenty of time when things are a bit slower, for them to properly give it the spotlight it deserves. The last thing I'd want is for Alex to make a massive video bringing attention to this issue... only for it to be lost behind the hype of some GPU/CPU launches.. or some other thing.

As for the time being... they continually keep this topic in people minds by bringing it up or referencing it during their DF Directs... which is great.

Realistically the issue is that PC hardware coverage is largely focused on the hardware itself and the reader/viewer interest seems to draw heavily based on the underlying "hardware vendor wars." Since this isn't a topic at this point that can be framed from a vendor centric coverage stand point, eg. AMD vs Nvidia, it's not going to receive much coverage if any. While content creators focused on games themselves and their audiences aren't into the hardware side much less on a more technical level.

Digital Foundry has a bit of a unique/niche in terms of how they cover game technology and hardware. I don't think Alex even does hardware specific review/coverage for Digital Foundry? But you can see the general difference in approach in terms of things such as how DLSS3 are covered. In the typical sites the even if not directly the coverage always has that underlying implication of how something like that ends up factoring into the "GPU Wars" (which I think Alex even referenced in their last Weekly).

To be fair to the content creators they are responding to the majority of the audience. PC gaming/hardware discourse itself has always been dominated by the vendor wars since people started these discussions on forums decades ago. Hardware reviews are as much content (if not more so) for "entertainment" than to actually inform purchases in terms of audience engagement.
 
Realistically the issue is that PC hardware coverage is largely focused on the hardware itself and the reader/viewer interest seems to draw heavily based on the underlying "hardware vendor wars." Since this isn't a topic at this point that can be framed from a vendor centric coverage stand point, eg. AMD vs Nvidia, it's not going to receive much coverage if any. While content creators focused on games themselves and their audiences aren't into the hardware side much less on a more technical level.

Digital Foundry has a bit of a unique/niche in terms of how they cover game technology and hardware. I don't think Alex even does hardware specific review/coverage for Digital Foundry? But you can see the general difference in approach in terms of things such as how DLSS3 are covered. In the typical sites the even if not directly the coverage always has that underlying implication of how something like that ends up factoring into the "GPU Wars" (which I think Alex even referenced in their last Weekly).

To be fair to the content creators they are responding to the majority of the audience. PC gaming/hardware discourse itself has always been dominated by the vendor wars since people started these discussions on forums decades ago. Hardware reviews are as much content (if not more so) for "entertainment" than to actually inform purchases in terms of audience engagement.
Yea, I realize that. Still, I would like to see Linus branch out and do more of this type of coverage and bring attention to issues in the space. Surely there's a large enough audience that is interested in the technical aspects and performance of PC games for them to do more coverage on it. Maybe they just don't really care though.

Even if they just did more collaborative works with Digital Foundry and others to amplify these issues, that would be great. I'd love to see more of that.
 
Cory Barlog posted some images of him playing Uncharted: The Legacy Collection early copy on Steam Deck.. and interestingly one of the pictures is of the game select menu.. and if you look in the bottom right corner, it says "building shaders"

So it looks like it will precompile shaders for the game... thank god! THIS is how it should be done.


FfQsnrdUAAAVQMM



He also says it runs great on the Deck. :)
 
Yeah but some users were blessed and reported they saw no stutters!

Didn't know Scorn was available on gamepass so I tried it, and to be fair - I may be one of these people. :)

Now they do happen, but as with many games, especially DX12, Rivatuner's frametime measurements (at least represented by the graph) don't always reflect the actual length of presented frames you're seeing.

The blips are just that - very slight blips that barely even register as a frame drop most times. There are a few segments early on when entering new sections that you're get a few repeated in a row, but it's certainly nothing like you're seeing a stutter with every new action/enemy encountered, there can be 10+ minutes of gameplay before you see another blip. They do seem to be related to shader compiling though, as revisting those areas and they don't re-occur - frankly traversal stutters that repeat upon visiting every area are more obnoxious to me than brief shader stutters that are gone once you encounter them.

Also it may be because I'm targeting 60fps and not above, but unlike that youtuber, frame consistency was perfect for me, no microstuttering at all. 4K with FSR balanced (I think its FSR 2? I hear DLSS is coming in a patch) is definitely a locked 60 at 4k on my 3060 so far.

Maybe I'll encounter more the further I play, and I have asked on their Steam support forum for a shader pre-caching stage to iron these out, but based on my gameplay so far I wouldn't necessarily put this into the 'shader stuttering' camp compared to other games that have had this problem at least. Pretty minor and generally a very smooth game overall.
 
I don't seem to be having any stuttering issues with Scorn either. Perhaps that may be in part due to moving around rather slowly with a controller as opposed to running around m/kb where it might be more noticeable?
 
Didn't know Scorn was available on gamepass so I tried it, and to be fair - I may be one of these people. :)

Now they do happen, but as with many games, especially DX12, Rivatuner's frametime measurements (at least represented by the graph) don't always reflect the actual length of presented frames you're seeing.

The blips are just that - very slight blips that barely even register as a frame drop most times. There are a few segments early on when entering new sections that you're get a few repeated in a row, but it's certainly nothing like you're seeing a stutter with every new action/enemy encountered, there can be 10+ minutes of gameplay before you see another blip. They do seem to be related to shader compiling though, as revisting those areas and they don't re-occur - frankly traversal stutters that repeat upon visiting every area are more obnoxious to me than brief shader stutters that are gone once you encounter them.

Also it may be because I'm targeting 60fps and not above, but unlike that youtuber, frame consistency was perfect for me, no microstuttering at all. 4K with FSR balanced (I think its FSR 2? I hear DLSS is coming in a patch) is definitely a locked 60 at 4k on my 3060 so far.

Maybe I'll encounter more the further I play, and I have asked on their Steam support forum for a shader pre-caching stage to iron these out, but based on my gameplay so far I wouldn't necessarily put this into the 'shader stuttering' camp compared to other games that have had this problem at least. Pretty minor and generally a very smooth game overall.
This is my experience too, with relatively modest hardware. Only minor stutters on entering new areas.
 
One of the other considerations for Scorn is that a lot of the environments are all the same biomechanical texturing, so there may not be a whole lot of different shaders to compile.
 
Ive just watched a video about emulators and the narrator says (rpcs3) the experience wasnt enjoyable because of stuttering caused by loading shaders, but that was solved when the emulator supported asynchronous shaders
could this be the answer ?
 
From the DF Gotham Knights PC article:

I used default settings plus ray tracing on the mid-spec machine and I was flabbergasted by the performance I saw in the game's intro, where shader compilation stutter ruins the first-play experience. I'd recommend watching the video to see just how bad that gets, but that 0fps readout is real and it's the nadir of a poor first-play experience. Shader compilation stutter is not an issue on consoles (a fixed platform means that shaders are pre-compiled and shipped with the game) but on PC, where there is so much component diversity, GPU shader code is essentially generated on the fly as it is needed. It's still bad on the Core i9 12900K but it's truly abysmal on the Ryzen 5 3600. Compiled shaders are cached and stutters only happen once, but as we've pointed out many times in the past, the only way to bypass this on PC is to get someone to play through the game for you first!

 
Given the timing with the recent round of new CPU reviews/releases this does bring up an interesting question with respect to CPU review methodology and gaming performance. Should reviewers be wiping the cache completely to replicate an actual first play through experience and how much the CPU impacts said experience in practice? Does that "overkill" 13900k over the 12400 for 60 fps gaming even on a "modest" GPU actually make a bigger difference in practice than the reviews are showing?

Has anyone looked in depth just how much CPU variance impacts this issue?

Even with some of the mitigation techniques discussed for implementation one would suspect that CPU perf may still be a factor that wouldn't be accounted for in reviewing testing if they are doing multiple runs already pre-cached, even if it's just the pre-compile time.
 
CIG developer about that topic.

Question
Would you consider adding a "shader compilation" step when loading the 'verse from the main menu? That way you could use the maximum power available from the machine to do it quicker and not worry people (who may not know this) with the worse framerate for the first ten minutes of play!

Answer
No, we can't do that. We have waaaay to many shaders for that. The latest shaderlist contains roughly 30.000 entries. Building a full shadercache can take up to several hours on a single machine. Surely you don't want people to wait that long:)

We have to do it on demand. But as i said most shaders are cached anyway, so no compilation will be done. And in case we do compile it's purely on a background thread so it doesn't effect framerate unless we compile tenth'ish of shaders at the same time, which is unlikely with a shadercache.
MEDIA=reddit]starcitizen/comments/tbvbdo/_/i0lojkb[/MEDIA]

A game like this would probably also be too large and diverse for Nanite.

---

EDIT:
Other quotes
I'm not too deep into the driver side, but i was talking about our shadercache. Most of our compiled shaders are distributed within our builds.

I believe the driver does a final compilation step with the binary code but this is done on a background worker which doesn't stall.

What we do when the shader is not compiled? We use kind of an uber shader which always gets compiled the first time an PSO gets created until the permutation is available. Works beautifully!

Regarding shader compilations:1.) A lot of the compiled binary shaders come already prebaked with the data.p4k, so you will see not much shader compilations anyhow. Without going to deep there are exceptions which can trigger a full rebuild of all shaders at runtime within a patch.

2.) Shader compilation is running on a background thread and doesn't stall the game much. It can be if LOTS of shaders are getting compiled (e.g. in case of a full rebuild) as the game also utilizes these background threads for lots of other things. So if all background treads are busy it can throttle down the engine. I'm not sure if it's in release builds, but you should see a teapot icon on the top left with a number in it which depicts how many shaders are there left to compile. So whenever that icon pops up you know the engine compiles some shaders.
 
Last edited:
Can't you just do it for the longer shaders only ?

Or maybe, at some point, work around the problem rather than saying "can't do sh*t, goodbye".
 
In my opinion, that Reddit posting appears to be saying that 30K shaders are compiled by the 3D API and cached while the game initiates driver compilation in the background on demand based upon the cached-compiled shaders...
 
It is of course a shame PC games get released in such a state with moderate or severe stuttering issues, but how are things after say 6 months time? Are most issues fixed by then, or are there many/quite a few games that never get the stuttering issues fixed?
 
It is of course a shame PC games get released in such a state with moderate or severe stuttering issues, but how are things after say 6 months time? Are most issues fixed by then, or are there many/quite a few games that never get the stuttering issues fixed?
Most of them never get fixed. Slightly improved at best.
 
Star Citizen player watched the Sackboy DF video and asked CIG:
Watching this video by Alex Battaglia I was wondering if the future implementation and polishing of GEN12 will be subject to these kinds of problems and if the team has thought of any solutions, other than explore and keep exploring.

Answer from CIG employee
Hey!
We're well aware of this and doing everything we can do to mitigate this Problem.
Gen12 precompiles all shaders while we load objects on our background workers if a shader wasn't found in the cache.
This means our main rendering loop is completely decoupled from shader compilation.
However: as long as we're on d3d11 we have no full control over what the driver is doing behind the scenes.
With Vulkan we have more control over shader/pso compilation in the driver and they have some neat features we can use to speed compilation up.

 
Back
Top