CPU. I'm not sure that it can be moved on GPU since we're talking about a pretty complex compiler which is a part of GPU driver.
Shader Compilation on PC: About to become a bigger bottleneck?
- Thread starter Flappy Pannus
- Start date
At the end of the day, it doesn't matter where you move compilation to, even if you could move it..
The main problem we currently have are developers not properly implementing complete compilation/caching systems into their games. There's also a problem with Quality Assurance, and developers/publishers releasing games in these kinds of states. You can't play Ghostrunner, or Shadow Warrior 3, or many other games for even 3 minutes without seeing very CLEAR problems here. Unreal Engine 4 games are notorious for this. Same with FF7R for crying out loud. People tested these games... and apparently it was acceptable for them. THAT is a problem.
I can understand some small indie dev team with no real low level programmers having issues... but SquareEnix?
Are developers and game testers properly testing games... which clean shader caches? Do developers actually play and test these games after they hit the final "build"?? Because in my mind, a developer would build the game, and constantly be testing how levels perform, by constantly clearing the caches. If you don't do that while you're testing... you're not getting the same experience that gamers will get when they first experience the game.. and the testing is useless.
Capcom seems to be one of the ones who does it right. I don't remember any compilation stutter in any of their RE engine games utilizing DX12. These games don't have long shader compilation processes at the beginning either. Monster Hunter Rise actually has a small shader comp process at the start to ensure it's all precompiled.
GPUOpen presentation by Capcom and AMD about DX12 optimizations in RE Engine
https://gpuopen.com/gdc-presentations/2019/gdc-2019-s4-optimization-techniques-re2-dmc5.pdf
Basically.. we need more developers to just start putting more of a focus on fixing and optimizing this aspect. If engine providers can improve how developers can capture the required data to build better pipeline caching systems.. then they should immediately begin implementing it.
We have the CPUs... we have the ability to pre-compile on our end.. We're willing to wait for these processes.. We just need them to be implemented.
The main problem we currently have are developers not properly implementing complete compilation/caching systems into their games. There's also a problem with Quality Assurance, and developers/publishers releasing games in these kinds of states. You can't play Ghostrunner, or Shadow Warrior 3, or many other games for even 3 minutes without seeing very CLEAR problems here. Unreal Engine 4 games are notorious for this. Same with FF7R for crying out loud. People tested these games... and apparently it was acceptable for them. THAT is a problem.
I can understand some small indie dev team with no real low level programmers having issues... but SquareEnix?
Are developers and game testers properly testing games... which clean shader caches? Do developers actually play and test these games after they hit the final "build"?? Because in my mind, a developer would build the game, and constantly be testing how levels perform, by constantly clearing the caches. If you don't do that while you're testing... you're not getting the same experience that gamers will get when they first experience the game.. and the testing is useless.
Capcom seems to be one of the ones who does it right. I don't remember any compilation stutter in any of their RE engine games utilizing DX12. These games don't have long shader compilation processes at the beginning either. Monster Hunter Rise actually has a small shader comp process at the start to ensure it's all precompiled.
GPUOpen presentation by Capcom and AMD about DX12 optimizations in RE Engine
https://gpuopen.com/gdc-presentations/2019/gdc-2019-s4-optimization-techniques-re2-dmc5.pdf
Basically.. we need more developers to just start putting more of a focus on fixing and optimizing this aspect. If engine providers can improve how developers can capture the required data to build better pipeline caching systems.. then they should immediately begin implementing it.
We have the CPUs... we have the ability to pre-compile on our end.. We're willing to wait for these processes.. We just need them to be implemented.
Ext3h
Regular
So simple that it hurts: Your testers, not even the ones you work with, do know how to clear their shader cache. They can't notice, because they have tainted (full) caches since earliest builds. They don't notice because the issue isn't reproducible. And they have plenty of reproducible stuff to worry about, so a one-off doesn't count to them.
Testers don't spin up clean OS images to ensure things like that don't happen?
That's not surprising at all.
The entire QA chain needs fixing. Developers know this stuff... this shouldn't be happening. PC profiling tools need to get better. PC dev tools need to get better. Engine developers need to focus on this issue. The entire industry needs to focus on this issue and do what it can all through the entire stack to ensure that gamers get the proper experience the FIRST time.
They'll get the message soon enough, as the discourse continues to grow, as people learn that there's more that developers could be doing, but they aren't.. When new games stutter so badly they're almost unplayable. When it makes the 60TF+ Nvidia and AMD gpus look so bad that they cant do basic things in a game without hitching profusely the first time you do it. When companies like Valve are attempting to improve things of their own volition.. because it's getting so bad... that makes the developers look pretty bad. When native PC games get compared to games running on emulators... and being worse.. When wer're spending more now on components than ever before.. $2000+ on a new GPU alone... $500+ on a big CPU... Motherboard prices being stupid these days too.. and you're still dealing with it.
This is a problem you can't buy your way past and brute force. It requires the industry to start addressing issues that they've been allowing to fester for ages now. It's finally becoming too much. I see more and more people speaking out about this "phenomenon" that's plaguing PC games.
Hopefully this industry can come together in all the ways it possibly can, to help improve this situation. I know there are tons of developers out there frustrated at the state of things as well, and have put a lot of effort into this very topic. I'm not trying to take away from the work they've done... but maybe now's the time for the industry to start listening to those people who've been fighting the good fight for so long now.
Ext3h
Regular
No. Your average tester is not only "lazy", but foremost values his work time far too much to spend it on system resets. Not to mention that the test system needs setup, in the form of OBS, NSight etc. for capturing reports, and plenty of automation. The test systems are almost never clean.
If you wanted to assist as a developer, you would on purpose render your shaders uncachable on each application startup (injecting a trivial, unreachable footer will do). But don't put that burden on the tester who is already frustrated enough as it is with loading screens, fragile scripts and a tracking a fair share of yet inexplicable issues.
Basically proves that most of the stuttering isn't due to shader compilation at all and is mostly because of a badly designed resource management in a d3d12 renderer.
Ext3h
Regular
On the Steam deck, yes. But as stated at time index 12:06, it never had been an issue on the Steam Deck in the first place as the Fossilize Vulkan layer provides a shader cache (actually: not just shaders, but full pipeline...) for Protons DX12 wrapper too, and Valve does ship the shaders from day one.
The video makes no statement as to the causes of stutters on the PC end. And resource management bottlenecks on Proton side do not necessarily translate to similar bottlenecks in Microsofts implementation - that's after all still far away from the driver. Keep in mind, it states the identified issue wasn't in burst submission, but in burst allocation.
The only thing you can take away from that video is: As long as Valve as you are hitting any to-Vulkan translation layer, Valve has your ass covered in this direction.
Fossilize captures pipeline states, Valve collects, precompiles centrally (no more crowd sourcing compiled pipeline states apparently?) and then delivers together with the games download from day 1.
Last edited:
Rootax
Veteran
So..
Valve stated that on the Linux/Proton side of things they have a pre-caching system with multiple levels of source/binary cache representations stored which download to a users device depending on their hardware setup. We already knew that they can crowdsource this data from Steam users using Proton. On the Deck, this is taken further because they know the exact specific hardware configuration and driver.. so Valve themselves can essentially build a shader/pipeline cache for the Deck before any users play the game.
That's great for Deck. But let's focus on the PC side of the equation where there's many different configurations. We know Valve can crowdsource this data from users, and build caches which download when you download the game. That's been a feature of Steam for a while now. This data could be crowdsourced extremely fast.. to the point where it could likely be done before the game even fully releases anyway as there's always some people who get pre-release copies. What a nice thing it would be to have those people actually contributing to making the launch better for everyone else! haha
That only applies to Vulkan/OpenGL games, however.
Ok, so Valve can seed pre-cached Vulkan shaders/pipelines to users with matching hardware/driver configurations. They can do this on Linux/Proton.. and they can also do this on Windows.. soooo
What if Valve made a Windows specific D3D to Vulkan translation layer which would do the same thing on Windows as Proton does on Linux and allow them to cache shaders/pipelines for all games? I've heard some people say that when you run some games using DXVK, Steam has actually downloaded some pre-compiled shaders for it all on its own.
I mean, they're already doing so much work on Proton.. and with the Steam Deck, they're essentially committing themselves to continually improving compatibility as well. Proton was a thing before Steam Deck was ever an idea.. so what if Valve created a way to build shader/pipeline caches for all games, through a DX to Vulkan translation layer? The performance overhead would be worth the reduction in hitches and stuttering, IMO.. and we apparently can't depend on developers to do it themselves.
Also, as a side note... what exactly is preventing this from being possible with DirectX itself in the first place? Why can't Valve create caches from DirectX based games? How can it be that people can make something like Proton... which allows all this to work on a completely different operating system... but it can't be done on the original OS using the API itself?? If it's MS holding that back... then maybe MS needs to get off their butt and change that.
Oh, and about the legality of all this... I feel like Steam itself collecting and distributing copyrighted shader code to users who legally purchased those games...is an entire world away from pirates sharing shader code generated from (potentially) illegally downloaded roms through emulators. This is intended to improve the experience of legally abiding customers.
Valve stated that on the Linux/Proton side of things they have a pre-caching system with multiple levels of source/binary cache representations stored which download to a users device depending on their hardware setup. We already knew that they can crowdsource this data from Steam users using Proton. On the Deck, this is taken further because they know the exact specific hardware configuration and driver.. so Valve themselves can essentially build a shader/pipeline cache for the Deck before any users play the game.
That's great for Deck. But let's focus on the PC side of the equation where there's many different configurations. We know Valve can crowdsource this data from users, and build caches which download when you download the game. That's been a feature of Steam for a while now. This data could be crowdsourced extremely fast.. to the point where it could likely be done before the game even fully releases anyway as there's always some people who get pre-release copies. What a nice thing it would be to have those people actually contributing to making the launch better for everyone else! haha
That only applies to Vulkan/OpenGL games, however.
Ok, so Valve can seed pre-cached Vulkan shaders/pipelines to users with matching hardware/driver configurations. They can do this on Linux/Proton.. and they can also do this on Windows.. soooo
What if Valve made a Windows specific D3D to Vulkan translation layer which would do the same thing on Windows as Proton does on Linux and allow them to cache shaders/pipelines for all games? I've heard some people say that when you run some games using DXVK, Steam has actually downloaded some pre-compiled shaders for it all on its own.
I mean, they're already doing so much work on Proton.. and with the Steam Deck, they're essentially committing themselves to continually improving compatibility as well. Proton was a thing before Steam Deck was ever an idea.. so what if Valve created a way to build shader/pipeline caches for all games, through a DX to Vulkan translation layer? The performance overhead would be worth the reduction in hitches and stuttering, IMO.. and we apparently can't depend on developers to do it themselves.
Also, as a side note... what exactly is preventing this from being possible with DirectX itself in the first place? Why can't Valve create caches from DirectX based games? How can it be that people can make something like Proton... which allows all this to work on a completely different operating system... but it can't be done on the original OS using the API itself?? If it's MS holding that back... then maybe MS needs to get off their butt and change that.
Oh, and about the legality of all this... I feel like Steam itself collecting and distributing copyrighted shader code to users who legally purchased those games...is an entire world away from pirates sharing shader code generated from (potentially) illegally downloaded roms through emulators. This is intended to improve the experience of legally abiding customers.
So they basically introduced a limited form of SSOs ...
The geometry pipeline is still monolithic since vertex, tessellation, and geometry shaders have to be compiled together but the good news is that tessellation and geometry shaders might be falling out of use which will reduce the number of possible combinations of the geometry pipeline. The fragment shader pipeline stage is entirely separate very much like it is in D3D11, OpenGL, or Metal ...
With the right potential dynamic state extensions exposed in the future, we can get rid of the fragment output interface. A future extension for dynamic blending and MSAA states along with the existing dynamic rendering extension will be necessary to make it happen ...
Still wondering when the bikeshedders including the one at Epic Games will make Vulkan their default API since that is arguably closer to their ideal vision in many cases compared to D3D12. With the right extensions, it's noticeably easier to transition from D3D11 to Vulkan than D3D12. Soon even the texture binding API is going to be simpler in Vulkan than whole heap indexing with D3D12 ...
The geometry pipeline is still monolithic since vertex, tessellation, and geometry shaders have to be compiled together but the good news is that tessellation and geometry shaders might be falling out of use which will reduce the number of possible combinations of the geometry pipeline. The fragment shader pipeline stage is entirely separate very much like it is in D3D11, OpenGL, or Metal ...
With the right potential dynamic state extensions exposed in the future, we can get rid of the fragment output interface. A future extension for dynamic blending and MSAA states along with the existing dynamic rendering extension will be necessary to make it happen ...
Still wondering when the bikeshedders including the one at Epic Games will make Vulkan their default API since that is arguably closer to their ideal vision in many cases compared to D3D12. With the right extensions, it's noticeably easier to transition from D3D11 to Vulkan than D3D12. Soon even the texture binding API is going to be simpler in Vulkan than whole heap indexing with D3D12 ...
Nice! Tobias Hector really is a Vulkan/OpenGL rockstar
Elenarie on resetera on shader compilation on console; it is as suspected but this is the first I’ve seen public confirmation on how it works on ps.
https://www.resetera.com/threads/is...ce-on-modern-games-on-pc.570796/post-84862756
https://www.resetera.com/threads/is...ce-on-modern-games-on-pc.570796/post-84862756
Console SDKs are updated though, they just don't change their behavior with such updates.
I took that as more of a static linking instead of dynamic linking on PS (as a concept), and not as a PS uses Virtualized Environments. So "sandboxed" means all the specific assemblies needed are bundled along with the title resources too, and those won't be updated by system updates, only developer updates. They don't have a General Assembly Cache shared across all titles like PCs do.
Despite some of the takes, I'm glad to see more and more discussion happening on this topic.
PC gamers are waking up and asking important questions. We're getting tired of these issues in our versions of games. A lot of developers speak about the roadblocks involved in finding solutions.. which basically comes down to logistics. Not that there aren't ways to improve.. but that the logistics involve are difficult. These are issues that can be solved if they industry comes together to do so. The industry isn't in any rush to solve this issue until people take a stand and speak with their wallets.
What PC gamers are finally beginning to say... is that now is the time. Necessity is the mother of all invention... if PC gamers put enough attention on this issue... something can and will be done to solve those logistical issues and figure out workable solutions.
Outside of that... PC gamers have to come to terms with the reality of the platform. A shader compilation process at initial boot, and subsequent driver/OS changes is far more preferable to hitches and stutters, and there are ways to augment those processes (I believe) and speed them up.. but we need developers to actually incorporate this step into their games in the first place, either as a forced requirement.. or at the very least as an option. From there, perhaps connecting to a remote server to help your CPU compile shaders much quicker could help reduce these processes to be as short as possible.
Regardless.. the solution begins with developers/publishers properly QA'ing their games. Whether they pre-compile at startup, or they compile in the background, or do it all during load screens... whatever way they choose to do it.. they need to properly QA the game and do what they can to solve these issues before releasing the game. The biggest problem I have right now, is with developers who OBVIOUSLY don't give a damn. Like you load the game up and instantly are met with hitches during every first action you do... It's clear that either the dev didn't test the game.. or they don't care.
And that doesn't sit well with me.
Flappy Pannus
Veteran
Significantly sharper than running it on the PS5 from what I can tell, but oh boy that CPU and shader stuttering. Good lord not again.
DF Direct went into this today. Early days of course, but Alex is...concerned.
On the bright side it it's really as heavy on the CPU as Alex has seen in the Matrix project then it should help drive PC CPU sales forwards and bring the average CPU performance way up!
Obviously that's searching pretty hard for a silver lining. Personally I'm much less worried about this though. It works fine on the consoles so with proper optimisation it should be fine on PC too. If you want 60fps, get a Zen4!
Obviously that's searching pretty hard for a silver lining. Personally I'm much less worried about this though. It works fine on the consoles so with proper optimisation it should be fine on PC too. If you want 60fps, get a Zen4!
