Announcement

Collapse
No announcement yet.

An Update On Generic GPU Video Decoding

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

  • An Update On Generic GPU Video Decoding

    Phoronix: An Update On Generic GPU Video Decoding

    One of Google's Summer of Code projects this year is to bring hardware-based video acceleration to Linux with Gallium3D. The advantage of this design is that the implementation is designed to be universal to any driver using Gallium3D, which for now is largely just the Nouveau driver and an experimental Intel version.With many of the open-source drivers currently lacking any form of GPU-based video decoding acceleration (such as XvMC or the forthcoming VA-API), this will be a terrific feature as it will provide this functionality once the drivers make the switch to Tungsten's Gallium3D as this method doesn't require any hardware/driver-specific work...

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

  • #2
    Seems like a waste of time to me if it's only an XvMC driver.
    XvMC is really useless today, the only time you would need mpeg2 acceleration is if you are on a 486DX.

    I believe a UVD2 implementation is what Linux needs. Not another XvMC driver.

    Comment


    • #3
      Does anyone know if the ati/radeonhd developers are planning to make use of Gallium3D?

      Comment


      • #4
        Originally posted by Chewi View Post
        Does anyone know if the ati/radeonhd developers are planning to make use of Gallium3D?
        Yes they will, once their first-cut R600/700 driver is working.
        Michael Larabel
        http://www.michaellarabel.com/

        Comment


        • #5
          Originally posted by cruiseoveride View Post
          Seems like a waste of time to me if it's only an XvMC driver. XvMC is really useless today, the only time you would need mpeg2 acceleration is if you are on a 486DX. I believe a UVD2 implementation is what Linux needs. Not another XvMC driver.
          This is actually pretty useful, since most of the work done for MPEG2 decoding via XvMC would also be re-useable for decoding H.264 or VC-1 via either an extended XvMC API or something new (VAAPI or whatever). It's also a good first step towards shader-based transcoding.

          Comment


          • #6
            I think it would be better to first provide such features to the drivers of manufacturers that work with the free software community through development efforts or providing hardware specs.

            People are of course free to code whatever they want, but I think it's a shame, all the skilled developer effort poured into reverse engineering Nouveau, that could have gone towards making the Intel or AMD driver implementation better.

            Comment


            • #7
              This shit always sounds cool, but from an end user point of view, it always takes like YEARS to fully enjoy something on linux (especailly related to gpus) and when this support kicks in, there will be 5 other cool ideas about whatever new 3d api. or am I wrong?

              Comment


              • #8
                Originally posted by cruiseoveride View Post
                I believe a UVD2 implementation is what Linux needs. Not another XvMC driver.
                I think this has more potential than UVD2. If I have understood it correctly, UVD2 is hardware that is limited to certain profiles of MPEG2/VC1/H.264. I have used another hardware solution (Popcorn Hour) and the profile constraints can make life difficult.

                This approach could lead to much more flexible decoding of different formats and profiles. XvMC is a good starting point to figure out how to do this kind of processing with hardware in X/Gallium3d environment.


                I'm hoping that Radeon drivers catch up soon. I have an NVidia 9600GT, which will probably take a long time to get free 3d support and the binary drivers are useless for this (and generally pretty bad quality.. can't wait to switch to ATI and free drivers).

                Comment


                • #9
                  Whatever it is, don't hold your breath.
                  How long has GNASH been going on for? a few decades now, and they can't even implement Flash 7 properly.

                  Good luck.

                  Comment


                  • #10
                    Originally posted by cruiseoveride View Post
                    Whatever it is, don't hold your breath.
                    How long has GNASH been going on for? a few decades now, and they can't even implement Flash 7 properly.

                    Good luck.
                    This will work, you don't even know what it is? In a few months, every gallium driver can add gpu-accelerated video decoding, within a few days at the max, rather than months/years (if it isn't a priority)

                    Comment


                    • #11
                      When that is done all we need is VA API support in Gallium and FFmpeg, then a few OpenGL GLSL shaders that are able to offload some of the H.264 decoding processes (like motion compensation and iDCT, to begin with at least).

                      So VAAPI support in Gallium and FFmpeg could possible be what is needed push more graphic manufactuers such as ATI, Intel, NVIDIA, and VIA to begin the active development of Gallium 3D device drivers.

                      There are also two more GSoC students and project by the way that is trying to achive GPU hardware acceleration video decoder via GLSL for OpenGL (one for the H264 decoder in FFmpeg for the XBMC project, and one for the Dirac codec for the Dirac Schrodinger project):
                      http://code.google.com/soc/2008/xbmc...DA81403F4B25AB
                      http://xbmc.org/wiki/?title=GSoC_-_G...Video_Decoding
                      http://code.google.com/soc/2008/dira...BC5171C6F4785F
                      http://www.diracvideo.org/wiki/index...er&action=edit

                      Video decoding processes that should be possible (in theory) to decode on a GPU:
                      • Motion compensation (mo comp)
                      • Inverse Discrete Cosine Transform (iDCT)
                      • Inverse modified discrete cosine transform (iMDCT)
                      • In-loop deblocking filter
                      • Intra-frame prediction
                      • Inverse quantization (IQ)
                      • Variable-Length Decoding (VLD), more commonly known as slice level acceleration
                      • Spatial-Temporal De-Interlacing, (plus automatic interlace/progressive source detection)

                      To sum up GPU Hardware Accelerated Video Decoding is really missing under Linux.

                      Comment

                      Working...
                      X