application problems and VDPAU_QUIRKS=AvoidVA (on radeon)

[i-rinat]

application problems and VDPAU_QUIRKS=AvoidVA (on radeon)

[i-rinat]

Splitted-Desktop Systems VDPAU backend for VA-API

This is VA-API driver that uses VDPAU. It should be used when your drivers natively provide VDPAU interface, but you have an application, that can only use VA-API. One of such combination was previous versions of VLC player and nVidia hardware with proprietary drivers. I guess /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so on your system is a symlink to something like vdpau_drv_video.so.

On the contrary, this project, libvdpau-va-gl is a VDPAU driver that uses VA-API. Intel drivers provide only VA-API interface, so if you have an application that only can use VDPAU, such translation layer could be used.

So, wrapping up. When you override driver by setting environment variable VDPAU_DRIVER to va_gl, libvdpau-va-gl gets loaded. It tries to open VA, asks libva to load appropriate driver, which after all symlinks resolving is vdpau_drv_video.so. It in turn tries to open VDPAU driver, which is forced to libvdpau-va-gl, which tries to load VA-API driver and so on. You short-circuited it. (There are no infinite cycle, but just trying to lock the same mutex twice on a second lap.)

[i-rinat]

And I also don't understand why you are trying to use libvdpau-va-gl at all. Open source radeon drivers (in Mesa) have native VDPAU support. There are also native VA-API support, which is probably not enabled in that binary repo.

So, for mpv you just have mpv --> VDPAU driver (Mesa) --> hardware.
For gstreamer-vaapi you have gst --> VA-API driver (vdpau_drv_video.so) --> VDPAU driver (Mesa) --> hardware.

[vliaskov]

thanks for the explanation about the deadlock.

I was trying to use this backend because i have some problems with gstreamer-vaapi + opengl + vdpau-va-driver. I was thinking this backend could be an alternative backend, because vdpau-va-driver has not been maintained/updated for a long time as far as i know.

So this backend does not make any sense at all for radeon, sInce radeon already has native VDPAU support with the existing backend? Ok, i didn't understand this backend 's purpose correctly, we can probably close the ticket.

[i-rinat]

So this backend does not make any sense at all for radeon, sInce radeon already has native VDPAU support with the existing backend?

Correct.

However, I heard about (but didn't actually try) VA-API interface in Gallium3D drivers. So you could try to use native VA-API interface, and exclude vdpau-va-driver from the chain. Perhaps, you'll need to reconfigure and build Mesa from sources.