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 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


            • #36
              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


              • #37
                ^^ 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


                • #38
                  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


                  • #39
                    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


                    • #40
                      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

                      Working...
                      X