Ubershaders: A Ridiculous Solution to an Impossible Problem (2017)

Has it really been 9 years since I started working on Ubershaders?<p>I&#x27;m a little surprised no better solution has come along. Vulkan didn&#x27;t even exist back then (and DirectX 12 had only just released) but instead of making things better, it digs it&#x27;s feet even deeper into the assumption that all shaders will be known ahead of time (resulting in long &quot;shader recompilation&quot; dialogs on startup on many games).<p>I&#x27;ve been tempted to build my own fast shader compiler into Dolphin for many common GPU architectures. Hell, it wouldn&#x27;t even be a proper compiler, more of a templated emitter as all shaders fit a pattern. Register allocation and scheduling could all be pre-calculated.<p>But that would be even more insane than ubershaders, as it would be one backend per gpu arch. And some drivers (like Nvidia) don&#x27;t provide a way to inject pre-compiled shader binaries.<p>On the positive side, ubershaders do solve the problem, and modern GPU drivers do a much better job at accepting ubershaders than they did 9 years ago. Though that&#x27;s primarily because (as far as I&#x27;m aware) examples of Dolphin&#x27;s ubershader have made their way into every single shader compiler test suite.

It&#x27;s interesting to see the parallels between this and an engine for a dynamic programming language. The one I&#x27;m most familiar with is JavaScript.<p>When you first need to run something, you run it on the interpreter (JS) &#x2F; ubershader (Dolphin). But once you know it&#x27;s going to be run repeatedly (rarely for JS, almost always for Dolphin), you kick off an async compilation to produce JIT code (JS) &#x2F; a specialized shader (Dolphin). You continue running in the expensive mode (interpreter &#x2F; ubershader) until the compilation is complete, then you switch over seamlessly.

The shader compilation stutter reminds me of a video I recently saw where a developer solved the problem by running a large portion of his game during its first loading: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;oG-H-IfXUqI" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;oG-H-IfXUqI</a><p>The developer register himself playing the game and during the first loading of the game, the entire gameplay is replayed at high speed in the background on the machine.

The pixel shading of the GameCube were slower than that of the OG Xbox. But, it was quite a bit more flexible. Specifically, the GameCube could load a couple textures, do a bit of math, then use that math to load some more texels. The Xbox could only load textures as the starting instructions before doing math and tried to make up for that with a few &quot;do very specific math and load textures in a single instruction&quot; ops.<p>But, still... Both GPUs were pretty well suited for this ubershader approach because they had a small, fixed limit on the number of instructions they could run. And, very strictly defined functionality for each instruction. They weren&#x27;t really &quot;shaders&quot; as much as highly flexible fixed function stages that you could reasonably wedge in a text shader compiler as a front end and only get a moderate to high amount of complaints about how strict and limited the rules were for the assembly. I recall that both shading units could reasonably be fully specified as C structs that you manually packed into the GPU registers instead of using a shader compiler at all.

Discussed at the time:<p><i>Ubershaders: A Ridiculous Solution to an Impossible Problem</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14884992">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14884992</a> - July 2017 (88 comments)

This is a really neat article because the Godot engine is adding Ubershaders as well to fix shader compilation stuttering: <a href="https:&#x2F;&#x2F;github.com&#x2F;godotengine&#x2F;godot&#x2F;pull&#x2F;90400">https:&#x2F;&#x2F;github.com&#x2F;godotengine&#x2F;godot&#x2F;pull&#x2F;90400</a>

What was the missing piece for &quot;shader sharing&quot;?<p>Would it be possible to build a web-hosted database of encountered shader configs against a game id, and have Dolphin fetch that list when a game launches and start doing async compilation?<p>When Dolphin encounters a new shader that wasn&#x27;t in the db, it phones home to request it to be added it to the list.<p>I feel an automated sharing solution would build up coverage pretty quickly, and finding a stutter would eventually be considered an achievement - &quot;no-one&#x27;s been here before!&quot;

Does anyone know why this isn&#x27;t an issue for modern games on PC? I assume it&#x27;s because more uniforms are used, and the amount of shaders that actually need to be compiled at runtime is minimized, not to mention that the Graphics API is optimized to compile the shaders in the format they are provided. So is the issue with Dolphin that GameCube games would compile new shaders for lots of different configurations of effects &#x2F; stages? Would some sort of preprocessor that converts shader compilations to some mini-ubershader with uniforms that can handle a lot of the different effects be feasible? And then depending on how many completely different shaders there are you would have many different mini-ubershaders?

I&#x27;ve thought about writing a GPU side interpreter for SDF definitions for a while. I made a SDF shader generator that dumps out shaders with hard coded values, but doing it with bytecode would be cool. I&#x27;m sure this has been done before..

I’m suprised to see that Ubershaders still exist, most game engines have settled on a set of fit-for-purpose custom shaders with almost no conditionals (for performance reasons), which is the opposite of UberShaders.

Why not just cache the shader compilation output and save it do disk? Only stutters or object pops on the 1st run.