so VDPAU on amd?
Phoronix: Mesa/Gallium3D Works On VDPAU Interoperability
Patches are pending to implement support for NVIDIA's VDPAU interoperability OpenGL extension within Mesa/Gallium3D...
so VDPAU on amd?
EDIT: Okay, so apparently (https://wiki.archlinux.org/index.php...o_acceleration) xvba can be pushed through vaapi. Great... But vaapi support isnt exactly super widespread either as far as I know... So can you call VDPAU then re-call VAAPI then re-call xvba to get hardware accel working?
Last edited by Ericg; 09-21-2013 at 07:07 PM.
That won't be really good to do. That ends like xvba-va-driver at the beginning, which was the reason we implemented direct xvba support in the first place. I think xbmc is the only software that ever did.
I hope that Christian can finish his work, so that the complete OSS world can use GL Interop in the future - this can also solve a bottleneck for VAAPI. This is working a bit different, but at a central point this could save us a complete surface copy (check xbmc LinuxRenderer Code).
For me the closed source driver and therefore XVBA is now obsolete. Cause of the following points
a) xvba-va-driver is not cared since > 2 years. It has limitations (H264 Level 4.1, rock solid unstable). It was abondened before even a lot of users used it. I have some patches arround here, that would solve that issue - I sent them to Kanotix and also upstream, but upstream did not care :-)
b) Nobodoy (despite a non mainline version of xbmc) implements XVBA
So - if the closed source linux people - take it serious, that would just abondon XVBA, implement vdpau directly. I think intel would be the last, that would keep their vaapi without doing also correct vdpau support, cause the pressure would be enormous - think of only one video decoding API for linux.
You are plain wrong - it works, check.
There was a hidden feature in the Linux driver, which was:
After that was found by debugging with gdb through the amdxvba.so symbols, it was enabled by default in the subsequent drivers. Since then Level5.1 with 16 Reframes work correctly.Code:sudo aticonfig --set-pcs-u32=MCIL,HWUVD_H264Level51Support,1
There was also a public driver changelog, that explicitely fixed the 16Reframes (which are at 1080p far over the Level41 High spec - but that you surely know).
Edit: Check the changelog: http://support.amd.com/us/kbarticles...easeNotes.aspx
I cite for you:
Fixed: 16 re-frames doesn’t work for H.264 @Level 5.1
Patch to make it work with xvba-va-driver: http://sprunge.us/YQGd
Last edited by fritsch; 09-22-2013 at 05:17 AM.
And if we are at it, check the radeon_uvd.c you will also see that there is a max reframe of 17 support by a size of 2048x1152 :-)
Compiled mesa with the patch.
XBMC now works like a charm.
Yeah, recompile ckoenig has made a long workin weekend :-)
Performance has improved another time.