[feature request] vulkan support?

[tails101]

It would be nice to have vulkan support since it is lighter than openGL for the cpu.
It is useful for low power android devices, 3dfx games can be a bit laggy.
Vulkan have better crt shaders too.

[alexb3d]

It does and it is the recommended one.

The graphics API is handled by RetroArch, not the core. It is configured in the main menu, video, output. But it depends on your device, if it supports this technology. If it is not compatible, you have glcore, which also supports the same shaders.

[schellingb]

The topic is about supporting Vulkan in the hardware accelerated 3dfx emulation. Currently that only supports OpenGL and I suspect it will be so for a long time. Vulkan support would be nice but I'm not very eager to learn it currently. It seems overly complicated and bloated which is not really in the spirit of how I like to maintain the code base. But if someone were to contribute an implementation, I'd very happily look into integrating it, cleaning the code up as much as possible, making it fit nice.

[alexb3d]

Ok, I understand, it can be a speed benefit, although, especially on modern hardware, most older devices don't support it.

Is this why voodoo on Windows doesn't work properly with hardware acceleration?

[tails101]

no it is just, vulkan is better for modern low power devices.
so android phones,mini pc,shield tv,rpi4 or 5...stuff like that.
stuffs with under powered cpu but with gpu modern enough to support vulkan 1.3
and are generally a lot faster on vulkan than open gl.
by the way i tried to force vulkan in retroarch but it switch back to open gl every time it run a 3dfx game.

[schellingb]

As I said, we only have a OpenGL/OpenGLES renderer in DOSBox Pure. It's either that or software rendering for the 3dfx emulation (which is still the default). Making the GL renderer was by no means an easy task. Though 3D rendering is not something I'd consider myself an expert in. I have used OpenGL over the last few decades and it is always fairly pleasant to use. As far as I know Vulkan is a different beast, much more code required, much more complex.
But in the end, before this year we only had software rendering, now we have the GL rendering which is magnitudes faster. If all the effort were now spent on making a Vulkan renderer it wouldn't be another magnitudes faster. So the benefit of having one renderer (GL) vs. software only is very substantial. Having a second renderer is good for compatibility and (perhaps) some minor performance benefits, but it's by no means on the same level.
Maybe some day I will have the time and motivation to get into Vulkan and do what is necessary. But it won't be soon. Until then, as mentioned, contributions are welcome :-)

[the-burrito-triangle]

I think the issue with most Android Phones is that they don't actually implement the full OpenGL 4.6, but rather a subset called OpenGL ES and is why they seem to work better with Vulkan.

I'm on Linux and thought that Vulkan would out perform OpenGL on my AMD RX 7600, Intel Xe RocketLake-S GT1 (32EUs), and Intel Iris Xe TigerLake-LP GT2 (96EUs) GPUs, but this is not the case--at all!

OpenGL uses less power (as measured by nvtop and intel_gpu_top) and can make the Intel iGPUs play games at 4k resolution. Yes 4k on an iGPU. Intel's GPUs seem to be well optimized for OpenGL and not so much for Vulkan. We are talking 20fps (or less) on Vulkan vs. 60fps on OpenGL for many games with the exact same settings and resolution (only different graphics API). Testing was done with various wrappers for Windows native games and emulators such as DuckStation, PCSX2, Citra and so on.

Vulkan support, while nice to have, will only provide better performance on a small number of devices in practice. For example, Apple users would be forced to wrap Vulkan to Metal using Molten--which only supports a subset of Vulkan's feature set. So native OpenGL / OpenGL ES might still out perform Vulkan on Apple HW.

Then there are the myriad vendor extensions for Vulkan that unlock a lot of performance, but who is going to optimize the engine for each supported manufacturer? And to be fair, I believe OpenGL has similar vendor extensions, but Vulkan has waaay more of them.

[schellingb]

While the variations of OpenGL (3, 4, ES2, ES3, to some extent WebGL) can be a bit of a nuisance, as a programmer it still feels like very common API evolution. In this case, it took me like a months to make the desktop OpenGL renderer and then a few days to make it run on OpenGLES which made it work on Android, iOS and Linux on some devices/configurations.

I cannot estimate how long implementing a Vulkan renderer would take. My guess is even for someone well versed in the Vulkan API it will take less than a month (certainly a decent amount of the overall approach to the OpenGL renderer still applies) but more than a week. A big worry for me is code bloat, but that might be just because I hear how terrible Vulkan can be, needing thousands of lines of code just to draw one triangle :-)

It would be nice to support as many renderers as possible so people who have set their RetroArch to use one video driver won't make starting our core switch the driver on startup to something else (because the set preference isn't supported). Vulkan certainly is next on the list. Though I don't even know if Direct3D or Metal is an option for a libretro core. It would be quite funny if we can't find any device where Vulkan would provide better performance, but I'm sure that wouldn't be the case.

Optimizing the OpenGL renderer of course is also an option. Maybe even a more realistic one.