[Mesa-dev] [PATCH 4/6] i965: Clarify that we only check one prim's type for cut index support.

[Kenneth Graunke]

On 08/30/2013 12:26 PM, Paul Berry wrote:
> On 30 August 2013 10:36, Eric Anholt <eric at anholt.net
> <mailto:eric at anholt.net>> wrote:
>
>     Kenneth Graunke <kenneth at whitecape.org
>     <mailto:kenneth at whitecape.org>> writes:
>
>      > can_cut_index_handle_prims() was passed an array of _mesa_prim
>     objects
>      > and a count, and runs a loop for that many iterations.  However, it
>      > treats the array like a pointer, repeatedly checking the first
>     element.
>      >
>      > This is wasteful and bizarre.
>      >
>      > The VBO module will never call us with multiple primitives of
>     different
>      > topologies, so it's actually reasonable to just check the first
>     element.
>
>     I'm pretty sure it will.  I don't see anything in vbo_exec_Begin()
>     making sure the new primitive is the same type as the last.
>
>
> Yeah, I agree.  Although I wasn't able to construct a failing case using
> primitive restart, I did verify by experiment that this sequence of

I'm not sure if you can.  I read through Jordan's code (which handles 
DrawElements), as well as Brian's code (which handles DrawArrays), and 
they just split one primitive into two of the same type...

> calls causes the VBO module to call us with multiple primitives of
> different types:
>
> glBegin(GL_LINE_STRIP);
> glArrayElement(...);
> ...
> glEnd();
> glBegin(GL_LINE_LOOP);
> glArrayElement(...);
> ...
> glEnd();
>
> Given that nr_prims only gets large when glBegin/glEnd is in use, I
> don't think we have to worry about performance in the loop.  Let's just
> correct the loop to check all prims, which was almost certainly the
> original intent.

...but I didn't think about Begin/End.  Sounds like it's worth just 
checking all the prims.  Thanks for the investigation!