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

41–50 of 72 posts

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

#41

Post by mandarax8 »

doophus wrote: 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)

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

#42

Post by shzhdbi09gv8ioi »

OCASMv2 wrote: post #36
ruined wrote: 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…

A 2002 postmortem on the tech of Rogue Leader, a Gamecube launch title, already using the term "shaders": https://www.gamedeveloper.com/programming/shader-integration...

The first video card with a programmable pixel shader was the Nvidia GeForce 3 (NV20), released in 2001. [1]

1: https://www.techpowerup.com/gpu-specs/nvidia-nv20.g644

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

#43

Post by rkachowski »

naikrovek wrote: post #29
phire wrote: post #26

Earlier quoted context omitted.

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.

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 rendering operations to first class shader operations on a modern GPU. This very process causes the stuttering that starts the issue.

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

#44

Post by 91edec »

mandarax8 wrote: post #41
doophus wrote: 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 Steamdeck does this thats why it doesn't suffer from stutters.

For normal PC's, realistically Valve/Steam are the only people who could solve or implement this for PC games as they have the tech and platform to distribute it all. Even with all that its a crazy task to try and solve due to all of the variations and new patches for games that require the shaders to be recompiled again.

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

#46

Post by ErneX »

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.

PC games that have a shader pre compile step usually have to re do it when new drivers come out, pre compiled shaders can be shipped to closed systems such as consoles or even steam deck but not for PC. Each different GPU brand requires different ones and like I said even when you update drivers.

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

#47

Post by ErneX »

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…

This a big issue in modern PC games, games that don’t do a shader pre compile before starting the game suffer from serious shader compile stutters while playing the 1st time, dropping frames every time a new variation is required for a particular frame, it’s actually bad.

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

#48

Post by maccard »

91edec wrote: post #44
mandarax8 wrote: post #41

Earlier quoted context omitted.

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 Steamdeck does this thats why it doesn't suffer from stutters. For normal PC's, realistically Valve/Steam are the only people who could solve or implement this for PC games as they have the tech and platform to distribute it all. Even with all that its a crazy task to try and solve due to all of the variations and new patches for games that require the shaders to be recompiled again.

Honestly I think torrents are not a bad idea for this.

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

#49

Post by mst »

sfink wrote: 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…

I might have said "oh, _clever_" out loud when that first clicked as I read through the piece.
Post reply on HN