Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

dolphin-emu.org

Post reply on HN
Print view View original

21–30 of 72 posts

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

#21

Post by naikrovek »

mappu wrote: post #19
naikrovek wrote: post #17

Earlier quoted context omitted.

I still don’t understand why you didn’t use the precompiled shaders packed with the games… you’re emulating the GameCube or Wii GPU, and it’s never going to change, and the games provide precompiled shaders.

They're precompiled for the console GPU architecture, not the PC architecture, so they can't be used directly and still need to be emulated - I think those precompiled shaders are the input to the ubershader.

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 nothing about this stuff but I am a developer so perhaps I know enough to ask the most stupid questions possible.

It’s gotta be a performance thing, why they didn’t emulate Flipper at a low enough level to use the precompiled shaders directly.

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

#22

Post by naikrovek »

phkahler wrote: post #20
naikrovek wrote: post #17

Earlier quoted context omitted.

I still don’t understand why you didn’t use the precompiled shaders packed with the games… you’re emulating the GameCube or Wii GPU, and it’s never going to change, and the games provide precompiled shaders.

Wait, I hought that's what the ubershaders are. What you say is what I kept thinking for much of the article - "just" emulate the GPU, no compiler needed. And then they did.

Maybe, lol, there were a lot of terms in that article that I didn’t understand well enough to claim I understood the article in toto.

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

#23

Post by ruined »

conorpo wrote: post #14

Does anyone know why this isn't an issue for modern games on PC? I assume it'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 eff…

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 configuration (literally, 24 instructions). you may think of this as a sort of proto-shader, but significantly, the fixed-function pipelines embody quite a lot of behavior in specialized and limited hardware that is now typically achieved in software on more versatile hardware.

so, to replicate that specialized hardware, modern graphics hardware (which exposes its greater capability as simple computational primitives) must compile a shader program and run it. but on gcn, the tiny configuration of static hardware loads near-instantly.

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

#24

Post by tom_ »

phire wrote: post #7
corysama wrote: post #4

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 "do very specific math and load textures in a single instruction" o…

> The Xbox could only load textures as the starting instructions before doing math and tried to make up for that with a few "do very specific math and load textures in a single instruction" ops. If you look closely, the TEV actually shares the same limitation, it's just that the traditional representation interleaves the texture fetch and math instructions (Because the 3rd texture fetch "instruction" always feeds int…

You could definitely define pixel shaders on the Xbox using a combiner type struct. See the D3DPIXELSHADERDEF struct in the docs, from memory the equivalent of one of the NV register combiner extensions from OpenGL with additional access to a secret extra stage ordinarily reserved for some fixed function pipeeline stuff.

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

#25

Post by phire »

Jasper_ wrote: post #13
phire wrote: post #11

Earlier quoted context omitted.

The only step that SPIR-V replaces is parsing the GLSL to an AST tree, and that's only a small part of the total time to compile a shader. Usually the bottleneck is Register allocation or scheduling. Back when Vulkan was developed, there were a bunch of OpenGL drivers out there which had random AST parsing bugs (Dolphin even has a bunch of workarounds for them); So a large chunk of the motivation for SPIR-V was avoid…

Shaving off the frontend costs is not going to be nothing . I don't know if Dolphin is still using FXC/D3DCompile or if they've switched to DXC, but FXC is infamously slow, even for very simple shaders. Dolphin's shaders are medium-complexity IIRC, so I'd expect removing the frontend to be a decent win. The driver PSO compilers aren't amazing but they're also not terrible. Most games do some form of hash-n-cache for…

> so I'd expect removing the frontend to be a decent win

I did some testing before working on ubershaders, and my modified build which cached the bytecode output of FXC/D3DCompile (whatever dolphin was using at the time) didn't reduce the stuttering by enough to be worth the effort of optimising the frontend.

My conclusion was that it's simply wasn't worth any effort to optimise for slightly smaller stutters, as they were still very perceivable to users. And Hybrid Ubershaders can hide any compile delays without any issue.

And this testing was with FXC/D3DCompile which does a bunch of optimisations. The fact that SPIR-V comes in (potentially) unoptimised means any vulkan compiler has to send it though all optimisation passes. Though I have been very tempted to do dead code removal before submitting the shaders, partly to make the shaders more readable to humans and partly to reduce the amount of code going though the various compiler passes.

> Being smarter about specialization is probably a good idea -- having a blend between "GPU interpreter" and "full specialized pipeline" is where I think you should head.

Yeah, that was always next on the list. Start with just ubershaders and then incrementally specialise on a background thread for the correct balance of shaders.

Dolphin's current specialised shaders are no-where near fully specialized. Need to go further by baking some of the constants and lookup textures into the shader.

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

#26

Post by phire »

naikrovek wrote: post #17
phire wrote: post #5

Has it really been 9 years since I started working on Ubershaders? I'm a little surprised no better solution has come along. Vulkan didn't even exist back then (and DirectX 12 had only just released) but instead of making things better, it digs it's feet even deeper into the assumption that all shaders will be known ahead of time (resulting in long "shader recompilation" dialogs on startup on many games). I've been t…

I still don’t understand why you didn’t use the precompiled shaders packed with the games… you’re emulating the GameCube or Wii GPU, and it’s never going to change, and the games provide precompiled shaders.

First, GameCube/Wii API actually generates the "shaders" at runtime, so there is simply no way to know which vertex/pixel pipeline states the game needs short of playing though the whole game, looking at every single bit of level geometry.

Many games actually dynamically generate new "shaders" on the fly, based on which lights are near an object, and in which order.

Second we can't use those vertex/pixel pipeline states directly on modern GPU, they need to be translated into modern shaders, and then compiled by the driver for your graphics card. It's actually that compile step which causes the stuttering, dolphin's translation is plenty fast enough.

The combination of these two facts means Dolphin can't depend on any pre-computation at all.

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

#27

Post by ploxiln »

conorpo wrote: post #14

Does anyone know why this isn't an issue for modern games on PC? I assume it'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 eff…

It is an issue for some modern big titles on PC. Trying to find some links that have somewhat general overview ...

https://twistedvoxel.com/unreal-engine-5-pc-stuttering-issue...

https://www.eurogamer.net/digitalfoundry-2022-df-direct-week...

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

#28

Post by saagarjha »

naikrovek wrote: post #21
mappu wrote: post #19

Earlier quoted context omitted.

They're precompiled for the console GPU architecture, not the PC architecture, so they can't be used directly and still need to be emulated - I think those precompiled shaders are the input to the ubershader.

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.

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

#29

Post by naikrovek »

phire wrote: post #26
naikrovek wrote: post #17

Earlier quoted context omitted.

I still don’t understand why you didn’t use the precompiled shaders packed with the games… you’re emulating the GameCube or Wii GPU, and it’s never going to change, and the games provide precompiled shaders.

First, GameCube/Wii API actually generates the "shaders" at runtime, so there is simply no way to know which vertex/pixel pipeline states the game needs short of playing though the whole game, looking at every single bit of level geometry. Many games actually dynamically generate new "shaders" on the fly, based on which lights are near an object, and in which order. Second we can't use those vertex/pixel pipeline sta…

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

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

#30

Post by MBCook »

Jasper_ wrote: post #16
conorpo wrote: post #14

Does anyone know why this isn't an issue for modern games on PC? I assume it'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 eff…

It is an issue with some modern games (I recently played a title that had a "Preparing Shaders..." loading screen); the main difference is that those games know the full set of what they need to do and can precompile most of them up-front, while an emulator like Dolphin needs to handle whatever the game throws it on the fly. Also, games might know what shaders it can skip and what it can't, but Dolphin can't skip sha…

It’s not a problem for the PS/Xbox/Switch. They have known hardware and it can all be recompiled.

But from what I’ve heard it’s often still an issue on PCs (I’m a Mac guy). I’ve seen videos of shader compilation stutters, even in games with a precompilation step that’s supposed to avoid that.

Digital Foundry has covered this many times. The link in a sibling comment to them on Eurogamer is a great place to start.

Post reply on HN