>________________________________________ >From: Brian Paul <bri...@vmware.com> >Sent: Wednesday, November 4, 2015 12:03 PM >To: Charmaine Lee; mesa-dev@lists.freedesktop.org >Subject: Re: [Mesa-dev] [PATCH] vbo: fix another GL_LINE_LOOP bug
>On 11/04/2015 12:40 PM, Charmaine Lee wrote: >> >> I concur with Sinclair and Roland that the vbo code is quite tricky. >> I do have a question, so when the line loop spans multiple vertex buffers, >> where is 0th vertex stored exactly? >It depends. If the line loop started in a new/empty VB, the 0th vertex >is at the start of the buffer. But if the line loop started later in >the buffer (because another primitive before it), the 0th vertex will be >at the prim->start position. >I didn't find the bug that this patch fixes earlier, because my test >programs all hit the first case. We have to draw at least two >primitives to hit some of the corner cases. >> In vbo_exec_End, you are changing src = exec->vtx.buffer_map + >> last_prim->start * exec->vtx.vertex_size; >> If the 0th vertex is always copied to the beginning of the buffer, why do >> you need this change? >To account for the second case, above. >> If it was not copied to the beginning of the buffer, couldn't it be >> overwritten by the subsequent vertices? >This patch actually fixes a case where subsequent vertices _were_ >overwriting previous vertices when another primitive followed the line >loop. That's the change at line 846. So if last_prim->start is 100, and if the line loop spans 3 vertex buffers, so at the second vbo_exec_wrap_buffers(), can't the original vertex 0 which is at buffer_map + 100 * vertex_size be already overwritten by the vertices that are now in the second vertex buffer? -Charmaine _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
