No subject


Mon Dec 19 16:14:14 PST 2011


it's fixable. Then I came up with a set of patches which did not
address the issue completely, but some cases (like with Torcs) were
optimized (well maybe not cleanly as it caused a few regressions too).
There still is a lot of cases where the vertex array state is
recomputed needlessly, so it still is an open issue. I did not fully
understand how the entire vbo module works and why so much state
validation was being done there. Even today, drivers have almost no
way to know in draw_prims whether the vertex array state is _really_
changed, because core Mesa almost always says "yes, it changed of
course! why wouldn't it?" Sadly, performance is usually being put
aside and energy is put into more important stuff like new features. I
was profiling Mesa quite extensively because there was simply nothing
better to do for r300g. I don't expect that's the case with the other
drivers.

Back on topic. The reason why you don't see a performance regression may be=
:
1) The vertex array state management is not the bottleneck.
2) You already hit the slowest path, that is recomputing the state
completely in every draw call.

Marek


More information about the mesa-dev mailing list