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

[Jerome Glisse]

On Fri, Nov 12, 2010 at 7:18 PM, Zack Rusin <zackr at vmware.com> 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.
>
> 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 :)
>

The GLES2 state tracker idea is more like trying to shoot an idea in
the open to get someone interested in it as a pet project. I wouldn't
build future of GL stack in hope that we can write from scratch better
code.

I guess length of the mail kind of dilute the result of my analysis
let me sum it up here (also see my reply to Marek):
          - mesa/gallium is capable of good vertex throughput
          - dri2 swapbuffer/copybuffer is not slowing us down too much
          - r600g pipe driver has several bottleneck of which the
buffer management overhead is the highest
          - GL state change trigger way too much pipe driver activity
which lead to a collapse in drawoverhead program and also i believe
explain the performance we are seing in games (like nexuiz, openarena,
...)

Again if you look at the result you will that nouveau gallium is more
efficient than r300g or r600g (higher number of drawcall/sec) but it
collapse too in front of state change which is i believe stressing the
fact that in front of state change GL state tracker is calling the
whole pipe driver entry point while fewer should have be call (and
thus less pipe driver activity).

What i am most interested in is any one ever spend time on state
change optimizations inside mesa or gallium. This isn't small task at
all as it affects many pieces. But i believe any call useless call
avoided to pipe driver would increase performance accross all GL app
and accross all gallium driver. That was my whole point.

Cheers,
Jerome Glisse