Announcement

Collapse
No announcement yet.

Where The Open-Source AMD Driver Is At For Modern GPUs

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

  • Where The Open-Source AMD Driver Is At For Modern GPUs

    Phoronix: Where The Open-Source AMD Driver Is At For Modern GPUs

    Earlier this week Sapphire launched the Radeon HD 5830 Extreme using the well-supported "Cypress LE" graphics processor at a very competitive price relative to the NVIDIA competition and the Radeon HD 5830 graphics cards from other AMD partners. With it being part of the HD 5000 series and not one of the newer HD 6000 series graphics processors, the Linux support is already spot-on for both the official Catalyst Linux driver and within the open-source stack. In this article are the open-source Gallium3D benchmarks for the Radeon HD 5830 along with other recent ATI/AMD GPUs to show where the latest Mesa/Gallium3D code is at today.

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

  • #2
    While the open-source ATI/AMD Linux driver stack is beginning to catch up with the proprietary Catalyst driver on older generations of Radeon hardware as earlier tests have shown, for modern GPUs it will still be a while before anything close to parity is hit.
    The problem is that it will be like that forever. AMD/NVIDIA deploy over five hundred programmers to create fast/optimized/bug free drivers for their GPUs, while at most there is just a handful of programmers (I'd say 10 tops) working on open source drivers.

    Comment


    • #3
      Originally posted by birdie View Post
      The problem is that it will be like that forever. AMD/NVIDIA deploy over five hundred programmers to create fast/optimized/bug free drivers for their GPUs, while at most there is just a handful of programmers (I'd say 10 tops) working on open source drivers.
      Not to mention the five hundred can write the driver the way they see fit, while the rest have to chase moving targets (KMS, DRI, etc).

      Comment


      • #4
        R300g and intel (sandy bridge) has more or less succeeded in making an optimized driver, without hundred of developers.

        In my opinion there is something weird with r600g, something at mesa or gallium that is really hurting r600-r700-r800 GPUs performance, something that developers don't find. Implementing new features like hiperz, opengl 3-4 will not solve this problem, it seems some type of "architectural" problem.

        Comment


        • #5
          Originally posted by birdie View Post
          The problem is that it will be like that forever. AMD/NVIDIA deploy over five hundred programmers to create fast/optimized/bug free drivers for their GPUs, while at most there is just a handful of programmers (I'd say 10 tops) working on open source drivers.
          300 Spartans can hurt 800 000 very much... http://en.wikipedia.org/wiki/Battle_of_Thermopylae

          why should the 130 radeon devs lose? Linus Torvalds Starts the Kernel alone.

          Comment


          • #6



            Ouch!

            too bad Catalyst fails horribly in other departments, e.g., it cannot even run gnome-shell without corruption.

            Comment


            • #7
              Originally posted by bug77 View Post
              Not to mention the five hundred can write the driver the way they see fit, while the rest have to chase moving targets (KMS, DRI, etc).
              That's one point. Underlying specifications constantly change, lot's of efforts become useless.

              Comment


              • #8
                Three things:

                a) my fglrx script can run 11-3 with .39 git kernel

                no differnet kernel needed to install.

                b) no libtxc_dxtn lib was installed

                i am not fully sure how much speed that gives, but at least it does not hurt

                c) swapbufferswait was not disabled

                this gives the biggest boost in benchmarks. The refreshrate for 1280x1024 was most likely 85 hz while benchmarking as warsow is usually a fast game and 80 is just below 85. my guess is you will easyly hit >100 fps when you disable it. when you would add openarena as benchmark you will see the impact of swapbufferswait even much more extreme.

                please take a look at my scripts in

                http://kanotix.com/files/fix/oss-test/

                and check the readme, basically the scripts are only tested with debian (squeeze), but should work with sid too - i dont think you care about the libgl switching capability of ubuntu lucid+ when you compile mesa, or do you? mesa script with any option: gallium mode, otherwise normal. intel script with any option: no vsync/swapbufferswait, ati script with any option: no swapbufferswait by default. Please retest with at least swapbuffers wait disabled.

                Comment


                • #9
                  Originally posted by Qaridarium View Post
                  300 Spartans can hurt 800 000 very much... http://en.wikipedia.org/wiki/Battle_of_Thermopylae
                  And in the end they lost and were wiped out (even with the help of 5000-7000 supporting forces).

                  Comment


                  • #10
                    For some use cases it seem that oss drivers are not that bad. When you only play browser games up to quake live you can be happy already - depends a bit on the card however. When you own an older ati card or intel you don't have got a big choice, there you have to use it. I would like to see a real fast r500 card in the benchmark with optimized settings. Maybe even using RADEON_HYPERZ=1 override for pts.

                    Comment


                    • #11
                      Originally posted by birdie View Post
                      The problem is that it will be like that forever. AMD/NVIDIA deploy over five hundred programmers to create fast/optimized/bug free drivers for their GPUs, while at most there is just a handful of programmers (I'd say 10 tops) working on open source drivers.
                      We don't need to "defeat" the blobs, since they have a number of inherent faults that make them undesirable and which can not be fixed.

                      What we need is to bring performance to the point where it does not matter any more, so all the inherent advantages of OSS drivers: KMS, out-of-the-box support, integration, support for X technologies, lack of spyware and malware, longer support, etc. take over.

                      With r300g, we're already there. With r600g, it will take a while longer, but we'll get to 65-75% of the performance, and that's fast enough for most people. There are always people who will fuck around with blobs, dicking them into a kernel that was not designed for them, to obtain 30% more FPS, but I imagine that for most users, this perversion will become unnecessary, just like nobody is installing nforce ethernet binary driver nowadays.

                      It's like GCC vs. ICC. ICC is much faster, but everyone uses GCC anyway, because speed is not everything. We need to cover the needs of the computer users, free software itself is THE killer argument.

                      Comment


                      • #12
                        Originally posted by Kano View Post
                        For some use cases it seem that oss drivers are not that bad. When you only play browser games up to quake live you can be happy already - depends a bit on the card however.
                        Yup, I would definitely buy a HD5830 to play Quake Live. No wait, Quake 3 was working fine on GeForce2... Well, after thinking about it, I think I'll stick to Catalysts.

                        Comment


                        • #13
                          Originally posted by yaji View Post
                          Yup, I would definitely buy a HD5830 to play Quake Live. No wait, Quake 3 was working fine on GeForce2... Well, after thinking about it, I think I'll stick to Catalysts.
                          You don't need an HD5830 to play QuakeLive, the cheapest card on the market will work just fine. Fanless, even:

                          http://www.google.com/products/catal...wBQ#ps-sellers

                          Comment


                          • #14
                            Originally posted by pingufunkybeat View Post
                            It's like GCC vs. ICC. ICC is much faster, but everyone uses GCC anyway, because speed is not everything. We need to cover the needs of the computer users, free software itself is THE killer argument.
                            The difference being is that the gap in performance for a vast majority of compiled items is usually about 5-10% if there is a difference at all when it comes to icc vs gcc. Gcc can also be faster on some items again not by much. Also the resulting binary winds up with the same features no matter what compiles it. Comparing compilers to drivers isn't a good comparison.

                            Comment


                            • #15
                              Originally posted by deanjo View Post
                              The difference being is that the gap in performance for a vast majority of compiled items is usually about 5-10% if there is a difference at all when it comes to icc vs gcc. Gcc can also be faster on some items again not by much. Also the resulting binary winds up with the same features no matter what compiles it. Comparing compilers to drivers isn't a good comparison.
                              Well, if the performance difference is 20% (if there is one at all), like is the case with r300g, then it is indeed a good comparison.

                              Sure, the r600+ drivers have some catching up to do, but they did start far too late, and they did catch up a lot already. If the drivers reach the 75% mark (as they are expected to and like r300g did), then it will indeed be a good comparison.

                              I also don't see why comparing compilers to drivers is not a good comparison, when a large part of what a modern GPU driver does is actually compiling. In fact, they translate OpenGL code and shaders into a form that the GPU (a processor) can execute.

                              Comment

                              Working...
                              X