Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: Mesa/Gallium3D Works On VDPAU Interoperability

  1. #1
    Join Date
    Jan 2007
    Posts
    14,913

    Default Mesa/Gallium3D Works On VDPAU Interoperability

    Phoronix: Mesa/Gallium3D Works On VDPAU Interoperability

    Patches are pending to implement support for NVIDIA's VDPAU interoperability OpenGL extension within Mesa/Gallium3D...

    http://www.phoronix.com/vr.php?view=MTQ2NjY

  2. #2

    Default

    so VDPAU on amd?

  3. #3
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,900

    Default

    Quote Originally Posted by chris200x9 View Post
    so VDPAU on amd?
    vdpau is already ON amd if you use Radeon. Only Catalyst so far is stuck using xvba and hopefully its on the closed source dev's TODO list to rewrite the driver to do vdpau because I can't think of a single project that actually supports xvba except MAYBE XBMC.

    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.

  4. #4
    Join Date
    Aug 2013
    Posts
    4

    Default

    Quote Originally Posted by Ericg View Post
    So can you call VDPAU then re-call VAAPI then re-call xvba to get hardware accel working?
    Yes. With VDPAU driver with OpenGL/VAAPI backend

  5. #5
    Join Date
    Feb 2011
    Posts
    141

    Default

    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.

  6. #6
    Join Date
    Jul 2008
    Location
    Germany
    Posts
    681

    Default

    Quote Originally Posted by fritsch View Post
    a) xvba-va-driver is not cared since > 2 years.
    And in the time there are no changes in VA-API or XvBA. So why they should change something?

    Quote Originally Posted by fritsch View Post
    It has limitations (H264 Level 4.1).
    Its a Hardware limitation.

  7. #7
    Join Date
    Feb 2011
    Posts
    141

    Default

    You are plain wrong - it works, check.

    There was a hidden feature in the Linux driver, which was:
    Code:
    sudo aticonfig --set-pcs-u32=MCIL,HWUVD_H264Level51Support,1
    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.

    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.

  8. #8
    Join Date
    Feb 2011
    Posts
    141

    Default

    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 :-)

  9. #9
    Join Date
    Jul 2009
    Posts
    91

    Default

    Compiled mesa with the patch.

    XBMC now works like a charm.

  10. #10
    Join Date
    Feb 2011
    Posts
    141

    Default

    Yeah, recompile ckoenig has made a long workin weekend :-)

    Performance has improved another time.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •