RADV Driver Lands Vulkan Video AV1 Decode For Mesa 24.1

[darkbasic]

Mesa d3d12 vaapi driver performance poorly and is usually inferior to software codecs unless the transcoding pipeline is full hardware accelerated.

True. Even the latest and greatest Phoenix APUs actually suck but at least there is a slight hope of improvements if you use Wayland: https://gitlab.freedesktop.org/drm/a...5#note_2295146
RDNA 3.5 will fare better thanks to VPE (https://gitlab.freedesktop.org/mesa/...requests/26841) but still no real world tests.
Intel cards are very good on the contrary because they are fully accelerated.

I wonder if AMD cards will be any better with vulkan video compared to vaapi.

[dlq84]

Video Vulkan should just present as both a VAAPI/libva driver and a vdpau driver as well. Then voila, will be more accessible

This is inevitable, but people think these things magically happens over night

[shmerl]

When will radv enable Vulkan video by default?

[shmerl]

Once advantage of VAAPI is that is has a processing API which allows you to take advantage of fixed function video processing engines which may be lower power that gfx. If you use vulkan video, you'd generally need to use a vulkan gfx queue to handle the CSC and scaling. This uses more power than the dedicated fixed function hardware. You could of course add a new queue type to vulkan to support these video processing engines, but that would be another multi-year project. Of course the ultimate low power solution would be to teach the compositors to use KMS planes to handle the CSC and scaling in the display hardware.

Why didn't they consider supporting these low power targeted queues with Vulkan video by default? It is marketed as a universal solution to replace VAAPI and others after all. So it should expose whatever common video hardware features are there as much as possible?

[geearf]

Once advantage of VAAPI is that is has a processing API which allows you to take advantage of fixed function video processing engines which may be lower power that gfx. If you use vulkan video, you'd generally need to use a vulkan gfx queue to handle the CSC and scaling. This uses more power than the dedicated fixed function hardware. You could of course add a new queue type to vulkan to support these video processing engines, but that would be another multi-year project. Of course the ultimate low power solution would be to teach the compositors to use KMS planes to handle the CSC and scaling in the display hardware.

Does that mean that if VAAPI works fine it should be used instead of Vulkan for now?
Would that free resources on the GFX so that more shaders and co could be used to enhance the video?

[Davo]

Of course the ultimate low power solution would be to teach the compositors to use KMS planes to handle the CSC and scaling in the display hardware.

Do you think this would be realistically doable or it's utopic to even propose it?

[agd5f]

Do you think this would be realistically doable or it's utopic to even propose it?

Yes, it's realistic. Planes are already used extensively on other OSes (e.g., windows, android) for low power video playback. Most hardware has had this functionality for years.

[agd5f]

Does that mean that if VAAPI works fine it should be used instead of Vulkan for now?
Would that free resources on the GFX so that more shaders and co could be used to enhance the video?

The idea is to avoid using GFX at all for video decode to save power. GFX uses a lot of power. Ideally we'd be using KMS planes as that is the most power efficient.

[agd5f]

True. Even the latest and greatest Phoenix APUs actually suck but at least there is a slight hope of improvements if you use Wayland: https://gitlab.freedesktop.org/drm/a...5#note_2295146
RDNA 3.5 will fare better thanks to VPE (https://gitlab.freedesktop.org/mesa/...requests/26841) but still no real world tests.
Intel cards are very good on the contrary because they are fully accelerated.

I wonder if AMD cards will be any better with vulkan video compared to vaapi.

You need to use KMS planes for low power video playback. vulkan video and vaapi are comparable with respect to power usage. Both use the video decode hardware for video decode and both likely use the GFX engine for color space conversion and scaling. At the moment vaapi has an advantage in that it supports an API for colorspace conversion and scaling that can make use of other memory to memory engines that may be lower power than GFX. Vulkan is more low level and needs explicit support for every engine type so it's harder to try and use some other hardware capabilities under the covers.

[agd5f]

Why didn't they consider supporting these low power targeted queues with Vulkan video by default? It is marketed as a universal solution to replace VAAPI and others after all. So it should expose whatever common video hardware features are there as much as possible?

They don't exist yet in vulkan. That's my point; you'd need to add support for them explicitly in vulkan. You might be able to enable them as an extension on top of transfer queues, but in some cases, these video processing engines may not support the baseline functionality needed for transfer queues so that may not be an option for every piece of hardware. Plus, you'd need to take advantage of this by using the new queues or extensions in the apps.