[Bug 34493] New: r600g performance regression introduced by 467023e8 (Marek Olšák: r600g: use the same upload buffer for vertices, indices, and constants)
https://bugs.freedesktop.org/show_bug.cgi?id=34493
Summary: r600g performance regression introduced by 467023e8 (Marek Olšák: r600g: use the same upload buffer for vertices, indices, and constants) Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: dawitbro@sbcglobal.net
As detailed in Comment 6 of bug 34156, I found this regression in Mesa 7.11-git while trying to pin down another performance regression a few commits earlier.
I was able to create a local branch where I was able to reverts 4 commits from a series by Henri Verbeet, which restored performance to the level which existed before that series was introduced. Performance remained high after the 4 reverts until commit 467023e8 was introduced.
Reverting this commit (in addition to the 4 mentioned in the other bug report: 077c448d, 7687eaba, 1fa95c7f, and a77e813d) restores performance. All further Mesa commits through the next 10 days (up to the HEAD I have currently, which is fd8d4b32 of Feb. 18) are working fine.
I am using r600g on 64-bit Linux, with the following hardware + software:
Hardware: Radeon HD 5750 (Evergreen JUNIPER)
Software: kernel 2.6.37 (+ radeon cherry-picks from drm-fixes) libdrm 2.4.23 xorg-server 1.9.4 xf86-video-ati 6.14.0
If I can provide any further info/assistance, just let me know.
https://bugs.freedesktop.org/show_bug.cgi?id=34493
--- Comment #1 from Marek Olšák maraeo@gmail.com 2011-03-01 14:09:55 PST --- It's unclear to me how using one buffer instead of three can decrease performance.
https://bugs.freedesktop.org/show_bug.cgi?id=34493
--- Comment #2 from Dave Witbrodt dawitbro@sbcglobal.net 2011-03-01 15:12:14 PST --- (In reply to comment #1)
It's unclear to me how using one buffer instead of three can decrease performance.
I am not a developer, so I cannot comment on the code. Indeed, regarding the other bug report I mentioned (#34156) I was asked by Henri (private msg) to do some profiling tests: I know what that means, but I do not (yet) have any experience with it, and have not found time to experiment with it in the past 2 weeks. I just barely know enough 'git' usage to create a local branch with the (five) problem commits reverted.
I wonder if anyone else can confirm the regression(s) I am reporting. I'm using Mesa r600g on Radeon HD 5750. Running performance tests at 3b1c1f02 (the commit before performance dropped for me) followed by 467023e8 (the subject of the current bug report) should reveal a big difference.
If not, then it's just me... and the bug could be rejected as invalid. It could be hardware-specific, it could be PEBKAC (if I did something wrong creating the local branch with the 5 commits removed), etc.
I was planning on testing the Mesa HEAD this weekend, including updating my local branch to see if any new commits are affecting performance. Maybe these code changes are features, not bugs -- providing other benefits more important than the performance effects. I was just so happy to see the major increase in performance in January that I hate the idea of losing it in the more recent work!
https://bugs.freedesktop.org/show_bug.cgi?id=34493
--- Comment #3 from Marek Olšák maraeo@gmail.com 2011-03-01 15:45:37 PST --- There will be more performance improvements soon. I know how to improve it by 50% or more, it's just not very high on my priority list currently.
https://bugs.freedesktop.org/show_bug.cgi?id=34493
--- Comment #4 from Dave Witbrodt dawitbro@sbcglobal.net 2011-03-01 17:01:14 PST --- (In reply to comment #3)
There will be more performance improvements soon. I know how to improve it by 50% or more, it's just not very high on my priority list currently.
Oh! Well, thank you for that (in advance)!
My purpose in testing for regressions was to find a way to contribute back to the community. Since I am not (yet) able to write code, or properly debug code, I thought I could at least report changes in performance and/or behavior in the build systems. I'm getting the vibe that reporting performance regressions is not deemed a meaningful way to contribute. Is that correct?
https://bugs.freedesktop.org/show_bug.cgi?id=34493
--- Comment #5 from Marek Olšák maraeo@gmail.com 2011-03-01 17:19:14 PST --- (In reply to comment #4)
(In reply to comment #3)
There will be more performance improvements soon. I know how to improve it by 50% or more, it's just not very high on my priority list currently.
Oh! Well, thank you for that (in advance)!
My purpose in testing for regressions was to find a way to contribute back to the community. Since I am not (yet) able to write code, or properly debug code, I thought I could at least report changes in performance and/or behavior in the build systems. I'm getting the vibe that reporting performance regressions is not deemed a meaningful way to contribute. Is that correct?
It's very useful to report performance regressions. Just in this case, it's not obvious to me what's wrong with the commit. There are not many developers, so it might be hard to get attention quickly especially if it's not a show-stopper, but developers usually read bug reports and, thanks to that, are aware of existing issues.
https://bugs.freedesktop.org/show_bug.cgi?id=34493
--- Comment #6 from Dave Witbrodt dawitbro@sbcglobal.net 2011-03-01 20:01:16 PST --- (In reply to comment #5)
It's very useful to report performance regressions. Just in this case, it's not obvious to me what's wrong with the commit. There are not many developers, so it might be hard to get attention quickly especially if it's not a show-stopper, but developers usually read bug reports and, thanks to that, are aware of existing issues.
OK, thanks for the clarification.
I will continue my local testing of Mesa master and my own branch with any problem commits I find reverted -- as long as I am able, I mean.
In the coming weeks I should finally be finding time to begin learning the code. Maybe this sort of testing -- profiling, identifying code changes that affect performance, and explaining the reason for those effects -- will be my way of learning the code base.
FTR, by pointing out performance problems I find, I am not seeking immediate fixes or attention for those particular problems. I am merely hoping to provide info to developers, in case the info is important. Mesa actually works fine for me from master... just 1/3 slower. ;)
https://bugs.freedesktop.org/show_bug.cgi?id=34493
--- Comment #7 from Dave Witbrodt dawitbro@sbcglobal.net 2011-04-11 20:15:46 PDT --- I have been away from Linux and testing radeon support since the Japan crisis began. Updating to Mesa 7.11.0-devel, commit a26121f3, caused the same slowdown I had observed before: min/max framerate in 'torcs' dropped from 28/54 fps to 17/34 fps. I was planning on restoring local packages of my last fast-working Mesa, but decided to rebuild my entire X stack against my newly updated kernel (updated from 2.6.38-rc8 to 2.6.38.2).
To my shock, I found that replacing xorg-server 1.9.99.903 with 1.10.0.902 and updating the radeon driver to the latest git version, 6.14.99-devel, commit cc7d1fa3 -- both built against the Mesa mentioned above -- improved Mesa performance in 'torcs' dramatically. It is no longer as consistently high as I was getting, but gives me 17/54 fps.
I also notice that another test program, 'prboom-plus', has dramatically improved performance all around. As a result, I am abandoning my local git branch where I intended to pin down the exact cause of the performance changes -- I haven't touch it for 7 weeks anyway -- and start following the Mesa HEAD again.
Sorry for the false alarm. It appears that Mesa changes alone were not to blame for whatever performance problems I was experiencing.
https://bugs.freedesktop.org/show_bug.cgi?id=34493
Jerome Glisse glisse@freedesktop.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #8 from Jerome Glisse glisse@freedesktop.org 2012-02-22 10:08:11 PST --- Closing reopen if it's still an issue with newer r600g
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org