[Mesa-dev] r600g/mesa/gallium performance, whois to blame ?

[david may]

Hello Zack,

Saturday, November 13, 2010, 12:18:30 AM, you wrote:

> On Friday 12 November 2010 14:55:08 Jerome Glisse wrote:

> Hi Jerome,

> It's a bit tough to answer your email because it's composed of several quite
> distinct parts (benchmarking, gallium, new state trackers, ttm...). If
> anything it'd be good to seperate those into seperate threads.

>> Drawoverhead outcome is i believe that gallium is severly
>> under-performing in front of states changes. If i had to guess i would
>> say that an improvement of factor n in this would gives an improvement
>> of ~n for the overall (at least for r600g and likely for r300g too).
>> Does any one works on this ? Or knows what could be done to improve
>> this ? I didn't spot any obvious mistake in mesa state tracker. Of
>> course one could argue that it's the pipe driver which is slow but i
>> don't it's the only one to blame. Classic driver doesn't fallover in
>> drawoverhead test, thought classic driver are lot less performant on
>> this benchmark so maybe bottleneck in classic is also somewhere in
>> state world.
>> 
>> To me gallium need to be improved to be more efficient at changing
>> only the smallest number of states and try avoid call into the pipe
>> driver. I am not saying there is nothings to be done in the pipe
>> driver but there is a limit on what we can do there and gpu driver is
>> all about avoiding doing things :o)

> To be honest I'm not exactly sure what are you suggesting. Is someone working
> on what? Do you want to improve hashing of the states? Improve the hash table
> we use to cache them? Improve the state tracker?

> I guess when you say EGL2 you mean GL ES2, and when you say GL2 you mean GL4.1
> because 4.1 is the one that is a real superset of GL ES2. Even then though I
> don't quite understand what makes you think that a new state tracker would
> improve anything.

> I'm very skeptical of making the connection between "i don't really know
> what's going on, in fact it might be the driver" and "so lets rewrite all the
> code". Not to say that writing an OpenGL 4.1 state tracker from scratch is a
> bad idea. We could then just drop old mesa model and use gallium helper libs
> all over the code which would definitely make it cleaner but I don't think we
> should be naive enough to assume that it will result in a hugely better
> performance.

> I guess it boils down to what makes you think that even though you can't even
> identify the bottlenecks in the current code rewriting it would result in
> something better :) 

> z
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


-- 
Best regards,
 david                            mailto:david.may10 at ntlworld.com

as an bystander, i dont think this whois to blame  thread is about fixing issues
or even pointing fingers at who in this thread as such zack,but sure
the thread name might have been picked better LOL,
so keeping general thought/replies here is fine IMO.

 its seem's more a general observation post to highlight performance
 problems, and to initiate and Focus People's thoughts on more optimization
 and re-factoring for future patches, rather than here's some code,it work's good
 enough, move on, etc.