This will be broken for indirect draws too, and possibly performance-crippling to fix there, since we don't have the baseVertex value available to shove into a uniform.
On Sun, Jun 22, 2014 at 3:36 AM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 21.06.2014 03:00, schrieb Ian Romanick: >> This patch series fixes bugs in the i965 w.r.t. several uses of >> gl_VertexID. OpenGL (desktop and ES) have the following expectations of >> gl_VertexID: >> >> 1. When used with BaseVertex drawing commands, gl_VertexID will include >> the value of basevertex. This differens from "the other API," but the >> change in OpenGL was based on feedback from application developers. >> This only affects OpenGL 3.2+. > > I don't question this, but note some binary drivers may not agree. There > are unforunately lots of man pages around of > glDrawElementsInstancedBaseVertexBaseInstance too which state: > "The basevertex has no effect on the shader-visible value of > gl_VertexID." There's a bug filed about this > (https://www.khronos.org/bugzilla/show_bug.cgi?id=932) which is still > open though maybe it has all been resolved... > (I'll just mention that llvmpipe right now will do d3d10-style vertexID > though I guess indeed at some point we need to make it either switchable > or implement GL_ARB_shader_draw_parameters so it can be worked around > easily in the state tracker.) > > Roland > > >> >> 2. When used with DrawArrays drawing commands, gl_VertexID will count >> from the 'start' value instead of zero. This affects OpenGL 3.0+ and >> OpenGL ES 3.0+. >> >> The i965 driver botched both of these for slightly different reasons. >> For #1, our hardware was designed with the "other API's" semantic in >> mind, so gl_VertexID doesn't include the basevertex value. >> >> For #2, we implement DrawArrays with a non-zero start index by >> reprogramming the array base offset. As a result, gl_VertexID always >> counts from zero. >> >> I suspect other hardware may suffer from one or both of these issues. I >> have sent tests to the piglit list to reproduce them. >> >> To fix both of these issues, the shader needs to know the basevertex >> value. A later GL extension, GL_ARB_shader_draw_parameters, adds >> gl_BaseVertex and gl_BaseInstance as built-in variables. I believe some >> hardware implements these as system values much like gl_VertexID. >> >> I started this series with the assumption that we could have a >> SYSTEM_VALUE_BASE_VERTEX that might come from a uniform. In the end, I >> couldn't make that work. I left patch 7 in the series, but we may want >> to remove it. >> >> I added a STATE_BASE_VERTEX uniform instead. >> >> There is now a lowering pass that converts gl_VertexID to >> gl_VertexIDMESA + gl_BaseVertex (backed by a uniform). Some of these >> names should probably be changed. >> >> I have also contemplated adding an extension that exposes the other >> semantic for gl_VertexID for applications that actually want that. This >> is primarily things that are porting content (or "bridging" content) >> from the other API. That, however, can happen later. >> >> _______________________________________________ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=E56BlL24I31lr1fFtEsKBJjAprQ%2BQdhUczD1EsQ3dIY%3D%0A&s=2634834afd3400c841ab62f11a9b5350d604592529cfea97f2297c9398c0fd93 >> > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
