• Login
  • Register
  • Dolphin Forums
  • Home
  • FAQ
  • Download
  • Wiki
  • Code


Dolphin, the GameCube and Wii emulator - Forums › Dolphin Emulator Discussion and Support › Development Discussion v
« Previous 1 … 11 12 13 14 15 … 117 Next »

SPIR-V for OpenGL
View New Posts | View Today's Posts

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Threaded Mode
SPIR-V for OpenGL
03-06-2019, 11:56 PM (This post was last modified: 03-07-2019, 03:19 AM by Miksel12.)
#1
Miksel12 Offline
Member
***
Posts: 143
Threads: 7
Joined: Jan 2019
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?
Find
Reply
03-12-2019, 08:08 PM (This post was last modified: 03-12-2019, 08:08 PM by mstreurman.)
#2
mstreurman Offline
Above and Beyond
*******
Posts: 1,239
Threads: 11
Joined: Nov 2015
(03-06-2019, 11:56 PM)Miksel12 Wrote: 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)
Check my profile for up to date specs.
Find
Reply
03-13-2019, 12:13 AM (This post was last modified: 03-13-2019, 07:25 AM by Miksel12.)
#3
Miksel12 Offline
Member
***
Posts: 143
Threads: 7
Joined: Jan 2019
(03-12-2019, 08:08 PM)mstreurman Wrote: 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. 
Find
Reply
03-30-2019, 12:53 AM
#4
Stenzek Offline
Junior Member
**
Posts: 17
Threads: 0
Joined: Nov 2016
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.
Find
Reply
03-30-2019, 11:09 AM
#5
Miksel12 Offline
Member
***
Posts: 143
Threads: 7
Joined: Jan 2019
(03-30-2019, 12:53 AM)Stenzek Wrote: 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.
Find
Reply
03-31-2019, 05:38 PM (This post was last modified: 03-31-2019, 05:45 PM by mstreurman.)
#6
mstreurman Offline
Above and Beyond
*******
Posts: 1,239
Threads: 11
Joined: Nov 2015
(03-30-2019, 11:09 AM)Miksel12 Wrote: 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.
Check my profile for up to date specs.
Find
Reply
03-31-2019, 10:18 PM
#7
Miksel12 Offline
Member
***
Posts: 143
Threads: 7
Joined: Jan 2019
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.
Find
Reply
09-07-2019, 07:06 AM (This post was last modified: 09-07-2019, 07:12 AM by Miksel12.)
#8
Miksel12 Offline
Member
***
Posts: 143
Threads: 7
Joined: Jan 2019
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).
Find
Reply
« Next Oldest | Next Newest »


  • View a Printable Version
Forum Jump:


Users browsing this thread: 1 Guest(s)



Powered By MyBB | Theme by Fragma