[Mesa-dev] [PATCH 11/19] glsl: Track explicitly set location independent from the actual location

Eric Anholt eric at anholt.net
Sun Apr 20 16:53:11 PDT 2014


Ian Romanick <idr at freedesktop.org> writes:

> On 04/11/2014 04:35 PM, Eric Anholt wrote:
>> Ian Romanick <idr at freedesktop.org> writes:
>> 
>>> From: Ian Romanick <ian.d.romanick at intel.com>
>>>
>>> Almost all of the time the location set by layout(location=...) is the
>>> location that will be used for the variable.  Vertex shader inputs and
>>> fragment shader outputs, for example, are visible to the API.  We just
>>> use those actual settings.
>>>
>>> Locations set for varyings, however, are a different story.  In those
>>> cases, the locations set in the shader are just used to facilitate
>>> matching outputs to inputs.  We need to track the value so that we can
>>> ensure that
>>>
>>>    layout(location=2) out float foo;
>>>
>>> will be assigned the same resource as
>>>
>>>    layout(location=2) in float bar;
>>>
>>> but we probably don't want to use 2 as the actual location in the set of
>>> varyings.
>> 
>> I assumed that layout(location=2) would be using VARYING_SLOT_VARx -- I
>> don't know of any reason to try and pack these, and it sucks to see
>> another field in our already-bloated ir_variables.  It looks like other
>> code in the series would go away if we just mapped things directly to
>> VARYING_SLOTs.
>
> I started off with that approach, and I encountered a couple problems.
> Since you can have a mix of varyings with and without explicit
> locations, it made the code for resetting the locations during link more
> complex.  I recall thinking that the changes should have been simple and
> obvious, but they weren't.  It was a few months ago at this point, so I
> don't recall the details.
>
> The other problem was that the i965 backend makes assumptions about
> there not being holes in the set of varyings used.  When shaders ended
> up using, say, VARYING_SLOT_VAR0 and VARYING_SLOT_VAR1 (but not
> VARYING_SLOT_VAR2), I started hitting assertions in the backend.  It
> seemed easier and less obtrusive to have the frontend continue giving
> the backend shaders that matched its assumptions.

There shouldn't be anything requiring that varying slots used be
contiguous.  For example, someone could use gl_TexCoord[0] and
gl_TexCoord[2] today, and there should be an open slot between the two.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140420/d1302d55/attachment.sig>


More information about the mesa-dev mailing list