On Fri, Nov 12, 2010 at 7:18 PM, Zack Rusin <za...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev