Closed ashleysommer closed 10 years ago
libvdpau-va-gl is a relatively thin layer, that uses VA-API interface provided by xvba-va-driver, which is also a compatibility layer to XvBA. I have almost no control on data provided by application, I just parse header, shuffle structures a bit to match API requirements and pass remaining bitstream as is. Looks like some combination of XvBA, GLX, and OpenGL calls make either Catalyst or underlying hardware stuck. Debugging of lockups is hard, but with closed-source components it's almost impossible.
VA-API decoding is working correctly in other applications like VLC.
VLC uses only VA-API, but I use it in combination with OpenGL. There is nothing hardware dependent used, but multiple contexts, excessive rendering to framebuffer objects, and frequent context switching in weird combinations are not usual type of load for a driver. It's like a stress test which Catalyst doesn't pass. My code surely can contain errors, but no error in user-mode library should put whole machine into unresponsive state. There is something with kernel drivers.
Im using libvdpau_va_gl 0.3.4-1 on Debian Sid. My VA-API backend is fglrx_drv_video, latest one available. I have a AMD Radeon HD 6870 card, using the latest FGLRX 14.04 drivers.
Whenever I load any flash video (with hardware acceleration enabled) the whole system will freeze completely, requiring a hard reboot.
If I specify AvoidVA in VDPAU_QUIRKS, then the video plays correctly, flash reports accelerated rendering is enabled but not accelerated decoding.
VA-API decoding is working correctly in other applications like VLC.
Is there any system logs which I can check to see what is causing the problem?