4 ms·
I haven't really done a whole lot with Vulkan yet but this really makes me curious if Vulkan could ever find itself as an alternative to VAAPI on Linux in some
by jchw 4y ago
I haven't really done a whole lot with Vulkan yet but this really makes me curious if Vulkan could ever find itself as an alternative to VAAPI on Linux in some cases. Vulkan for compute purposes already seems like a pretty compelling idea, as it is, but in both cases I wonder, but was unable to ascertain an answer with a cursory glance, if it is possible today or maybe will ever be possible, to expose devices to Vulkan that are not GPUs (like compute accelerators.) Perhaps it's not even really a good idea :) The case is probably stronger for compute devices a la OpenCL, since at least for video, if you're targeting Linux anyways, it seems like you could use dma-bufs to pass buffers between Vulkan and VA-API and other stuff. Still, it does inspire curiosity.
A cursory search did seem to suggest encoding was supported as well as decoding in Vulkan, which is very cool.
- shmerl 4y agoYes, the general idea is for it to replace VAAPI for all relevant use cases. I'd expect it also to move faster than VAAPI moves now once all things are in place (like adding new hardware and etc.). It might be also possible to implement actual VAAPI over Vulkan video.
- jchw 4y agoHmmm, interesting: maybe the last bit is the key to working around the issue that Vulkan drivers can really only exist for GPUs (to my knowledge, anyways). You could still have VA-API drivers for devices other than APIs, alongside a Vulkan implementation.
- bubblethink 4y ago> if Vulkan could ever find itself as an alternative to VAAPI The bar to beat VAAPI is really low. For all practical purposes, VAAPI doesn't exist. So any alternate plan, even if it is essentially the same thing underneath, is worth a shot.
- redeeman 4y agoexcept all the practical usage that a lot of linux users have. using your logic, linux on the desktop doesnt exist, and yet it does. Yes, much fewer use it than windows, but those who use it do still use it
- pjmlp 4y agoMy single desktop experience is that no matter what I do with VAAPI on my netbook (the only device left with GNU/Linux), I only get software rendering on Chrome/FF.
- bubblethink 4y agoI meant that vaapi is broken beyond repair and a lost cause.
- cillian64 4y agoOn Linux there is already an alternative to VAAPI: The Video4Linux Memory-2-memory (V4L2-M2M) API, which provides a standardised API for hardware encode and decode accelerators (and supports using DMA-bufs for copy-free decoding or using decoded frames as textures). I don't know how much support there is for AMD/nvidia/intel but it works well on the Raspberry Pi at least. It would feel weird for Vulkan to become the standard API for encode/decode given that (as you say) video accelerators aren't necessarily tied to the GPU (although not necessarily weirder than doing it through an extension of the webcam API).
- deleted 4y ago[deleted]
- jchw 4y agoTruth told, Raspberry Pi is the only device I've ever used v4l2 to do video encoding with. It does seem to work well enough, but since I was using it via GStreamer, I have no idea what the API looks like. The advantage of Vulkan is that they've already got a functional and productive committee with all of the GPU vendor stakeholders to work out the design, whereas VA-API and VDPAU seem to have somewhat different designs and seem to be mostly championed by a single GPU vendor. I have a bit more confidence that the Vulkan designs for hardware accelerated video will be good for both hardware vendors and application developers (even if it is still low-level.) In a neighboring comment thread, hrydgard states that it is very much possible to have a Vulkan driver that has only video encoding/decoding queues, which if true resolves the potential awkwardness in my opinion. That's especially relieving if true as well since Vulkan looks to be a prime contender to take up the mantle for OpenCL as well; especially believable now seeing what has been done with rusticl. Perhaps it is still a little awkward, but Vulkan as a general hardware acceleration abstraction layer seems like it could be a very good thing. As it is, as an application developer, you're probably better off on Linux just using GStreamer or Pipewire rather than v4l2 directly, since some devices (e.g. Blackmagic Decklink) provide GStreamer integration but not v4l2 drivers. In that case, it hardly matters what API abstracts the hardware as long as it does a good job of it.