Announcement

Collapse
No announcement yet.

Benchmarks Of AMD's Newest Gallium3D Driver

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

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


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


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


        • #44
          You guys really should read the thread on Mesa-dev that jglisse started. It's good

          Comment


          • #45
            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.
            Anytime they need such help most people are ready to do what they can.

            Maybe it would be nice to set up a bunch of tests which can be run automatically and checks for regressions & co. Sounds familiar?
            I think something like piglit so all the features would get tested on all hardware.
            One thing to keep in mind is that it must be _easy_ to use, i.e. Ubuntu repo, rpms, etc. And also user-friendly so only a few clicks!

            Best would be an online database where your results could be uploaded and it would show which tests pass on which hardware after which commit. I would definitely not mind running a few minutes of tests after every xorg-edgers update.

            So, if this would be of any help to devs and it is possible to do then I'm totally in! If this is already possible please point me to the right direction. PTS does not really count in this sense, because I think reports like " I see artefacts in game xx which were not present 3 weeks ago" are not too helpful, but submitting to an online database that piglit test xy stopped working because of a commit between day vv and ww of this month might be of use.

            Any thoughts regarding this?

            Comment


            • #46
              Originally posted by pingufunkybeat View Post
              You guys really should read the thread on Mesa-dev that jglisse started. It's good
              I told you!

              Anyway, for the lazies here it is again. Although, another thread was started by Jerome on this matter, but this one might be even more technical.

              One almost immediate speed-up is likely to come soon according to this thread. I have no idea how much the speed should increase, maybe it won't even be measurable. You've been warned.

              Comment


              • #47
                Originally posted by phoronix

                Nexuiz (...) The Gallium3D driver on ATI Radeon HD 5000 series was not even working for us with this open-source game.

                VDrift (...) With the Gallium3D driver on the Radeon HD 5000 series, like Nexuiz, resulted in the game not getting beyond the loading screen.

                World of Padman (...) The Gallium3D driver on the ATI Radeon HD 5770 graphics card would lock-up when running World of Padman
                There have been some nasty regressions lately on the r600g Evergreen front that causes GPU lockup . It would be nice if people would test their code on Evergreen before they commit and don't assume that it's the same as r700.

                Anyway your probably hitting this bug.

                https://bugs.freedesktop.org/show_bug.cgi?id=31530

                Comment


                • #48
                  Looking fglrx performance, make me sad. I wonder when we have a PROPER Open Source driver for ati/amd hw. Could we have it on our life times?

                  Comment


                  • #49
                    Originally posted by HokTar View Post
                    I told you!

                    Anyway, for the lazies here it is again.
                    Originally posted by Jerome Glisse
                    In that path it's the pb_bufmgr_cache mecanism
                    that are too blame, we are loosing lot of time in gettimeofday. We are
                    also loosing lot of time in pb_bufmgr_cache bo allocation path (again
                    for gettimeofday).
                    I had a quick look at the usage of gettimeofday in mesa, and apparently
                    it never is used for accessing the wall time, but instead for timeouts
                    like in the pb_bufmgr_cache, or for benchmarks elsewhere.

                    So my thought was that it might make sense to replace it, if available,
                    with POSIX clock_gettime and a cheaper monotonic clock with an
                    unspecified starting point.

                    Also according to the manpage of gettimeofday,
                    POSIX.1-2008 marks gettimeofday() as obsolete, recommending the use of
                    clock_gettime(2) instead.
                    Googling a bit I found an interesting patch on the Xorg-devel mailing list,
                    http://lists.x.org/pipermail/xorg-de...st/012483.html
                    which points to a Linux patch,
                    http://marc.info/?l=linux-kernel&m=125073483507611&w=2

                    Accordingly I replaced gettimeofday in mesas's os_time_get(), src/gallium/auxiliary/os/os_time.c
                    with clock_gettime and CLOCK_REALTIME_COARSE.

                    It's working nicely, but the problem is that I don't see a significant difference

                    Comment


                    • #50
                      Originally posted by nikai View Post
                      Accordingly I replaced gettimeofday in mesas's os_time_get(), src/gallium/auxiliary/os/os_time.c
                      with clock_gettime and CLOCK_REALTIME_COARSE.

                      It's working nicely, but the problem is that I don't see a significant difference
                      Actually it was lock_gettime and CLOCK_MONOTONIC_COARSE.
                      Gah.

                      Comment

                      Working...
                      X