Page 5 of 17 FirstFirst ... 3456715 ... LastLast
Results 41 to 50 of 164

Thread: Benchmarks Of AMD's Newest Gallium3D Driver

  1. #41
    Join Date
    Apr 2010
    Posts
    1,946

    Default

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

  2. #42
    Join Date
    Apr 2010
    Posts
    1,946

    Default

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

  3. #43
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    933

    Default

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

  4. #44
    Join Date
    Jul 2008
    Posts
    565

    Default

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

  5. #45
    Join Date
    Jul 2008
    Posts
    565

    Default

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

  6. #46
    Join Date
    May 2008
    Posts
    99

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

  7. #47
    Join Date
    Jun 2009
    Posts
    2,929

    Default

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

  8. #48
    Join Date
    Dec 2009
    Posts
    338

    Default

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

  9. #49
    Join Date
    Dec 2009
    Posts
    338

    Default

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

  10. #50
    Join Date
    Dec 2008
    Posts
    988

    Default

    Quote 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

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •