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

The last time I tried it it wasn't nearly as bad as it was before. I wonder if these guys are pre-downloading and installing the 28GBs of streamed assets before playing??

View attachment 11391



I still maintain that I wish Epic would just have an optional button to click in the main menu to trigger a precompilation process for every damn thing in the game.
The streamed assets are for downloading models/skins before a match (as we know, fortnite has 100s of skins) - they make server connections faster since you are not downloading the player skins used in the match during map load but just getting them from disk instead.

I am pretty sure people have just misattributed that as to meaning something to do with compilation. As we all know, you cannot download precompiled shaders on PC in DX12.
 
I'm surprised that Fortnite has not solved their shader compilation stutter yet while being out for like 7-8 years. I know it's a game that is updated/changing fast with a lot of different character skins so it's hard for QA to keep the list of shader permutations up to date. But on the other hand the game is out for a long time so you would think they would have some automated systems that fly the camera through a level filled with bots (or recordings of previous matches) to collect PSO's. It's also an online game that has one of the biggest player bases. So you could even collect data from players on which PSO's the system missed and distribute this list to other players who didn't play a match yet. So lots of ways for them to reduce the PSO stutter.
 
The streamed assets are for downloading models/skins before a match (as we know, fortnite has 100s of skins) - they make server connections faster since you are not downloading the player skins used in the match during map load but just getting them from disk instead.

I am pretty sure people have just misattributed that as to meaning something to do with compilation. As we all know, you cannot download precompiled shaders on PC in DX12.
You could be right, but that just doesn't make any sense to me. That wouldn't be "streaming" that would be downloading and loading before playing.

Besides that, there's more than just character skins, there's weapon skins, vehicle skins, item skins and all sorts of effects which can come from all of these different skins which I doubt is all being loaded right at the start of a game.

If you read the description of the option it says: "Installs all assets that would normally be streamed during gameplay"

1716889884170.png

So I take that to mean like as you're running through the world and playing.. and I just figure that the less you have the game downloading assets and streaming during actual gameplay, the less chance there is of stutter, and not simply shader related, but network related and so on.
 
Last edited:
The streamed assets are for downloading models/skins before a match (as we know, fortnite has 100s of skins) - they make server connections faster since you are not downloading the player skins used in the match during map load but just getting them from disk instead.

I am pretty sure people have just misattributed that as to meaning something to do with compilation. As we all know, you cannot download precompiled shaders on PC in DX12.

Fortnite has:
1850 skins
933 emotes
1223 pickaxes
1485 back blings
550 gliders
750 vehicle/weapon wraps
169 dive trails

Would be really interesting to know how many unique shaders all of those cosmetics add up to. And that's not even counting the map and the effects for all if the different items.
 
I've noticed the default shader cache size in the NVCP is rather small, maybe 4-5GB. Does raising it provide any meaningful benefits? I set mine to 10GB because I see no reason not to but I'm curious. It can go much higher.

Also, does updating the driver always clear the shader cache? I've noticed some games either take longer to load (the first time) or become stuttery for a bit after driver updates. For this reason I've avoided updating drivers unless I'm having problems or want to play a relatively new game.
 
question :
what happens for example if I have it set to 10gb but I play that many games that I need 20gb do some games not get their shaders cached or does the driver delete previously cached shaders to make room?
can I empty the cache manually ? If I select do not cache shaders in the driver does that delete the cache or just not use it anymore ?
 
Last edited:
Thanks but sometimes it maybe better if the driver thought I could delete the shaders for the 3 oldest games to make room for this new games shaders or I could delete the shaders of a newer game and it's better to have 1 game without cached shaders than 3 games without cached shaders.
just a thought..

Depends on how many games you tend to play on one driver version.
May be a good idea if nvidia could somehow tell the driver no updates in this driver affect shader compilation or execution its ok to use shaders compiled by the previous driver
 
Last edited:
May be a good idea if nvidia could somehow tell the driver no updates in this driver affect shader compilation or execution its ok to use shaders compiled by the previous driver
That would be not that hard to make. Who knows, maybe they already do this? But fixing just one bug in the compiler already means the shader code generated will be different and thus the shader cache would need to be rebuild. So a lot of times a rebuild will be needed anyway.

What would be good if we could have an option to let the driver recompile the shader cache in a low-priority thread after install. This would require additional space to also cache the byte code that was used to generate the shaders. And it would have to be opt-in only (and maybe even pause-able?), else people won't know what it is and will freak out that a process is using they CPU time.

Btw: this will not help with live-service games like Fortnite as they get huge updates periodically anyway. And those are the games a lot of people are playing.
 
That would be not that hard to make. Who knows, maybe they already do this? But fixing just one bug in the compiler already means the shader code generated will be different and thus the shader cache would need to be rebuild. So a lot of times a rebuild will be needed anyway.

What would be good if we could have an option to let the driver recompile the shader cache in a low-priority thread after install. This would require additional space to also cache the byte code that was used to generate the shaders. And it would have to be opt-in only (and maybe even pause-able?), else people won't know what it is and will freak out that a process is using they CPU time.

Btw: this will not help with live-service games like Fortnite as they get huge updates periodically anyway. And those are the games a lot of people are playing.

Basically it seems like you're asking for Steam's Fossilize method to be done at the IHV level. Fossilize can do it since Valve/DXVK authors basically write the translation layer and are intercepting D3D calls to translate to Vulkan - I think if something like this were possible, if would have to be done at the API level, but I dunno.

Fossilize's success rate, at least ime as well, is somewhat spotty. I can have games with a GB+ of downloaded Vulkan PSO code that will still exhibit shader stutter until those shaders are compiled in real-time (even at the start of the game).

But outside of more efficient real-time solutions like Ubershaders, that's the dream - a driver-independent, hardware abstracted method for compiling shaders for all games outside of gameplay. Fossilize sounded like that when it was launched, but I'm wondering how feasible such a method it really is. I tend to think if you could abstract uncompiled shader code and have a universal standard for it to be done outside of gameplay it would have been done by now - at least with current API's.
 
Last edited:
Basically it seems like you're asking for Steam's Fossilize method to be done at the IHV level. Fossilize can do it since Valve/DXVK authors basically write the translation layer and are intercepting D3D calls to translate to Vulkan - I think if something like this were possible, if would have to be done at the API level, but I dunno.

Fossilize's success rate, at least ime as well, is somewhat spotty. I can have games with a GB+ of downloaded Vulkan PSO code that will still exhibit shader stutter until those shaders are compiled in real-time (even at the start of the game).

But outside of more efficient real-time solutions like Ubershaders, that's the dream - a driver-independent, hardware abstracted method for compiling shaders for all games outside of gameplay. Fossilize sounded like that when it was launched, but I'm wondering how feasible such a method it really is. I tend to think if you could abstract uncompiled shader code and have a universal standard for it to be done outside of gameplay it would have been done by now - at least with current API's.
It can be done. It just depends on Microsoft.
 
Crytek did a fine job in eliminating their PSOs stutters in the game Hunt Showdown, by reducing the amount of PSOs created and also by hiding the object responsible for the stutter for a few frames until it's ready to be drawn without causing any stutters. They don't even precompile any shaders at loading, and yet achieved good results with this methodology (timestamped).

 
Essentially the same way Nixxes does it. It's the best way overall with the least amount of friction for the player without a large pre-comp process upon initial startup. However, I'm still a fan of big and thorough pre-comp processes at startup. I actually prefer it if I'm honest for a couple reasons. Compiling all the shaders you can upfront can help reduce CPU utilization during gameplay as well as reducing load times. Which in turn can help performance especially on mid to low end PC setups.
 
My understanding of the video was that Hunt does have shader pre-compilation, but instead of compiling every possible shader that could be encountered in the game on initial startup they decide what shaders are necessary based on the graphics settings and the current level and compile them in the level loading screen. The live async compilation takes care of any shaders that were missed by that step.
 

How God of War Ragnarök was ported to PC


Digital Foundry: Speaking of resources, DX12 has explicit compilation of PSOs, and it's my bugbear on PC. I hate it when it doesn't work and you get shader compilation stutter. I'm only early on, but I've noticed zero frame-time spikes during my playthrough, which is what you want to see. What exactly are you doing for PSOs?

Steve Tolin
: Do we only have 30 minutes? [laughs] We're in the same camp as you - we use the #StutterStruggle hashtag the same as you and we take it to heart, because it's not something we want to see in our games.

The biggest issue and hurdle for a lot of that is that you need to have a full representation of all of your runtime render passes and everything offline, so that you can run all your materials through it to generate all the permutations for everything and then catch everything that's done.

Very early on we decided not to just have QA play the game and accumulate PSOs that way, then ship some pre-known set and hope in the wild that players don't look off into a corner. We did the full build offline and created the PSOs offline, so all of the data is known beforehand in the pipeline for us, and it took us a substantial amount of time to get that right.

Great to see this attitude on shader compiling in general of course, but I'm curious about their "creating the PSO's offline" approach - I mean, yeah, that's pretty much what everyone wants, but I can't discern what "did the full build offline" actually means here wrt collecting PSO's. Obviously with the comment that it took them a 'substantial amount of time' this isn't just flicking a variable and letting 'er rip for a few hours, perhaps this is only possible since they likely have the support of the original devs and maybe get the option for approaches just not possible with something like the Unreal Engine, dunno.
 
Back
Top