2011/12/19 Mathias Fröhlich <mathias.froehl...@gmx.net>: > > Brian, > > On Monday, December 19, 2011 17:01:07 you wrote: >> I still don't get what the purpose of the special mapping of the last >> four/five elements is all about. Can you explain that? > > As far as I can see the last ones should not map to anything. > The map is used only in fixed function mode. And there these arrays should not > show up as inputs to any fixed function shader. I think that the purpose of > the > previous mapping was just to fill in anything. The changes I did serve exactly > this purpose. > > But I agree that here should not be any mapping of these attributes in this > mode. Attached is a small change that is probably a more clean solution to > this mapping problem. > > The change passes a quick r600g piglit test. > >> Yeah, I see how the incorrect varying_inputs values was causing >> _NEW_ARRAY to get set, thus hiding the problem. The solution looks >> correct, but I'm a little worried about performance, as is mentioned >> in the comment. >> >> Marek, made that change back in March. Maybe he can take a look at >> this too. > I cannot comment on this, since I do not see a performance regression on my > use cases. > Marek?
The problem back in March and earlier was that the vertex array state was completely recomputed for each draw call even if the user did not change any state at all! There was the validation in the vbo module and then in st/mesa, which were basically needless. It turned out to be the major bottleneck in the game Torcs (in the track called Forza). I checked the source code of Torcs and it confirmed my findings. There was a loop that looked like this: for (i = 0; i < very large number; i++) glDrawElements(...); From that point, it became clear that Mesa is underperforming and that 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
