Announcement

Collapse
No announcement yet.

Mesa/Gallium3D Works On VDPAU Interoperability

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    so VDPAU on amd?

    Comment


    • #3
      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; 21 September 2013, 07:07 PM.
      All opinions are my own not those of my employer if you know who they are.

      Comment


      • #4
        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

        Comment


        • #5
          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.

          Comment


          • #6
            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?

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

            Comment


            • #7
              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; 22 September 2013, 05:17 AM.

              Comment


              • #8
                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 :-)

                Comment


                • #9
                  Compiled mesa with the patch.

                  XBMC now works like a charm.

                  Comment


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

                    Performance has improved another time.

                    Comment

                    Working...
                    X