<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Access violation on glDrawArrays with count >= 2048" href="https://bugs.freedesktop.org/show_bug.cgi?id=107295#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Access violation on glDrawArrays with count >= 2048" href="https://bugs.freedesktop.org/show_bug.cgi?id=107295">bug 107295</a> from <a class="email" href="mailto:sroland@vmware.com" title="Roland Scheidegger <sroland@vmware.com>"> Roland Scheidegger</a> <pre>(In reply to Paul from <a href="show_bug.cgi?id=107295#c2">comment #2</a>) > I managed to build a debug version of Mesa3D 10.4.7 (version 18 is a > pre-built binary without debugging information), and this is what I got for > a callstack: Thanks, but a callstack with a more recent version would have been more useful. > The test program is, therefore, setting PT_PIPELINE while the actual program > is not (what exactly causes clipped to be true or false in terms of the > OpenGL context?). Simple, if at least some of the vertices are outside the viewport clipped will be set (if there's no gs, this will be determined directly in the generated shader, otherwise draw_pt_post_vs_run() will determine it). (PT_PIPELINE will also be already set if you hit the draw pipeline fallbacks, such as drawing tris in wireframe or point mode, but it appears this isn't the case here.) > Forcing the code to call emit indraw_pt_post_vs_runstead of pipeline by using > the debugger does reproduce the crash. Forcing the actual program to call > pipeline instead of emit does not crash and does show the proper output. > translate->key.output_stride = 32 > translate->key.nr_elements = 2 > vert_info->stride = 68 > vert_info->count = 101088 > > I assume the values are associated with the output of the geometry shader. > There I specify a max_vertices of 32, and it produces 2 outputs: position > and color. The 32 would also refer to the number of bytes for the output: > position and color are both vec4. The 68 doesn't make sense, though. I do > emit 32 vertices in batches of 4 vertices for a triangle strip primitive. The 68 indeed is the stride of the output vertices of the gs here. So 32 bytes plus the vertex header, though (should be 20 bytes, 4 floats for clip pos, plus another 4 bytes for flag bits - I think it's 68 here and not 52 because you're using a prehistoric mesa version). I can reproduce this here. I think it might be a bug in the translate code but not sure (valgrind shows it's writing past the allocated buffer size for the output (driver) vertices). Or the parameters to it aren't quite right (it does not appear to be a bug in the generated translate code directly, since if that's commented out (see translate_create()) it'll crash in the memcpy used in the generic path instead). I'll try to look into this.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>