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.
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.
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).
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.
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.
> 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.
Closer to AMD and mobile hardware. We got abominations like monolithic pipelines and layout transition thanks to the first, and render passes thanks to the latter.
Luckily all of these are out or on their way out.
Not really, other than on desktops, because as we all know mobile hardware gets the drivers it gets on release date, and that's it.
Hence why on Android, even with Google nowadays enforcing Vulkan, if you want to deal with a less painful experience in driver bugs, better stick with OpenGL ES, outside Pixel and Samsung phones.
Trying to fit both mobile and desktop in the same API was just a mistake. Even applications that target both desktop and mobile end up having significantly different render paths despite using the same API.
I fully expect it to be split into Vulkan ES sooner or later.
Absolutely not a problem, in fact, I enjoy this. But asking game developers for "discipline" is akin to asking frontend developers for forward compatibility - simply not in their culture.
A long time ago I did some contract work writing firmware for a major hardware manufacturer in Taipei. I quickly learned to ignore bugs, because reporting them would get me reprimanded for doing things other than the task I was assigned. Even worse, the hardware team saw the firmware/driver/software devs as lowly servants and dismissed any feedback outright.
It's crazy how the hardware sector just can't grasp that software is actually important too. Everywhere I've worked at we were just second class citizens, last to get a new hire or any budget, and then it was our fault when the software was subpar. It seems like they think going down to our level will actually sully them.
>hardware sector just can't grasp that software is actually important too
they are treating software as important as they need to in order to turn a profit. it is ofcourse disappointing that you can sell such trash to willing buyers, but the market is what it is.
My issue with Unreal is that Epic puts little effort into improving the developer experience, focusing instead on churning out tech demos, flashy visuals and half baked features that only become usable after several major releases (if ever).
The artists at my company love it, the developers not so much.
I agree with the author that protobuf is bad and I ran into many of the issues mentioned. It's pretty much mandatory to add version fields to do backwards compatibility properly.
Recently, however, I had the displeasure of working with FlatBuffers. It's worse.
