SPIR-V for OpenGL

[Miksel12]

I have been reading about the use of SPIR-V for OpenGL as it is officially supported since 4.6 and I was wonder if using SPIR-V instead of GLSL would give better performance in Dolphin?
For Vulkan it would mean one less conversion step as it is currently compiling SPIR-V from GLSL.
Only problem I foresee is the post processing not working with SPIR-V.
Any ideas if it would be worthwhile to implement?

[mstreurman]

I have been reading about the use of SPIR-V for OpenGL as it is officially supported since 4.6 and I was wonder if using SPIR-V instead of GLSL would give better performance in Dolphin?
For Vulkan it would mean one less conversion step as it is currently compiling SPIR-V from GLSL.
Only problem I foresee is the post processing not working with SPIR-V.
Any ideas if it would be worthwhile to implement?

Shouldn't do too much unless you start optimizing it as it is not a "magical" change this and you get more performance, but if you have a GPU that fully supports OGL4.6 you usually have a CPU with it that can run 99% of the games at the magical framecap of 25/50 or 30/60 and thus not need the extra performance it brings.
The downside of it is that the GPU needs to support OGL4.6 which will make a lot of GPU's (mainly AMD's) and iGP's not being able to run the game in OGL anymore and it would completely break on MacOSX.

those are my 2 cents (but I'm not a developer so I can't really chime in)

[Miksel12]

Shouldn't do too much unless you start optimizing it as it is not a "magical" change this and you get more performance, but if you have a GPU that fully supports OGL4.6 you usually have a CPU with it that can run 99% of the games at the magical framecap of 25/50 or 30/60 and thus not need the extra performance it brings.
The downside of it is that the GPU needs to support OGL4.6 which will make a lot of GPU's (mainly AMD's) and iGP's not being able to run the game in OGL anymore and it would completely break on MacOSX.

those are my 2 cents (but I'm not a developer so I can't really chime in)

Yeah, after thinking about it, it probably isn't a big difference in performance. But it could streamline the videobackend:
spirv -> vulkan(and thus moltenVK)/opengl 4.6
spirv -> spirv-cross -> opengl 4.5 (and lower)
spirv -> spirv-cross -> d3d11/d3d12 
spirv -> spirv-cross -> metal (maybe in the future?)


I'm not a developer so i don't know if this would be beneficial and I don't no if spirv-cross is performant enough. 

[Stenzek]

FWIW, this is something I did consider, but I think spirv-cross was missing support for interface blocks in HLSL output.

There shouldn't be any significant performance differences. Perhaps shader compilation time may be reduced, but that's all.

[Miksel12]

FWIW, this is something I did consider, but I think spirv-cross was missing support for interface blocks in HLSL output.

There shouldn't be any significant performance differences. Perhaps shader compilation time may be reduced, but that's all.

And what about ubershaders? I understand that for the specialized shaders, it doesn't mater in which language they are once they are created when it comes to speed but ubershaders are much heavier. 
Thanks for your answer btw.

[mstreurman]

And what about ubershaders? I understand that for the specialized shaders, it doesn't mater in which language they are once they are created when it comes to speed but ubershaders are much heavier. 
Thanks for your answer btw.

To answer this question we have to look first at what Ubershaders really are:

What Ubershaders do is this: on Synchronous Ubershaders it completely emulates the Gamecube/Wii GPU pipeline. With Async Ubershaders it Emulates the full Gamecube/Wii GPU pipeline while in the background the Specialized shaders are being compiled, as soon as the specialized shaders are compiled it will use those from that moment on.

No Ubershaders compiles the specialized shaders on the go: this means everytime a shader isn't ready yet emulation pauses until it IS ready causing (micro)stutters. Async no ubershaders does the same as this except it doesn't pause the emulation and just keeps going causing the geometry/textures to "pop-in" whenever shader compilation is done (=missing graphics 'til done).

As you see *I'm not a dev though* once the shaders are done compiling, it shouldn't matter at all in speed as soon as the shaders have been created. Sync/full ubershaders wouldn't be faster either as the consoles GPU pipeline differs heavily from a PC GPU pipeline where a lot of instructions have to be completely translated, this is why we do not recommend to use the full ubershaders as it puts a high strain on your GPU with no added benefit compared to the async ubershaders and thus it should only be used for testing purposes. Changing the shader language doesn't magically add new functions to your PC GPU pipeline so it becomes easier to emulate a console's GPU.

[Miksel12]

I understand how ubershaders work and understand that hybrid ubershader is pretty solid in it's current state. I was primarily interested in exclusive ubershader because shaders are compiled every time the emulator is run, meaning that faster shader generation would be more important than with normal shaders. But if the conversion from Wii gpu bytecode to shaders is bottlenecked either way, it probablu doesn't matter to which shader lang/intermediate representation it is converted like you said.

The only significant reason to implement spir-v might be maintainability as it could simplify shader gen with spir-v cross. But using spir-v cross might not be desirable.

Thanks for your answers guys, was interested to hear some opinions on spir-v.

[Miksel12]

The wip 1.16 Cemu builds contain Vulkan (with SPIR-V) in which the shader compilation has been drastically cut down (https://youtu.be/Vl6AXbdHXjM?t=240) almost to the point where playing without shader cache would be bearable. While Cemu and Dolphin are not directly comparable, I think this shows that SPIR-V shader generation can be significantly faster than GLSL (Or something else has been drastically improved in regards to shader generation, which I doubt as such an improved would be probably be shared with GLSL).