[MountainTheme12]

No, that's not the reason.

The shader stutter issues are non-existent on console because consoles have one architecture and you can ship shaders as compiled machine code. For PC you don't know what architecture you will be targeting, so you ship some form of bytecode that needs to be compiled on the target machine.

[Uvix]

Agreed. I didn't mean to say consoles' popularity is why they don't have shader stutter, but rather it's why implementing a fix on PC (e.g. precompilation at startup) isn't something most titles bother with.

[MountainTheme12]

It's not just popularity, Epic has been trying really hard to solve it in Unreal Engine.

The issue is that, because of monolithic pipelines, you have to provide the exact state the shaders will be used in. There's a lot of that, and a large part of it depends on user authored content, which makes it really hard to figure out in advance.

It's a fundamental design mistake in D3D12/Vulkan that is slowly being corrected, but it will take some time (and even more for game engines to catch up).

[jayd16]

You still don't get it. It's just not possible to ship a precompilation of every shader permutation for every supported hardware permutation.

[Uvix]

That's why I said "precompilation at startup". That has users compile for their precise hardware/driver combination prior to the game trying to use them for display.

[formerly_proven]

Even this is just guesswork for the way these engines work, because they literally don't know what set of shaders to compile ahead of time. Arbitrary scripting can change that on a frame-by-frame basis, shader precompilation in these engines mostly relies on recording shader invocations during gameplay and shipping that list. [1]

Like, on the one hand, you have engines/games which always stutter, have more-or-less long "shader precompilation" splashscreens on every patch and still stutter anyway. The frametime graph of any UE title looks like a topographic cross-section of Verdun. On the other hand there are titles not using those engines where you wouldn't even notice there were any shaders to precompile which... just run.

[1] https://dev.epicgames.com/documentation/en-us/unreal-engine/...

> In a highly programmable real-time rendering environment such as Unreal Engine (UE), any application with a large amount of content has too many GPU state parameters that can change to make it practical to manually configure PSOs in advance. To work around this complication, UE can collect data about the GPU state from an application build at runtime, then use this cached data to generate new PSOs far in advance of when they are used. This narrows down the possible GPU states to only the ones used in the application. The PSO descriptions gathered from running the application are called PSO caches.

> The steps to collect PSOs in Unreal are:

> 1. Play the game.

> 2. Log what is actually drawn.

> 3. Include this information in the build.

> After that, on subsequent playthroughs the game can create the necessary GPU states earlier than they are needed by the rendering code.

Of course, if the playthrough used for generating the list of shadersdoesn't hit X codepath ("oh this particular spell was not cast while holding down shift"), a player hitting it will then get a 0.1s game pause when they invariably do.