[Mesa-dev] [PATCH] vbo: signal _NEW_ARRAY when transitioning between glBegin/End, glDrawArrays

[Brian Paul]

2011/12/21 Mathias Fröhlich <Mathias.Froehlich at gmx.net>:
>
> Hi,
>
> On Wednesday, December 21, 2011 01:58:08 Brian Paul wrote:
>> This fixes a regression seen with the isosurf demo when switching between
>> glBegin/End and glDrawArrays (do it several times).  The problem was the
>> driver wasn't getting _NEW_ARRAY when the arrays were subtly changed:
>> (vertex3f, normal3f) vs. (normal3f, vertex3f).
>>
>> This patch fixes that by signaling _NEW_ARRAY whenever we transition
>> between glBegin/End and glDrawArrays mode.
>
> The basic idea should probably work, still preserving the optimization.
> But I have two issues/thoughts on that:
>
> I also think that draw elements and draw arrays should not make a difference.
> The array state should be already set dirty by the gl api functions on exactly
> these occations where they change the array state.
> So, there should be no need to set the array state dirty when switching
> between draw arrays and draw elements.
>
> Additionaly, I think that the dlist draw path in vbo_save_draw.c needs the
> same treatment like the the immediate mode draw path in vbo_exec_draw.c.

I'm not sure if "playback_vertex_list" is more like DRAW_BEGIN_END or
DRAW_ARRAYS.
Maybe add a DRAW_DISPLAY_LIST enum value?


>> The patch also fixes up the initialization of the map_vp_none[] array
>> to stop putting strange values in the last five elements of the array.
> That change should render correct.
>
> Even if this could still insert the higher numbered generic arrays into the
> fixed function enabled arrays where they should not be there. This is just
> about the same as any previous sloution did, just with different arrays that
> bleed into the generic arrays beyond the last material.

I think the code is a bit more understandable now.

-Brian