The project got most of the way there and stalled for more than a year due to burnout.įinally, another Dolphin dev, Stenzek, took up the task and helped see it through. Phire spent months working on ubershaders, and the solution seemed to be working, eliminating shader compile stuttering, but with just as many bugs and problems as you'd expect from a brand new form of GPU emulation.

Not to mention running an interpreter as huge shaders is not exactly easy on the GPU, and many were afraid that all that work might not even run full speed on current video cards.' The post continues: 'To put it into perspective, even among all the developers that work on Dolphin, only two or three people at most have the necessary knowledge on not only the GameCube/Wii hardware, but also modern GPUs, APIs, and the drivers to write, debug, and optimize the shaders. Theoretically, this would solve shader compilation stuttering by avoiding compilation altogether.' If we compile these massive shaders on game start, whenever a game configures Flipper/Hollywood to render something, these 'uber shaders' would configure themselves and render it without needing any new shaders. 'The crazy idea was born to emulate the rendering pipeline itself with an interpreter that runs directly on the GPU as a set of monsterous flexible shaders. 'What if we don't have to rely on specialized shaders?' asks the blog post. Finally, one of Dolphin's major contributors, phire, came up with a crazy alternative. That last problem is why, even though there's a popular branch of Dolphin that implements asynchronous shaders, the developers decided not to pursue it as a universal solution.

Worse: this actually permanently screws up some games. Essentially, if a shader is supposed to show up, instead of a stutter while it compiles, the game simply skips rendering it. That left one popular solution: asynchronous shader compilation, which is akin to 'pop in' in modern graphics engines. More critically, this would only work on a game-by-game basis, a big no-no for emulating a console, rather than specific games. What about sharing shader configurations for games between users? That was possible, but like shader caches, those configurations would have to be tossed out frequently with new Dolphin builds. Predicting shaders was considered, but the developers decided it would be too performance intensive, and due to the way games are programmed, likely wouldn't be effective, anyway. One amusing example is generating all the shaders beforehand, but the blog points out there are more possible graphical effects on the GameCube/Wii than there are grains of sand on Earth, so that seems impractical. So the developers tried to figure out a solution. But you're still going to experience stuttering as you encounter new effects, and upgrading builds, changing drivers, etc. That's why as you play games like Metroid Prime in Dolphin, the stuttering becomes less common. Typically a stutter only lasts a couple of frames, but on really demanding scenes with multiple compiling shaders, stutters of over a second are possible.'ĭolphin can cache shaders, so once a game has compiled a shader, it shouldn't cause stuttering again. Usually the compilation will take place in under a frame and users will be none the wiser, but when it takes longer than a frame, the game will visibly stop until the compilation is complete. 'To deal with this disparity, Dolphin's only option is to delay the CPU thread while the GPU thread and the video driver perform the compilation - essentially pausing the emulated GC/Wii. Dolphin has to translate those effects into shaders, and shaders have to be compiled, which takes time. In the GameCube/Wii GPU's case, configurations aren't stored in memory, and they can be called instantly. They can be preconfigured, since the hardware will never change. Consoles have fixed hardware, unlike PCs, so their shaders aren't written in the same way. Understand so far? Okay, so here's the problem with emulating shaders.

Dolphin emulator won't open mac