Ian Romanick <i...@freedesktop.org> writes: > On 04/11/2014 04:35 PM, Eric Anholt wrote: >> Ian Romanick <i...@freedesktop.org> writes: >> >>> From: Ian Romanick <ian.d.roman...@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.
pgpb3nc6larjo.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
