Benchmarks Of AMD's Newest Gallium3D Driver

[crazycheese]

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.

[crazycheese]

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

[darkbasic]

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.

[Yfrwlf]

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.

[Yfrwlf]

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.

[mirza]

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.

[pingufunkybeat]

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

[HokTar]

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?

[HokTar]

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.

[monraaf]

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