Announcement

Collapse
No announcement yet.

NVIDIA's VDPAU Implemented Over OpenGL/VA-API

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

  • NVIDIA's VDPAU Implemented Over OpenGL/VA-API

    Phoronix: NVIDIA's VDPAU Implemented Over OpenGL/VA-API

    Back-ends have been implemented for VDPAU to implement the video hardware-based decoding process over OpenGL and through Intel's VA-API interface, for those not using the NVIDIA binary blob or the VDPAU Gallium3D state tracker...

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

  • #2
    Arch has had this in the AUR for a few months now (https://aur.archlinux.org/packages/libvdpau-va-gl/), been using it for about 2 months now personally on my Sandy Bridge laptop. Works beautifully. Kudos to the developer.
    Last edited by Ericg; 08-06-2013, 01:00 AM.

    Comment


    • #3
      Interesting, so now we have not only VDPAU → VA-API, but also VA-API → VDPAU. That's pretty useful for Intel users. Maybe for fglrx users as well, either through OpenGL or XvBA → VA-API → VDPAU.

      Comment


      • #4
        Fragmentation is bad, I wish all drivers would use the same video acceleration API, or that all libraries all implemented a common interface.

        Comment


        • #5
          If I understood it correctly, this patch allows every application to target VDPAU which could then be accelated in either vdpau, va-api or opengl backends depending on the hardware support, thus, finally unifying the video accelaration api, at least on desktop distros. Did I get it wrong?

          Comment


          • #6
            Originally posted by uid313 View Post
            Fragmentation is bad
            Not always, but in this case, yes.

            Comment


            • #7
              Originally posted by Figueiredo View Post
              If I understood it correctly, this patch allows every application to target VDPAU which could then be accelated in either vdpau, va-api or opengl backends depending on the hardware support, thus, finally unifying the video accelaration api, at least on desktop distros. Did I get it wrong?
              I'm not sure... From the README on the github page, it sounds like:
              va-gl:
              1) Uses VA-API for video decoding when available, and GL for drawing/scaling support.
              2) Allows XvBA -> VA-API as well for fglrx users who've got xvba-va-driver installed.

              I don't see any mention of using GL for decoding, just drawing/scaling.

              That being said, if the user has an ATI/NVidia/Intel card, one of these options, or VDPAU directly (for NV or OSS radeon), should be available, which means that applications should be able to assume support for either VDPAU, or no hardware decoding. At least on most consumer desktop hardware.

              Now, what are the possibilities for ARM chips?

              Comment


              • #8
                Since fragmentation in this case is bad. Which one of the three choices should stay if we were to remove the others?

                Comment


                • #9
                  Originally posted by xeekei View Post
                  Since fragmentation in this case is bad. Which one of the three choices should stay if we were to remove the others?

                  Drivers which support VDPAU by default:
                  Nouveau (eventually)
                  Radeon
                  Nvidia
                  Gallium3D (Its a state tracker, works over OpenGL with shaders. Doesnt use hardware. Back-up solution only.)

                  Drivers which support VA-API by default
                  Intel
                  Poulsbo
                  Broadcom

                  Drivers which support XvBA by Default
                  AMD Catalyst


                  That all being said... there's ways and methods so that lets say AMD Catalyst can use VA-API despite offering XvBA (xvba-video). VA-API can use VDPAU with this driver, at least partially. Wikipedia also states that Intel MAY be looking into using VDPAU in the future, but, thats wikipedia soooo.. grain of salt with that.

                  To answer your question though... My opinion? Throw out XvBA, deprecate VA-API (ship this va_gl driver by default and enable it on Intel hardware). Everyone moves to VDPAU. AMD -may- even be looking to do just that given that they chose VDPAU for R600g.

                  In looking up which drivers support what, i did find this however: http://developer.amd.com/wordpress/m...Decode_API.PDF

                  Its a PDF from AMD describing a new, platform independent, API that hooks into the devices native hardware decoder combined with OpenCL for any and all video needs. Not sure Phoronix ever covered it.. (wink wink nudge nudge, Michael)
                  Last edited by Ericg; 08-06-2013, 12:19 PM.

                  Comment


                  • #10
                    Originally posted by Ericg View Post
                    Drivers which support VDPAU by default:
                    Nouveau (eventually)
                    Radeon
                    Nvidia
                    Gallium3D (Its a state tracker, works over OpenGL with shaders. Doesnt use hardware. Back-up solution only.)

                    Drivers which support VA-API by default
                    Intel
                    Poulsbo
                    Broadcom

                    Drivers which support XvBA by Default
                    AMD Catalyst


                    That all being said... there's ways and methods so that lets say AMD Catalyst can use VA-API despite offering XvBA (xvba-video). VA-API can use VDPAU with this driver, at least partially. Wikipedia also states that Intel MAY be looking into using VDPAU in the future, but, thats wikipedia soooo.. grain of salt with that.

                    To answer your question though... My opinion? Throw out XvBA, deprecate VA-API (ship this va_gl driver by default and enable it on Intel hardware). Everyone moves to VDPAU. AMD -may- even be looking to do just that given that they chose VDPAU for R600g.

                    In looking up which drivers support what, i did find this however: http://developer.amd.com/wordpress/m...Decode_API.PDF

                    Its a PDF from AMD describing a new, platform independent, API that hooks into the devices native hardware decoder combined with OpenCL for any and all video needs. Not sure Phoronix ever covered it.. (wink wink nudge nudge, Michael)
                    Thanks for the answer. I would also like an article on OpenVideo API.

                    Comment

                    Working...
                    X