It's unclear to me how using one buffer instead of three can decrease performance.

(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!

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.

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

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

(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.  ;)

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.

Closing reopen if it's still an issue with newer r600g