CasparCG
Vulkan
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
I'll take a look at updating the build-workflows as soon as possible, so that we can enable vulkan in the automated builds
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?
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)
Now that 2.5 is released, feel free to unmark this as a draft whenever it feels ready enough to merge. I don't mind if it isnt fully functional, seeing as it wont be compiled by default.
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.
For 2.6 I have already dropped 'official' support for ubuntu 22.04, and 24.04 has vulkan 1.3 in the system repositories, which should simplify a bit if that can be the target.
As for GPU support, I am happy to say we require 1.3 for now, and when we evaluate if that needs some ability to degrade nearer to the point of making it the default/only compositor. But I expect it will result in the same extension checks, so wouldnt harm to do it now either.
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.
Yeah,I've not had much motivation to continue on that recently, and that was made easy once you started on this :laughing: . tbh I was expecting the sync to not be a problem, but I didn't test under much load so maybe it wasnt.
But once this is merged maybe I can see if I can get that rebased onto this and see where it stands. The challenge now will be how to do it without needing to do the same work for both opengl and vulkan, as that will be tedious to do everything twice and just result in bugs. But maybe it is possible to keep things working similarly to today for opengl and keep the new stuff for vulkan