search

i-rinat / libvdpau-va-gl

VDPAU driver with OpenGL/VAAPI backend
MIT License
161 stars 26 forks source link

application problems and VDPAU_QUIRKS=AvoidVA (on radeon) #47

Closed vliaskov closed 8 years ago

vliaskov commented 9 years ago

Test system is Ubuntu 14.04 with ATI HD7850 (radeon driver) and mesa/graphics stack from https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers

I 've compiled both 0.3.4 and master libvdpau-va-gl, but vainfo gets stuck (never returns) when using the vdpau-va-gl backend.

VDPAU_LOG=1 VDPAU_DRIVER=va_gl vainfo
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_37
[VS] Software VDPAU backend library initialized
[VS] {full} vdp_imp_device_create_x11 display=0x225f430, screen=0
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_37
[VS] {full} vdp_imp_device_create_x11 display=0x242e810, screen=0

The backend/vainfo only returns with VDPAU_QUIRKS=AvoidVA:

VDPAU_QUIRKS=AvoidVA VDPAU_LOG=1 VDPAU_DRIVER=va_gl vainfo
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_37
[VS] Software VDPAU backend library initialized
[VS] {full} vdp_imp_device_create_x11 display=0x767430, screen=0
[VS] {full} VdpGetApiVersion
[VS] {full} VdpGetInformationString
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.38 (libva 1.6.0)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.5.pre1
vainfo: Supported profile and entrypoints
[VS] {part} VdpDecoderQueryCapabilities device=1, profile=VDP_DECODER_PROFILE_MPEG2_SIMPLE
[VS] {part} VdpDecoderQueryCapabilities device=1, profile=VDP_DECODER_PROFILE_MPEG2_MAIN
[VS] {part} VdpDecoderQueryCapabilities device=1, profile=VDP_DECODER_PROFILE_MPEG4_PART2_SP
[VS] {part} VdpDecoderQueryCapabilities device=1, profile=VDP_DECODER_PROFILE_MPEG4_PART2_ASP
[VS] {part} VdpDecoderQueryCapabilities device=1, profile=VDP_DECODER_PROFILE_H264_BASELINE
[VS] {part} VdpDecoderQueryCapabilities device=1, profile=VDP_DECODER_PROFILE_H264_MAIN
[VS] {part} VdpDecoderQueryCapabilities device=1, profile=VDP_DECODER_PROFILE_H264_HIGH
[VS] {part} VdpDecoderQueryCapabilities device=1, profile=VDP_DECODER_PROFILE_VC1_SIMPLE
[VS] {part} VdpDecoderQueryCapabilities device=1, profile=VDP_DECODER_PROFILE_VC1_MAIN
[VS] {part} VdpDecoderQueryCapabilities device=1, profile=VDP_DECODER_PROFILE_VC1_ADVANCED
[VS] {full} VdpDeviceDestroy device=1

But VDPAU_QUIRKS=AvoidVA does not solve problems with applications. E.g. gstreamer-vaapi pipeline works with normal va-vdpau-driver backend:

gst-launch-1.0 filesrc location=/opt/vliaskov/Videos/3_neu.mp4 ! qtdemux ! vaapidecode ! vaapisink

but not with 

VDPAU_QUIRKS=AvoidVA VDPAU_LOG=1 VDPAU_DRIVER=va_gl

Output of backend here: http://pastebin.com/mGhDnZCT (there was no compatible capabilities found between vaapidecode element and output vaapisink element of gstreamer. This is with gstreamer 1.5.2)

Without AvoidVA, initialization gets stuck the same way as vainfo.

Should the backend work without AvoidVA? Even with VDPAU_QUIRKS=AvoidVA are these errors expected?

i-rinat commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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.