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

Admittedly, D3D12 might cause more compilations than necessary in comparison to D3D11. D3D12 has less dynamic states available compared to D3D11 which can mean compiling more redundant state-based duplicates. If more dynamic states were exposed, drivers wouldn't be caught dead compiling the EXACT SAME shaders MULTIPLE TIMES(!!!) and you wouldn't need to create as many PSOs since some hardware can dynamically change states which is much faster than doing driver compilation. Every time there are unique PSOs and no matter how near identical they are, compilations are inevitable by design ...

Khronos Group tried fixing this design flaw in Vulkan by exposing more dynamic states with an extension. Even then more dynamic states does not address the engine side problem of the generation of shader variants. Material/Shader graphs will cause a combinatorial explosion of different shaders so we're still left with tons of PSOs ...

Relevant thread below:

 
Admittedly, D3D12 might cause more compilations than necessary in comparison to D3D11. D3D12 has less dynamic states available compared to D3D11 which can mean compiling more redundant state-based duplicates. If more dynamic states were exposed, drivers wouldn't be caught dead compiling the EXACT SAME shaders MULTIPLE TIMES(!!!) and you wouldn't need to create as many PSOs since some hardware can dynamically change states which is much faster than doing driver compilation. Every time there are unique PSOs and no matter how near identical they are, compilations are inevitable by design ...

Khronos Group tried fixing this design flaw in Vulkan by exposing more dynamic states with an extension. Even then more dynamic states does not address the engine side problem of the generation of shader variants. Material/Shader graphs will cause a combinatorial explosion of different shaders so we're still left with tons of PSOs ...

Relevant thread below:

Yea, that's all well and good, yet one can't shake the feeling that they only REALLY give a damn in so far as the effect is has on their game production and iteration times... and not so much the players experience when they actually play their game.
 
My understanding is the PC version is based on the PS5 version. The PS5 version supposedly was updated with specifics to take advantage of the higher memory of the PS5 and the SSD/storage framework. This has some issues. Memory, and specifically VRAM, as well as data movement (due to the non unified nature) on the PC side can be quite lacking versus the PS5 (or XSX) at this point still even if the other performance metrics are higher. The analogous storage framework is also not yet available.

Weve had these discussions before. Its certainly not the case, in special when changing to D3D11 renderer fixes alot of the issues to begin with. PS5 doesnt have any 'higher memory' than say a 6800XT equipped system, it has way less to VRAM. The shared and low bandwith of the consoles isn't 'superior' either, most likely its a huge disadvantage to a dedicated 16gb vram high speed gpu with dedicated system ram, a fast ssd interlinked with PCIE4.0, of which the nvme is faster aswell, even with the lack of DS/RTXIO.

Its in my belief that a PCIE3.0 system/nvme, any modern mid end or better GPU and CPU and a good software stack should have no problem to run anything the PS5 does and then some, if the port is optimized.

All this issues with Final Fantasy has to do with optimizations, not much else.
 
DX11 runs faster than DX12, with more consistent frame times and using less GPU resources too!

It's possible that a very easy fix in this case would be to make D3D11 renderer the default one and provide an option of using D3D12 for those cases where it would do better.
There are many indie UE4 games which give an option of using D3D12 while this option brings nothing but performance issues with it.
FF7R is not indie though.
 
It's possible that a very easy fix in this case would be to make D3D11 renderer the default one and provide an option of using D3D12 for those cases where it would do better.
There are many indie UE4 games which give an option of using D3D12 while this option brings nothing but performance issues with it.
FF7R is not indie though.
Would be an ideal 'quick fix', they would also have to fix HDR not working in DX11, as well as fix the vsync. If they had those working and just defaulted to DX11, the reception to this port, while still weak in other areas, would have been significantly better.
 
Don't have FF7 Remake yet but something to look into regarding the stutters - https://www.nexusmods.com/finalfantasy7remake/mods/66?tab=description
While obviously not the most ideal solution to this problem, what was funny about using this for GTAIV (where it works wonderfully) is that Steam now downloads partially completed shader caches for it as it does for all Vulkan/GL games. So you don't necessarily need the async version of DXVK (it can be a bit buggier in behavior than the non-async version IME). Not sure if this is unique to GTAIV under DXVK as that's the only title I use it with but was surprised that I constantly see shader cache updates being downloaded for it automatically now.
 
While obviously not the most ideal solution to this problem, what was funny about using this for GTAIV (where it works wonderfully) is that Steam now downloads partially completed shader caches for it as it does for all Vulkan/GL games. So you don't necessarily need the async version of DXVK (it can be a bit buggier in behavior than the non-async version IME). Not sure if this is unique to GTAIV under DXVK as that's the only title I use it with but was surprised that I constantly see shader cache updates being downloaded for it automatically now.

Wouldn't that be something if a Vulkan wrapper allowed Steam to create caches for DirectX games which legitimately solved these stutter issues the first time through.. haha

Problem is there's a risk of being banned using this wrapper, and thus can't recommend it's use for a wide variety of games.. and I'm not sure it works as great as everyone thinks in the first place. =/
 
Wouldn't that be something if a Vulkan wrapper allowed Steam to create caches for DirectX games which legitimately solved these stutter issues the first time through.. haha

Problem is there's a risk of being banned using this wrapper, and thus can't recommend it's use for a wide variety of games.. and I'm not sure it works as great as everyone thinks in the first place. =/
I've had zero luck with it in DX11 games for some reason, across months of various versions. People say it works great for games like Jedi Fallen Order but I can only get it to work with DX9 games, DX11 games just give me a black screen.

Outside of the initial shader compile stutter when caches aren't available, it's worked wonders in GTAIV and also Sonic Generations last time I tried it though.
 
I've had zero luck with it in DX11 games for some reason, across months of various versions. People say it works great for games like Jedi Fallen Order but I can only get it to work with DX9 games, DX11 games just give me a black screen.

Outside of the initial shader compile stutter when caches aren't available, it's worked wonders in GTAIV and also Sonic Generations last time I tried it though.
Yea, it's definitely no solution to the real issue. I understand using it if it makes it a bit more bearable and helps you get through the games, but it's not really constructive for people to tout it as some kind of "fix" such as I see on forums all the time IMO, and we really need to get out of this space where it's ok for developers to release trash ports of games in the first place.

The best chance we have at accomplishing that is by making enough noise about these issues when they happen and refusing to support these lackluster ports with our hard-earned money. Tech sites reporting on the issues are also imperative to getting things done.

It's amazing what a little negative press can help companies achieve these days.
 
...making enough noise about these issues when they happen and refusing to support these lackluster ports with our hard-earned money.

Followed by six months later: "PC Ports dont' sell, because PC gaming is a dying breed and nobody does that anymore. There's no profit to be made in a dying sector, we aren't going to bother trying."
 
Sorty if this has already been posted, but the thread grew faster than I could keep up with...

Ubershaders: A Ridiculous Solution to an Impossible Problem

This is a post from Dolphin Emulator about all the strategies they employed to avoid shader conpilation stutters on their software. It details many performance boosting strategies they encountered, ways to try to pre cache shaders, share them across users, and all that.

The more interesting solution is their hybrid uber-shader system. They have a ubershader that is capable of emulating all "shader" capabilities of the gamecube, but in order to do that its a big and alow shader, that can't perform fast enough on most computers. But, it can be used sparingly in certain objects without dropping the performance too significantly.

So with that in mind, when an object shows up in a game that needs to compile a new shader, dolphin will do that in the background, but instead of halting the game completely until that is done, it uses the slow uber shader for that/those objects that need it temporarely, until a leaner compiled shader is ready to be used.

If a team of enthusiasts can figure all this shit out on their spare time, for a emulator that runs code from hundreds of different games they have no source code for and can't possibly predict what the code and content of which will be, it makes it even more embarrassing that many large teams can't be bothered to do it for their titles, for which they have full access of the source code and content... It may be hard, and it may be boring. But shit, it can be fucking done...
 
Last edited:
Yeah, I don't see how interpreting shaders is a practical solution for modern games. Especially if we're talking about a system that doesn't even have a programmable pipeline nor was it turing complete either. When we take a look at modern console emulation, this solution isn't viable in practice ...

Interpreting shaders would be just as bad as of an experience compared to driver compilation hitches ...
 
Weve had these discussions before. Its certainly not the case, in special when changing to D3D11 renderer fixes alot of the issues to begin with. PS5 doesnt have any 'higher memory' than say a 6800XT equipped system, it has way less to VRAM. The shared and low bandwith of the consoles isn't 'superior' either, most likely its a huge disadvantage to a dedicated 16gb vram high speed gpu with dedicated system ram, a fast ssd interlinked with PCIE4.0, of which the nvme is faster aswell, even with the lack of DS/RTXIO.

Its in my belief that a PCIE3.0 system/nvme, any modern mid end or better GPU and CPU and a good software stack should have no problem to run anything the PS5 does and then some, if the port is optimized.

All this issues with Final Fantasy has to do with optimizations, not much else.

At the risk of reopening old discussions I'm just going to clarify on the issue I was referring to in console vs PC differences in that it's more of a problem of practicality versus actual theoretical technical capabilities.

Yes in theory overall the PC can be more capable depending on the hardware configuration. As you say a 6800XT GPU is not at a VRAM deficiency, with something like a RTX 3090 we have can systems with significantly more VRAM.

The problem however is that the PC inherently is the going to be the platform typically with the least sales while being the most problematic to actually optimize for just from a variety of hardware configurations stand point. Optimizing a game for say the PS5 is much more defined target than optimizing a game for the PC, which is a very loosely defined platform. Just in terms of GPU VRAM you cannot assume a 16GB or higher VRAM configuration (or you'd limit sales even further) but you need to even these days assume a substantial amount of users with 8GB if not optimize for 6GB or less. So how would you approach this from an optimization stand point? "Perfect" scalability and for the lack of a better term "infinite" optimization paths are easier said than actually done or possible in practice. Even in the console market cross gen titles are often considered essentially compromises in terms of optimization and that's with way less target platforms to account for.

Would it result in a different and "better" experience if the approach was we don't care if the game doesn't run at all with <16GB VRAM GPUs (without worrying at all about scalability down to 3GB, which is apparently FF& Remakes min requirement). Would the approach to optimization be different? Essentially in practice this does result in a situation on the PC, which has to my knowledge been a bit of conundrum in the console vs PC debate, in that despite how much better the high end hardware is the overall platform does need to factor in the low end as well which can be worse. Compounding the issue of course is early on in each new console cycle the "better" than console PC hardware market share gets reset to very lows.

While obviously not the most ideal solution to this problem, what was funny about using this for GTAIV (where it works wonderfully) is that Steam now downloads partially completed shader caches for it as it does for all Vulkan/GL games. So you don't necessarily need the async version of DXVK (it can be a bit buggier in behavior than the non-async version IME). Not sure if this is unique to GTAIV under DXVK as that's the only title I use it with but was surprised that I constantly see shader cache updates being downloaded for it automatically now.

That's interesting as at least from what I understand it you'd need a compile for every unique GPU/driver/OS version? configuration. I'm wondering how many permutations they have on hand.
 
At the risk of reopening old discussions

Ofcourse optimizations and consistency is something the consoles largely enjoy, they always have, being a single target platform for a seven year period, devs have only one configuration to have in mind. Though, i do things have improved alot coming from the PS1 days, 2000's etc.Scaling also has improved alot, and now with MS having different SKUs for their xbox consoles, thats bound to improve further.

What could happen is studios supporting 5700XT/6700 (or 3060 for nv) and up, those roughly match the consoles, and have lesser support for legacy hardware. I assume this automatically will happen as PS4/One will be dropped entirely.

But yes ofcourse if a studio just does a shitty port (to either PC or console), its not going to impress many. Usually, if you have the pc version (and a pc more capable then the consoles), you have technically the 'best' version in hands.

I want to note again, i think Sony is really improving alot with their ports to the pc platform.
 
I want to note again, i think Sony is really improving alot with their ports to the pc platform.

They've got 2 very high profile releases coming up, God of War, and the Uncharted Collection.. so hopefully they knock it out of the park with these releases and seal the perception that their releases will be high quality from here on out.

With Horizon Zero Dawn things didn't start off that great, the port had many bugs and issues, performance was all over the place. Then you had Days Gone which was better, but still had it's own issues. Subsequent patches for both games would improve things, and in the case of Horizon they really went about fixing most of the issues.. so that has really put them on this new trajectory of expectations. We know they are taking PC seriously, and first of all their commitment to fixing the previous games showed that... as well as the Nixxes acquisition, which we are already seeing fruits from in the form of further improvements to Horizon. Hopefully Nixxes will take on the role of port quality assurance. Working with either the actual dev studios themselves, or the port studios, to ensure high quality ports. Hopefully they kinda act like "the ICE team" for the PC side of the equation and that knowledge and expertise accumulates over the other studios and thus the entire machine becomes well oiled to maximize output.

That's what I hope for.
 

It's probably a little too early to judge based on that given the game very likely runs at higher settings than the original release which runs at 4k checkerboard / 60fps on the PS5. 4k FSR UQ is about 18% more resolution than 4K CB so we should expect a slight performance penalty there plus an unknown penalty from the higher settings. It'll be interesting to compare the visual quality of FSR and CB at similar internal pixel counts. And of course DLSS.
 
Lol. Judging with benchmarks that arent really a match between platforms is one thing. Judging a game or port that hasnt been released yet is another.
 
Back
Top