[Mesa-dev] vertex array regression
Marek Olšák
maraeo at gmail.com
Mon Dec 19 16:40:46 PST 2011
2011/12/19 Mathias Fröhlich <Mathias.Froehlich at 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(...);
More information about the mesa-dev
mailing list