Announcement

Collapse
No announcement yet.

A few questions about video decode acceleration

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

  • #71
    Good *GOD* what a rush.

    Open source driver implementing MPEG2 and h264 acceleration?

    This is why I now buy AMD and ATI products instead of Intel and nVidia.
    OK, I know, Intel are doing it to. But they're expensive! ^.^
    Even if it doesn't happen with UVD2.
    SO EXCITED!!! 8D 8D 8D

    J1M.

    Comment


    • #72
      > Good *GOD* what a rush.
      >
      > Open source driver implementing MPEG2 and h264 acceleration?

      Huh? I can't find an announcement anywhere.

      Great news if it is true.

      Comment


      • #73
        The gallium frontend to XvMC, I guess

        Comment


        • #74
          Originally posted by Dieter View Post
          > Good *GOD* what a rush.
          >
          > Open source driver implementing MPEG2 and h264 acceleration?

          Huh? I can't find an announcement anywhere.

          Great news if it is true.
          Sorry, I meant the *idea* of it.
          And even if it's not been announced, it's been talked about by the right people in the positive.
          I've always been planning to get a 780g/4850e machine for the living room (mythtv) but I'm going to BOUNCE UP AND DOWN ON MY SOFA HOPING FOR UVD2 SUPPORT!!! *D

          We're no longer standing still or moving in the wrong direction.
          For so long it's all been held back by companies keeping the specs for their hardware closed.
          Now, hopefully, with a few shining examples of how it's good PR and makes financial sense, everybody else will follow suit.

          'lest they fall behind with a Mineshaft Gap.

          And even if it never comes to pass, ATI are aiming for feature parity with Windows with fglrx, yes? Doesn't that mean UVD? Right? DRM? (As in digital rights, not the other DRM)

          I'm just sitting here hoping and being excited about all this.
          Probably too excited but I just don't care.

          J1M.

          Comment


          • #75
            > The gallium frontend to XvMC, I guess

            Assuming the SoC project goes well.

            But... then we need gallium for ATI. Is anyone working on that?

            Comment


            • #76
              Two parts to the answer :

              1. There are some pre-requisites which need to be at least partially in place for Gallium. A modern memory manager in drm is the first priority (Dave Airlie is working on that) and I believe DRI2 will be needed as well -- and DRI2 also needs the new memory manager.

              2. In terms of development priorities, we are aiming to get at least basic 3d functionality running on "classic mesa" before beginning implementation on Gallium, so that developers are only faced with the challenge of learning the chips and not learning a new environment & API at the same time. This definitely made sense for 5xx but 6xx/7xx will probably be the last generation where we get things running on "classic Mesa" before Gallium.

              Documentation and community knowledge for 5xx and earlier is good enough to support Gallium work today; glisse did some preliminary work a few months back, and MostAwesomeDude is eyeing Gallium now. I expect that work on both DRI2 and Gallium will ramp up over the next month or so as (a) we make more progress on 6xx/7xx 3d and (b) Dave's work on a new memory manager gets a bit further along.

              Memory manager => DRI2 => Gallium

              Memory Manager => Kernel Modesetting

              Work on the above initiatives can start in parallel to a certain extent, but they really need to "come up" in the order above and certainly need to finish in the order above.

              So... real soon now
              Test signature

              Comment


              • #77
                Originally posted by TechMage89 View Post
                Windows drivers are kind of messy because a large amount of the code goes in-kernel. Hopefully, Windows 7 should fix that, but you have to expect that the Windows graphical system will be less stable than the Linux graphical system.
                Do you think that the move to Kernel Modesetting is going to lighten the load on the Linux kernel? We are actively pushing more into the kernel while Windows is trying to pull things out. There are religious wars over drivers in userland/kernel so let's avoid it here....

                When kernel modesetting kicks in, the X developers, FB developers and other random display developers are all going to have to find a way to support the same OSS driver. If we end up with 3 kernel based graphics drivers, then I don't believe we have improved the situation.

                Regards,

                Matthew

                Comment


                • #78
                  Originally posted by chaos386 View Post
                  This may be coming a little out of left field here, but what about using CAL/GPGPU? Would it be a reasonable way to avoid the legal issues surrounding the UVD, or would it be so much slower that it wouldn't be worth the effort?

                  In any case, using the GPU to accelerate video encoding would be a dream come true, and if that gets done, how much more work would decoding be?
                  Video encoding is probably best suited to OpenCL (I will use that term instead of CAL/OpenCL/CUDA/Shader/whatever), since in general that is done away from the consumers desktop.

                  The OpenCL based solutions scale their performance with the number of shader cores that are available. This means the effectiveness will scale with hardware.

                  The Proprietary driver has used shader based video (only colorspace conversion/attributes) since R5xx, and shader based 2D since R6xx, and has some people have been playing with RENDER acceleration (TexturedVideo, Textured2D and TexturedXRender). It does work, but it does present a number of technical issues that need to be resolved, and realistically we focus a lot more on 2D acceleration than video.

                  I am absolutely in support of the GP-GPU approaches to computing problems (including xvmc/h264 decode), but just be aware that the performance of those solutions will scale with hardware.

                  Regards,

                  Matthew
                  Last edited by mtippett; 16 July 2008, 03:38 PM.

                  Comment


                  • #79
                    Originally posted by mtippett View Post
                    The Proprietary driver has used shader based video (only colorspace conversion/attributes) since R5xx, and shader based 2D since R6xx, and has some people have been playing with RENDER acceleration (TexturedVideo, Textured2D and TexturedXRender). It does work, but it does present a number of technical issues that need to be resolved, and realistically we focus a lot more on 2D acceleration than video.

                    This is exactly why UVD hardware was created. It is dedicated hardware that is consistent across all market segments and is built to do only video decode.
                    This why there are discussion (i think i heard things ) about adding special infrastructure in pipe to be able to take advantage of such hw instead of trying to do it in shader. I am convinced that for decode gpu is not the best solution, dedicated hw is. Shader will be the default safe path, i think...

                    Comment


                    • #80
                      Originally posted by glisse View Post
                      This why there are discussion (i think i heard things ) about adding special infrastructure in pipe to be able to take advantage of such hw instead of trying to do it in shader. I am convinced that for decode gpu is not the best solution, dedicated hw is. Shader will be the default safe path, i think...
                      But what good does that do when the HW makers' contract terms with the "content protection" cartels and with Microsoft apparently explicitly forbid them from enabling their video-dedicated hardware to be used with free software?

                      (And has anyone discussed the antitrust implications of Microsoft and the HW makers signing secret agreements that say certain HW functionality shall be off-limits to Microsoft's chief competitors?)

                      Comment

                      Working...
                      X