[Mesa-dev] [PATCH 00/13] Fix gl_VertexID on i965

[Marek Olšák]

That's right. A uniform won't work with ARB_draw_indirect unless you
lower it to direct draws, which would be very bad if it was applied to
all drivers.

Radeonsi indeed supports BaseVertex and BaseInstance as system values
in the vertex shader. Well, vertex fetching has to be done in the
vertex shader on that hardware, so the system values are kinda
required there.

Marek

On Sun, Jun 22, 2014 at 12:27 AM, Chris Forbes <chrisf at ijw.co.nz> wrote:
> 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 <sroland at 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 at 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 at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev