Airlie Exploring Possibility Of VA-API On Top Of Vulkan Video

[phoronix]

Phoronix: Airlie Exploring Possibility Of VA-API On Top Of Vulkan Video

Well known open-source Linux graphics expert David Airlie of Red Hat has recently been working on early Vulkan Video support for Mesa's Radeon "RADV" and Intel "ANV" drivers. As part of that effort and in part due to lack of software making use of Vulkan Video extensions right now, he has started exploring the feasibility of implementing the Video Acceleration API (VA-API) atop Vulkan Video...

https://www.phoronix.com/scan.php?page=news_item&px=VA-API-On-Vulkan-Video-Hacks

[sarfarazahmad]

This is quite cool. Having video encode/decode instructions abstracted behind a graphics api. I think this is first time this is being done. I could be wrong

[Danny3]

Very nice!
I hope everything (video, games, compute) will be based on Vulkan in the future.

[jonix]

That looks interesting. Certainly a step towards Vulkan Video adoption.

If I am not wrong this Vulkan Video standard is still not released, what shows a big push of this (at least on open source community).

[schmidtbag]

This is quite cool. Having video encode/decode instructions abstracted behind a graphics api. I think this is first time this is being done. I could be wrong

Having not enough experience in development for 3D or video transcoding, I've wondered why this wasn't done over a decade ago. Clearly, it appears to be possible, so why didn't it happen sooner?

[lumks]

This is quite cool. Having video encode/decode instructions abstracted behind a graphics api. I think this is first time this is being done. I could be wrong

Correct me if I'm wrong, but isnt this the same as what Gallium3D does? Where the VAAPI state tracker sits on top of Gallium3D like VAAPI sits on top of a Vulkan driver?

[brent]

Having not enough experience in development for 3D or video transcoding, I've wondered why this wasn't done over a decade ago. Clearly, it appears to be possible, so why didn't it happen sooner?

Because APIs like OpenGL don't have any video decode capabilities? All those video APIs just expose video decode IP blocks to software. Except for buffer sharing there is no overlap with regular GPU rendering. That is why video decode capabilities are usually exposed through separate APIs like VA-API and then some buffer sharing mechanism like DMA-BUF is used if you want to use decoded frames from GL or Vulkan.

I'm often irritated because people tend to assume that everything becomes better, faster and more efficient just because Vulkan is involed. Spoiler: this is, in general, not true. Vulkan has strengths in specific use-cases. In many use cases, Vulkan does not have any or no significant advantages as far as performance and efficiency are considered. Video decode acceleration is one of these use cases. A unified API ecosystem still is advantageous for interoperability, though.

[frytaped]

Does this mean that we could get va-api working with the NVIDIA driver since it supports Vulkan video ?

[BlueCrayon]

Interesting that ARM boards are going into a completely opposite direction, moving all nasty video decoding into the kernel courtesy of v4l2 and m2m interfaces. I don't quite understand the need to keep it in userspace and separate from the kernel driver infrastructure

[ezst036]

Over the years Airlie has done amazing things for Linux graphics. Truely a "rockstar", to use that category.

I hope this can be leveraged for older generations of GPUs and APUs with the first generations of Vulkan. For example, Radeon HD 7xxx and Kaveri and Intel G gen7.