Announcement

Collapse
No announcement yet.

Three Priorities For Open-Source Radeon Graphics

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

  • Three Priorities For Open-Source Radeon Graphics

    Phoronix: Three Priorities For Open-Source Radeon Graphics

    While we still haven't been able to deliver any Radeon HD 7000 series Linux benchmarks, we do know what are AMD's three priority projects right now for their open-source Radeon Linux driver stack...

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

  • #2
    how about VDPAU? why focus on UVD?

    Comment


    • #3
      UVD is an engine on the graphics card while VDPAU is an API to let programs use it. These are two very different things which shouldn't be confused. You need the card's UVD to be supported before VDPAU will ever work as good as in nVidia's implementation.

      Comment


      • #4
        i thought that VDPAU uses the 3D engine, while UVD was a engine itself...
        but if you say that it wont work without UVD...
        i really thought that VDPAU can be used on r300g driven cards..

        Comment


        • #5
          Originally posted by jakubo View Post
          i thought that VDPAU uses the 3D engine, while UVD was a engine itself...
          but if you say that it wont work without UVD...
          i really thought that VDPAU can be used on r300g driven cards..
          Oh no, as I understand all this theoretically you could implement (expose)vdpau using the 3d engine of the radeon cards. If they are going to do that and if it would be worthwile is something I don't know.

          Comment


          • #6
            Originally posted by jakubo View Post
            i thought that VDPAU uses the 3D engine, while UVD was a engine itself...
            but if you say that it wont work without UVD...
            i really thought that VDPAU can be used on r300g driven cards..
            VDPAU: "Video Decode and Presentation API for Unix". This is nothing more or less than NVIDIA'S (i.e. evil/hostile) SOFTWARE INTERFACE to their hardware video decoder, which they call "PureVideo".

            NVIDIA calls their implementation by the name "PureVideo".
            AMD calls their implementation by the name "Unified Video Decoder" (aka "UVD").

            I.e., UVD ~= PureVideo
            (~= means "approximately equivalent")

            Comment


            • #7
              I only care about Video Acceleration. While it works flawlessly under Windows, up to the point where one can easily watch hardware-accelerated YouTube HD videos on even the weakest AMD APU, it is still a huge pain under Linux. There are VDPAU, VA-API and whatnot, every single player has to be patched to use them, every driver exposes a different API, and the open-source drivers don't expose any or offer just half the codecs or it doesn't work. Just today I installed a GT 210 in an HTPC running Ubuntu. I had to manually install VDPAU, libva and smplayer to get acceleration working. All other combinations and players (vlc, xine etc.) didn't work. Great. Sometimes i just wish we had a port of DirectShow.

              Comment


              • #8
                Let's try to clear the confusion here!

                UVD is indeed the equivalent of PureVideo. There purpose is just to decode video, hence they are special function hardware and extremely efficient.

                VDPAU and XvBA are APIs which are mainly meant to take advantage of the above decoders.
                This means that they can be implemented even on CPUs but most probably it would not be efficient at all.
                The consequence is that either of them could be implemented in a Gallium3D state tracker and any gallium drivers, including r300g, could make use of them.
                So yes, the idea is that the VDPAU state tracker tries to create an implementation of said API over gallium. It currently supports r300g, r600g and nouveau.

                Now it should be obvious that UVD is not needed for VDPAU on any hardware.
                The shortcoming of the Gallium3D state tracker is that it uses the shaders, hence it cannot be as efficient as the UVD would be. This is the main reason why guys at AMD are still battling to provide some sort of support despite the serious legal challenges.

                Hope it clarifies a few bits. If I made mistakes hopefully bridgman & co. will fix me.

                Comment


                • #9
                  I wish they'd make power management a bigger priority. Thats the reason I got a new laptop with intel graphics to replace my old laptop that had an hd2600 mobility. Using the OSS drivers on that thing raped my battery life and caused very high temps compared to catalyst, even when I set it to low profile. And on low profile performance wasn't very good for compositing. Dynpm hardly even worked, screen flickered every time it switched clocks. Power management is a total mess right now for those drivers.

                  This new laptop has less powerful integrated intel graphics, but compositing seems smoother, and I get good temps and battery life. Both catalyst and the oss drivers were too problematic for me in linux to keep using ATI. Catalyst has gotten better, and did give me decent temps, but the fact that it is so broken with gnome-shell was a deal breaker for me.
                  Last edited by bwat47; 01-12-2012, 11:30 AM.

                  Comment


                  • #10
                    +1

                    I wish powermanagement were better.

                    Comment


                    • #11
                      I'm wondering if there is still hope left to ever get accelerated video decoding on a AVIVO (RV530) X1600 card?

                      Bridgman?

                      Anyone?

                      Thanks

                      Comment


                      • #12
                        Originally posted by tball View Post
                        +1

                        I wish powermanagement were better.
                        +2
                        IMO the biggest hurdle for a wider adoption, especially on laptops.
                        Feature-wise, the drivers are usable as they are, nevermind the performance delta with fglrx in 3D applications, that can come later.
                        You'd expect people who are serious about 3D performance to be able to install a driver. Otherwise, in my opinion: GTFO.

                        P.S.: I've just read about LG having signed a deal with MS for the "privilege" of using Android, so I'm in a bad mood.

                        Comment


                        • #13
                          There is always hope, but...

                          Originally posted by hobbes View Post
                          I'm wondering if there is still hope left to ever get accelerated video decoding on a AVIVO (RV530) X1600 card?
                          The current shader-based video acceleration is targeted for R600+ GPUs. To quote Christian König:

                          For the whole R3xx - R5xx series we had only very limited success, and that only with some of the later R5xx chipsets.
                          I'm guessing that means X1950 cards. Apparently, it is (theoretically) possible to get the shaders working on other R300-R500 GPUs, except that no-one has any time to do the work.

                          Comment


                          • #14
                            Originally posted by hobbes View Post
                            I'm wondering if there is still hope left to ever get accelerated video decoding on a AVIVO (RV530) X1600 card?
                            r5xx and previous asics used the 3D engine for video decode, so in theory, one could fix any remaining issues with gallium pipe video on r300g and use it on older asics. It's just a matter of time and resources.

                            Comment


                            • #15
                              Power consumption is the main driver for me. Will ZCP be in the SI ddx initially?

                              Comment

                              Working...
                              X