Live data from Hacker News

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

dolphin-emu.org

51–60 of 72 posts

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

#51

Earlier quoted context omitted.

I don’t get it (this is not your fault, it’s mine) but I believe you.

if I understand correctly 1. "shader" is just a metaphor, the actual code running on the gamecube gpu is a custom pipeline that has a dynamic structure and is updated aggressively throughout the lifetime of the app - there is no static "shader" program to run on the host GPU. 2. The architectures of the gamecube and modern GPUs are so distinct as to require an intricate translation layer in order to map gamecube rend…

Translation is not intricate, but modern graphics card are not tuned for dynamically setting up shaders.

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

#52

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 would a lack of conditionals remove the need for uber shaders..? Or why would the presence of conditionals cause a need for uber shaders? How are these connected?

It's common to have many shader variants exactly because you want to avoid 'if' statements; conditionals are turned into shader-compile-time options. Uber shaders are about turning those compile-time options back into runtime options to have a fallback shader to run while the right shader variant is being compiled.

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

#53
post #45

This is a really neat article because the Godot engine is adding Ubershaders as well to fix shader compilation stuttering: https://github.com/godotengine/godot/pull/90400

Pretty sure these are very different phenomena both called "ubershaders". As far as I understand it, outside of Dolphin, when people say "ubershader" they mostly mean a large material shader that has branches and constants to handle all the material variants used in one game (e.g. wood door, metal shield, shiny forcefield). It's produced by the engine so it's under full control of the engine developers. This means instead of loading separate shaders for the wood door and metal shield you can just tweak pipeline parameters. It's a work around for the various overheads, like compilation, involved in creating specialized shaders.

But Dolphin's "Ubershader" is a different beast. It's about handling all the shader variants for _all_ Dolphin games (which are made in different engines) with one shader, and the variant parameters aren't passed as nice constants (data) but as shader programs (code) that need to be interpreted to be understood. It's more like a meta-shader that takes shaders as input and produces shaders as opposed to a "normal" ubershader which takes configuration to specialize it at runtime.

I think that's right anyway. I haven't worked directly with ubershaders in either variety and my knowledge comes from building my own hobby engine and 3D pipelines.

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

#54
post #53
post #45

This is a really neat article because the Godot engine is adding Ubershaders as well to fix shader compilation stuttering: https://github.com/godotengine/godot/pull/90400

Pretty sure these are very different phenomena both called "ubershaders". As far as I understand it, outside of Dolphin, when people say "ubershader" they mostly mean a large material shader that has branches and constants to handle all the material variants used in one game (e.g. wood door, metal shield, shiny forcefield). It's produced by the engine so it's under full control of the engine developers. This means in…

It sounded to me like an interpreter that emulates the GameCube / Wii GPU inside a shader, but I didn't read it closely

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

#55
post #38

What was the missing piece for "shader sharing"? 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? When Dolphin encounters a new shader that wasn't in the db, it phones home to request it to be added it to the list. I feel an automated sharing solution would build up coverage pre…

Every shader depends on both the driver version and the model of your GPU itself. Which means a lot of shaders. I think Valve had a version of it though but not without issues (GBs of shaders to be downloaded)

The idea here wasn’t to share the compiled shader, but to share the shader configurations that each game uses — the ones that are used to then compile the actual shader. So you would compile them all at game start from the configurations you downloaded

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

#56
post #18

It's interesting to see the parallels between this and an engine for a dynamic programming language. The one I'm most familiar with is JavaScript. When you first need to run something, you run it on the interpreter (JS) / ubershader (Dolphin). But once you know it's going to be run repeatedly (rarely for JS, almost always for Dolphin), you kick off an async compilation to produce JIT code (JS) / a specialized shader…

While JS can be interpreted, V8 and SpiderMonkey (the two most common JS engines) will _always_ compile before execution -- JS is _never_ directly interpreted these days (aside from more niche engines).

https://v8.dev/blog/ignition-interpreter

https://firefox-source-docs.mozilla.org/js/index.html#javasc...

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

#57
post #53

Earlier quoted context omitted.

Pretty sure these are very different phenomena both called "ubershaders". As far as I understand it, outside of Dolphin, when people say "ubershader" they mostly mean a large material shader that has branches and constants to handle all the material variants used in one game (e.g. wood door, metal shield, shiny forcefield). It's produced by the engine so it's under full control of the engine developers. This means in…

It sounded to me like an interpreter that emulates the GameCube / Wii GPU inside a shader, but I didn't read it closely

Yup, the whole vertex and pixel stages I believe.

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

#58
post #33
post #23

Earlier quoted context omitted.

gcn games never anticipated shader compilation time because it didn't exist. shaders weren't a thing when the gcn released. it may be arguable, but nobody even used the word at the time. shader compilation time is an issue for modern games on the PC, and because of this, developers anticipate and work around it. on the gcn, specialized fixed-function pipelines were available, and could be composed by some limited con…

Shaders as concept exists since 1980's, https://en.m.wikipedia.org/wiki/TMS34010 https://en.m.wikipedia.org/wiki/RenderMan_Shading_Language Just two examples, SIGGRAPH has plenty of paper on the subject.

[deleted]

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

#59

Earlier quoted context omitted.

The GAMES THEMSELVES are precompiled for the PowerPC architecture, not the PC architecture, though. That didn’t stop anyone from creating Dolphin. GPUs (I’m told) have far fewer instructions to emulate than a CPU, so I’d think that low level emulation of the Flipper shaders would be no trouble. Can’t translate or transpile them to PC GPUs though because those instruction sets are somewhat secret, I think. I know noth…

Yes, that’s exactly the point though. This is the same question as why you can’t emulate a game by precompiling its code, and this doesn’t work because that information isn’t available until you try to run the game. That’s why Dolphin has an interpreter/JIT.

>This is the same question as why you can’t emulate a game by precompiling its code, and this doesn’t work because that information isn’t available until you try to run the game.

I mean technically you can, but it generally requires a bunch of inefficient jump tables, or alternatively a way to fall back to an interpreter or JIT for self modifying code.

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

#60

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.

The wins here are probably not as large as one might think https://advances.realtimerendering.com/s2016/s16_ramy_final....

The fact is that a branch that the whole warp takes or does not take is relatively cheap on modern hw. Even if it is per thread dependent.

Post reply on HN