Announcement

Collapse
No announcement yet.

Benchmarks Of AMD's Newest Gallium3D Driver

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

  • #31
    The rate of progress here given the available manpower is not bad at all. Still a long way to go (is there ever not a long way to go with open source graphics?) but the progress is nonetheless impressive.

    If I were able to contribute, my first priorities would be fixing the cases where r600g was not able to run the program, or would crash / lock up. Then I'd work on the incorrect rendering issues. Once most of that is handled, I'd look at setting a performance goal of ~50% of Catalyst across the board. If we can get correct rendering at half of Catalyst speeds in general, I'll abandon Catalyst for good.

    As it stands, Savage 2, Heroes of Newerth and Second Life are unplayable on evergreen with either r600c or r600g, and due to hard-locks are very difficult to debug. I've only been running the same three GL 2.1 apps for the past 2-3 years, but they still won't run on any open source driver.

    Comment


    • #32
      Stop calling it "AMD's" driver. 80+% of it was written by two guys who don't work for AMD. In another thread, I did the break down, and there were only 14 commits from AMD employees.

      Comment


      • #33
        I tried r600g on a hd3850 with Nexuiz. Can't say I was impressed. Some maps, which r600c runs just fine, were completely unplayable with r600g (too slow), with no obvious gain. Other maps run well with both most of the time, but r600g gives some performance drops from time to time. So for now I'm going to stick with r600c.

        Comment


        • #34
          IMO the gallium drivers could be better again if r600 classic was dropped. By now the places that the classic driver has the advantage are so marginal as to be anomalous....

          Comment


          • #35
            Originally posted by pingufunkybeat View Post
            Thanks for the benchmarks. We still have a long way to go, but looking at r300g, there is lots of "win" coming our way.

            Still, the numbers are a bit odd.

            I get stable 60fps at 1920x1080 in OpenaArena using r600g on a 4550 (!!!), which is at least 3-4 times slower than a 4870. It's impossible that you only get 87fps on a 4870.
            all bechmark results over 60fps vsinc are invalid

            the result 87fps just say somthing like: yes tearfree gaming on 60fps is valid on an 4870

            there are no need for driver optimations if the driver do have more than 60fps-

            or stereoscopic view 120fps.

            if you wana benchmark a hd4870 you need a benchmark with less than 30fps.

            Comment


            • #36
              Originally posted by mattst88 View Post
              Stop calling it "AMD's" driver. 80+% of it was written by two guys who don't work for AMD. In another thread, I did the break down, and there were only 14 commits from AMD employees.
              don't waste your time by making this clear

              its a driver for amd hardware means normal people think its amd's driver.

              the only point thats matters is: the radeon should be the best driver over the world

              Comment


              • #37
                Originally posted by bridgman View Post
                BTW one of the differences between the proprietary drivers and the open source drivers is that the proprietary drivers are multithreaded (using a worker thread to do most of the processing) while the open source drivers do driver processing inline with application calls.

                There are probably some simpler changes that can and should be made first, but as others have said finding the right spots to change is the hardest part of the job.

                The driver probably is starving the hardware at this point (which would minimize the difference between fast and slow GPUs), but even that has not yet been confirmed. What we have seen is that overall performance is more a function of CPU speed than GPU power right now.
                in that case one should simply test the catalyst driver with only one core enabled (and turned off HTT of course). and see how much Catalysts superior performance lies therein.
                right?

                Comment


                • #38
                  I getting >40-60 fps< average at 1920x1080@32, 32bit textures, using 2.6.36 amd64 kernel with R600g on HD4770, quadcore Athlon II x4 630, 6gb ddr3 1600.

                  4770 is similar to 4830 in performance.

                  The interesting thing is when a lot of players(or bots) are calculated (ie. clash in single room), fps goes massively down for very few secs. I.e. the performance is constant, not with any big variation and it is very sensitive to CPU load.

                  I'm more than sure something CPU dependent is blocking the performance.
                  Some code in gfx stack that uses CPU too much instead of using GPU; or something that binds GPU performance to CPU.

                  Hope it helps somebody.

                  Comment


                  • #39
                    ^^ Actually, this is pretty much what jglisse wrote about in that thread linked here (a really good read). The vertexrate is already pretty much equivalent to fglrx, but the driver chokes way too hard when it changes state. Finding the exact culprit is hard, and it looks like it will be a large number of small optimisations across the board rather than one huge bottleneck that can be fixed overnight.

                    I'm a total layman, but this could also be the reason why the driver doesn't scale well with improved woomph -- the graphics hardware is starved most of the time waiting for the driver.

                    Comment


                    • #40
                      Originally posted by bridgman View Post
                      BTW one of the differences between the proprietary drivers and the open source drivers is that the proprietary drivers are multithreaded (using a worker thread to do most of the processing) while the open source drivers do driver processing inline with application calls.

                      There are probably some simpler changes that can and should be made first, but as others have said finding the right spots to change is the hardest part of the job.

                      The driver probably is starving the hardware at this point (which would minimize the difference between fast and slow GPUs), but even that has not yet been confirmed. What we have seen is that overall performance is more a function of CPU speed than GPU power right now.
                      This maybe might go together with behavior I experience. Yet, I remember even single-cored Pentium III was able to draw over 300 fps with good gfx card in windows 98 era.

                      I think adding multithreading capability would be very good performance boost, but it I dont think it is the reason for current brakes.

                      I can turn off cores on my machine as well as force 800Hz (via powersave governor), so if I can help please drop me a PM with instructions and I will do what I can.

                      Comment


                      • #41
                        Originally posted by pingufunkybeat View Post
                        ^^ Actually, this is pretty much what jglisse wrote about in that thread linked here (a really good read). The vertexrate is already pretty much equivalent to fglrx, but the driver chokes way too hard when it changes state. Finding the exact culprit is hard, and it looks like it will be a large number of small optimisations across the board rather than one huge bottleneck that can be fixed overnight.

                        I'm a total layman, but this could also be the reason why the driver doesn't scale well with improved woomph -- the graphics hardware is starved most of the time waiting for the driver.
                        Maybe we should start a enrollment program to allocate all xf86-video-ati users and provide them easy steps to assist the development with benchmarking on their hardware! I think barely anyone would resist the chance to help improve the driver.

                        Comment


                        • #42
                          Originally posted by smitty3268 View Post
                          The r600g driver is mostly CPU limited right now, i think. Maybe your cpu is just faster?
                          An old Athlon64 3800+X2 2Ghz faster than a Core i5 750 quad-core at 2.67GHz?

                          If my HD3870 with a 6 years old cpu does 100fps @2560x1600, a modern quad core w/ a much more powerful GPU like the 4870 should do at least 500fps at a lower resolution like 1920x1080

                          This is really, really strange.
                          ## VGA ##
                          AMD: X1950XTX, HD3870, HD5870
                          Intel: GMA45, HD3000 (Core i5 2500K)

                          Comment


                          • #43
                            Originally posted by crazycheese View Post
                            Maybe we should start a enrollment program to allocate all xf86-video-ati users and provide them easy steps to assist the development with benchmarking on their hardware! I think barely anyone would resist the chance to help improve the driver.
                            I agree with this, I'd do it to help out. These differences between the closed and open driver are insane. Open source drivers should beat the proprietary ones provided there is enough coding power and documentation. The closed and Windows drivers should be left in the dust.

                            Comment


                            • #44
                              Originally posted by bridgman View Post
                              BTW one of the differences between the proprietary drivers and the open source drivers is that the proprietary drivers are multithreaded (using a worker thread to do most of the processing) while the open source drivers do driver processing inline with application calls.

                              There are probably some simpler changes that can and should be made first, but as others have said finding the right spots to change is the hardest part of the job.

                              The driver probably is starving the hardware at this point (which would minimize the difference between fast and slow GPUs), but even that has not yet been confirmed. What we have seen is that overall performance is more a function of CPU speed than GPU power right now.
                              I hope these changes will be made so that GPUs can be fully utilized instead of cycles being wasted. There's no reason open drivers can't be greener than closed provided documentation and coding power.

                              Comment


                              • #45
                                Solution

                                what I would do to find performance bottlenecks is quite simmilar to what Ubuntu did to improve startup performance:
                                1) Make optinal recording of high level communication CPU <-> GPU (like: "setting states", "moving this or that from RAM to GPU", ...).
                                2) Make simple OGL program that exposes difference in speed as much as possible.
                                3) Compare logs and see where open driver wastes time comparing closed source.

                                Comment

                                Working...
                                X