Originally posted by crazycheese
View Post
Announcement
Collapse
No announcement yet.
Benchmarks Of AMD's Newest Gallium3D Driver
Collapse
X
-
-
Originally posted by bridgman View PostBTW 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.
Comment
-
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
-
Originally posted by crazycheese View PostMaybe 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.
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
-
Originally posted by pingufunkybeat View PostYou guys really should read the thread on Mesa-dev that jglisse started. It's good
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
-
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
Anyway your probably hitting this bug.
Comment
-
Originally posted by Jerome GlisseIn 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).
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.
which points to a Linux patch,
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
-
Originally posted by nikai View PostAccordingly 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
Gah.
Comment
Comment