[Mesa-dev] [PATCH 11/19] glsl: Track explicitly set location independent from the actual location
Ian Romanick
idr at freedesktop.org
Fri Apr 18 13:27:19 PDT 2014
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140418/6ddf8b7b/attachment.sig>
More information about the mesa-dev
mailing list