On 08/30/2013 12:26 PM, Paul Berry wrote:
On 30 August 2013 10:36, Eric Anholt <e...@anholt.net <mailto:e...@anholt.net>> wrote:Kenneth Graunke <kenn...@whitecape.org <mailto:kenn...@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!
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
