[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