<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Gallium: GL_LINE_LOOP broken with more than 512 points" href="https://bugs.freedesktop.org/show_bug.cgi?id=81174#c16">Comment # 16</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Gallium: GL_LINE_LOOP broken with more than 512 points" href="https://bugs.freedesktop.org/show_bug.cgi?id=81174">bug 81174</a> from <a class="email" href="mailto:brianp@vmware.com" title="Brian Paul <brianp@vmware.com>"> Brian Paul</a> <pre>I'm digging into this bug because it pertains to an issue with a particular app and the VMware gallium driver. The VBO code for splitting GL_LINE_LOOP is actually correct, I believe, but our implementations of vbo_context::draw_prims(), such as st_draw_vbo() and brw_draw_prims() are subtly broken. And has been broken since day one! The issue comes from the two 'begin' and 'end' flags in the _mesa_prim structure. These flags indicate whether the primitive's vertices start at a glBegin() and whether the prim's vertices end at a glEnd(). Suppose we have a long GL_LINE_LOOP that gets broken into three pieces. Here are the flags for the three _mesa_prims that we draw: _mesa_prim[0].begin = 1 _mesa_prim[0].end = 0 _mesa_prim[1].begin = 0 _mesa_prim[1].end = 0 _mesa_prim[2].begin = 0 _mesa_prim[2].end = 1 For all three drawing calls, the 0th vertex in the primitive's vertex buffer will be a copy of the first glVertex() issued after glBegin. If N is the number of vertices in the _mesa_prim: For _mesa_prim[0] we should draw the line segments from v[0] .. V[N-1] For _mesa_prim[1] we should draw the line segments from v[1] .. V[N-1] For _mesa_prim[2] we should draw the line segments from v[1] .. V[N-1] and an extra line from V[N-1] to v[0] You can see this in the old 'tnl' code's t_vb_rendertmp.h code for GL_LINE_LOOP. Our implementations of draw_prims() ignore those flags and always draw V[0].V[N-1] so we get the stray lines that people are seeing. Furthermore, draw_prims() is supposed to look at the 'begin' flag to know when to reset the line stipple counter. We don't do that in the state tracker either. I've posted a patch series that fixes this. The basic idea is when we have to split a GL_LINE_LOOP, draw the pieces with GL_LINE_STRIP instead so that drivers don't need to worry about the 'begin' and 'end' flags (except where the stipple counter matters). Drivers will only get a GL_LINE_LOOP when all the vertices live in one vertex buffer. Unfortunately, after fixing the VBO code, there's still a bug somewhere in the gallium 'draw' code. See comments in the patch series for more information.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>