Good points.
I don't think I ever elaborated on this. Time to do it:
zxz wrote: ↑Thu Mar 23, 2023 5:41 pm
The Vulkan rendersystem seems rather picky, and easy to crash and/or cause various API errors. So quite a bit of work will be required to make the transition. For that reason, I'd like to determine the possible benefits before doing all the work.
Yes, Vulkan is picky; which is why I keep OpenGL support for fast prototyping (it will accept errors without complaining, which is nice when you just want to get your algorithm to render).
But for overall stability, Vulkan complaining means your OGL version was either more likely to break on another system, or slowdown. Though, half of the complains will be Vulkan-specific.
As to the benefits:
-
Multi-window support. This has been always problematic with OGL.
-
Android support.
-
Requires care (i.e. periodical testing) because it's a different platform with lots of quircks that aren't graphics-specific (i.e. properly handling suspend/resume, optimizing boot speed on slow devices, testing for ANRs); but there are also a lot of gpu driver bugs so if your rendering does something an Android GPU doesn't like, you should catch it early on
-
But other than that, Android is a big market and can be quite profitable. And our use of Vulkan is quite compatible with Android devices.
-
Memory Management is mostly on OgreNext side. Which means bugs are often up to us. This is a good thing because we've been bitten before by GPU driver bugs where the driver allocates until it runs out of memory.
-
But it may also require some care for you, as drivers tend to be more lenient (i.e. if you overallocate and don't use it, they forgive more)
-
See Samples/2.0/Tutorials/Tutorial_Memory
. Monitor your mem usage.
-
There's fewer stutters when creating/destroying buffers and textures because of how memory management works
-
OGL has multiple quircks that are not immediately visible. For example on X11 (Linux) it is impossible to request a D32 bit depth buffer. You'll end up with a D24_UNORM. This can cause rendering issues because you get less precision and can't use reverse depth either.
-
Better support from Tools:
-
Profilers (e.g. AMD Radeon GPU Analyzer)
-
RenderDoc has shader debugging (works on DX11 and Vulkan, but not OGL)
-
Overall more stable integration with tools (as long as there's no validation errors)
-
Looking forward, more features:
-
CIVCT Indirect Illumination runs like crap on OpenGL. OGL drivers have very poor support for advanced techniques like indexing an array of texture3d textures, which is needed by this GI technique.
-
OGL has a limit of 32 bound textures on most drivers. Vulkan has no such limit.
There are downsides of course. Integration with other tools (e.g. Qt) is lagging behind. If you want to integrate with QML, you'll need Qt 6.
The older the 3rd party tool, the more you'll have a better experience with OGL. The newer, the better experience you'll have with Vulkan.
Notice that I didn't mention performance. This one is tricky because a Vulkan engine basically is similar to writing a GPU driver.
Vulkan has multiple optimizations we take advantage of (like the use of dont_care
load and store semantics, though you have to specify it in the Compositor and you can debug it in RenderDoc; we also do proper batching of barriers) but on the other hand OpenGL (and DirectX) drivers are heavily optimized* and is hard to compete against the best driver implementations (that's why we shine on Mobile, Android OGL drivers are so bad it is easy to outmatch them).
\* What most drivers do is record the commands we do (e.g. glDrawPrimitive calls and stuff), send it to a worker thread, analyze the whole stream; merge and remove anything redundant, reorder what can be reordered, and then issue the work to the GPU.
On Vulkan we are supposed to do that ourselves and we don't do that yet (though for 4.0, we are introducing parallel shader and PSO compilation and that causes significant boosts)
Therefore don't expect significant performance boosts (there are exceptions). In fact on your particular system it may run slightly slower than the OGL/DX11 version when looking at the average FPS, but that says little about the 1% percentile and cold boot times (which is usually where our Vulkan implementation shines).
Personal experience: Our game engine works on Vulkan as main and while it took a little time to fix some of the issues, now I don't want to go back. It works super stable, works exactly the same on all platforms (except Apple, which uses Metal), doesn't have any major issues. When I turn on OpenGL or DX11, usually some problem arises.
The main advantage is that the features we use from Vulkan are everywhere. If the GPU supports Vulkan, then it supports our renderer. The same cannot be said about OGL. And when it comes to DX11, some issues sometimes arise.
Granted, my experience is biased because "Vulkan (and Metal) main" means our GL & DX11 support will get less attention. But back when we supported GL+D3D11, we always had to fix some issue because "random xyz system on the customer breaks" (i.e. "it works on my machine") and we are not getting this problem with Vulkan. "It just works", which is something I am heavily surprised (personally I was scared it would break in a billion ways).