Vulkan

[niklaspandersson]

Initial support for Vulkan

• Drop in replacement of the opengl accelerator
• Image mixing should be on feature parity with the opengl image mixer
• Very limited compatibility and performance testing has been done
• Support for configuring which accelerator backend to use (defaults to opengl on linux and windows)
• New feature flag "ENABLE_VULKAN" (defaults to OFF on linux and windows) to opt in to building with vulkan support (since it requires new build dependencies)
• Initial support for macOS
• Very limited updates of the BUILDING documentation

[niklaspandersson]

I'll take a look at updating the build-workflows as soon as possible, so that we can enable vulkan in the automated builds

[Julusian]

I have no problem with using vulkan, but I do wonder if it is worth the complexity for us to support both vulkan and opengl?
I am worried about the complexity of maintaining the two code paths that will both need to be tested when touching the accelerator code, or doing anything with texture sharing. (Such as the gpu format conversion PRs I started).
There is already the challenge of testing windows and linux for some of these things, so I am hesistant to add more to the mix.
Of course, short term it is fine to have both until we are ready to commit to vulkan being the default.

Wikipedia suggests that for AMD gpus, ones as old as 2013 support vulkan 1.2, nvidia support 1.2 on 2012 cards.
That is less than the 2009/2010 age gpus that support the opengl 4.5 we currently require, but it still surely old enough?
Also, if we consider what is supported by windows 11 (as 10 is EOL), the oldest nvidia gpu is 2012, amd looks to be the same 2013 model, which is likely the oldest gpu we should expect to see on windows.

Which actually is a question of that I can see that the build is pulling in vulkan 1.4 headers instead of using the 1.1(?) available in the ubuntu package manager. Is this necessary?

[niklaspandersson]

I have no problem with using vulkan, but I do wonder if it is worth the complexity for us to support both vulkan and opengl? I am worried about the complexity of maintaining the two code paths that will both need to be tested when touching the accelerator code, or doing anything with texture sharing. (Such as the gpu format conversion PRs I started). There is already the challenge of testing windows and linux for some of these things, so I am hesistant to add more to the mix. Of course, short term it is fine to have both until we are ready to commit to vulkan being the default.

I agree. Just like with the GPU screen consumer. I think having both in parallell is a good thing until the Vulkan accelerator has been proven production worthy. After that we should remove the opengl accelerator. I think this could be done in a couple of steps. Beginning like this, where vulkan is opt-in. Step two, changing the default to vulkan, but allowing opt-out., before finally removing opengl. But that could all be only in master, I'm not saying that we have to takes these steps in official releases.

Which actually is a question of that I can see that the build is pulling in vulkan 1.4 headers instead of using the 1.1(?) available in the ubuntu package manager. Is this necessary?

There are some extensions that are very convenient, primarily related to dynamic rendering, but also the synchronization2, that get's pulled into core in 1.3 and 1.4. But we could check for the extensions instead of requiring the version where they enter core.

Related to the GPU format conversion PR. I think the Vulkan accelerator will simplify that effort. It especially makes the CPU/GPU synchronization at lot easier while maintaining parallellism, without having to explicitly wait. I would also like to use the gpu format conversion to fix proper support for ffmpeg hardware encode/decode (ie. without leaving the gpu)