Vulkan rendersystem advantages

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


Post Reply
zxz
Gremlin
Posts: 184
Joined: Sat Apr 16, 2016 9:25 pm
x 19

Vulkan rendersystem advantages

Post by zxz »

Hello!

I've briefly looked into what is needed to move towards using the Vulkan rendersystem in our application (moving from GL3Plus). 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.

I have some understanding of what Vulkan is supposed to improve in general, but little understanding of what I can expect in the context of Ogre. Are there any resources about what advantages there are to using the Vulkan rendersystem in Ogre specifically? Are there any concrete, tangible benefits? Minor performance improvements? Major ones? Any improved GPU memory usage, or the same often wasteful texture arrays? Does it allow something that can't be done with GL3Plus? Maybe something I haven't even considered at all?

Thanks!

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Vulkan rendersystem advantages

Post by dark_sylinc »

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:

  1. Multi-window support. This has been always problematic with OGL.

  2. 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.

  3. 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

  4. 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.

  5. 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)

  6. 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).

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Vulkan rendersystem advantages

Post by dark_sylinc »

TL;DR: Don't expect major improvements. Overall it's an improvement on the quality of life as a developer on the little things that accumulate. Once you fix all the issues you'll notice your app becomes much more stable.

Vulkan drivers are thin, which means you rarely get a crash deep inside the driver (that wouldn't be caught by validation), unlike the OGL/D3D11 ones. With Vk when something goes wrong, it's likely your fault. With GL/D3D11 (specially GL) things randomly break with driver updates and require coordination with vendors.

IMHO it's worth it, but your mileage may vary. For example speaking with other non-OgreNext devs, their Vulkan on Android experience has been the opposite: they only enable VK on very specific phones. My personal experience is that I had to give up GLES on Android, and Vulkan runs quite well (not perfect, specially on older Androids. Android 10+ drivers run well).

zxz
Gremlin
Posts: 184
Joined: Sat Apr 16, 2016 9:25 pm
x 19

Re: Vulkan rendersystem advantages

Post by zxz »

Thanks a lot for the writeup!

The better profiling and shader debugging support sounds very useful on its own. Otherwise it seems like the benefits are somewhat tenuous and situation dependent.

I will probably make some attempt at porting our application to Vulkan, hoping that it won't be too difficult. I'm currently having issues getting a simple non-embedded window to resize without crashing the whole application, but I don't intend to pollute this thread with troubleshooting questions.

Post Reply