Hacker News Reader

Comment by slaymaker1907 | Hacker News Reader

slaymaker1907

Why not take a profiling approach and cache the configurations rather than the compiled shader? You could then compile them on startup. By caching the configurations, you could then share this data between hosts and don't have to invalidate them as often.

View on HN

I don't know much about this topic. Is what you're suggesting distinct from the approach they addressed in the "Sharing Shaders" section?

https://dolphin-emu.org/blog/2017/07/30/ubershaders/#sharing...

Each configuration has a Unique ID, and they discuss building up a list of all the required UIDs beforehand:

> Users refer to this as "sharing shaders" and in theory if users shared UID files, they could compile shaders ahead of time and not encounter stuttering.

They list a few reasons why they didn't go for this, but the tl;dr is that it is hard to build a complete list, so many users in many games would still see stuttering.

It still seems like a good supplementary approach to the ubershader hybrid mode. Perhaps it'll be an idea that gets revisited at a later date, after the speed of changes to the graphics emulation code have slowed down.

this is kind of BS, all it takes is one cheap shared hosted server collecting shaders from users(upload every time you check for new version/once a day), you would build 95% complete list in couple of months.

Citation needed

Except that formats change between driver versions, among other things. I know of few games that aggregate their shaders, most just generate them during loading. There's a good chance you'd uncover some amusing bugs.

we are talking about caching TEV configuration, not compiled shaders. They were against this solution for ~3 years, how much coverage would they get in 3 years of users uploading missing Unique ID" objects?

At the end of the day you still have to compile the shader though. A shader cache is the only way around that.

Yes, and the parent comments are talking about a way to make it possible to compile all the shaders on startup instead of in the middle of the game. Longer loading times > stuttering.

The UID's are a dolphin invention, though, on the hardware level there are just a bunch of registers set. So either you store a complete dump of the cpu state for each shader configuration or you invalidate all shared shaders when dolphin internals change.

Awesome, go build it and prove them wrong

What I did was using two modes: in development mode, the shaders would be (re)compiled on the fly (causing some latency), and stored in a bank. In release mode, the shader-bank is used, and a shader compilation would be done if a shader wasnt found - supposedly rarely.

As far as I can tell it worked pretty well.

Could they use the "cut scenes" (?) to prime the shader cache(s)?

I mean those bits of animation between levels. I understood that many animations are scripted, vs movie recordings.

Apologies if I'm using the wrong words. I don't play many games.

This is an emulator. I assume they don't have the option of modifying the games to include high level optimizations like that.

They aren't able to predict what shaders will be needed.

In a traditional game this is exactly how it's done. Dolphin is a bit different though, because it's an emulator. It is aware that a game is using the GPU, but isn't aware of the inner workings of each game's logic. Dolphin doesn't know the difference between a cutscene, gameplay, a pre-rendered movie, or a credits sequence. Because of this, it has to be written in a more general manner, so that a game running inside of it can ask it to do anything a Gamecube or Wii would be able to do, and still come up with the right result.

Cut scene might have different shaders than in game, generally cut scenes are far more controlled and so might have higher quality shaders than in actual levels. And also that solution would only work in games with cut scenes and you would have to assume so cut scenes occur before the levels with the needed shaders in. So it would end up being a very brittle solution.

Reply on news.ycombinator.com