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

[Zack Rusin]

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