[Mesa-dev] ARB_sso layout() + other qualifiers

Ian Romanick idr at freedesktop.org
Wed Jun 4 09:45:45 PDT 2014


On 05/19/2014 10:06 PM, Chris Forbes wrote:
> Hi Ian,
> 
> When I was writing the `precise` support I found some error cases in
> the GLSL parser where we reject combinations of layout() with
> invariant / interpolation / etc qualifiers.
> 
> This seems to be consistent with the GLSL 1.50 grammar (or, at least,
> admits all the examples that were given in various GLSL specs and
> extension specs), but I don't think it works any more with SSO, since
> you'd want to be able to do rendezvous-by-location on qualified
> variables. The body of the ARB_sso spec doesn't clearly make the
> changes required to allow this, but various parts of the spec hint at
> it being possible, with the most obvious being in the resolution of
> issue 13:
> 
>     13. How are interpolation modifiers handled for separate shader
>         programs?
> 
>         RESOLVED:  GLSL only provides interpolation modifiers for user-
>         defined varyings. These modifiers can be used in conjunction
>         with the layout location qualifiers specified in this extension.
>         Such modifiers must match.
> 
> I propose relaxing the rules in type_qualifier as follows:
> 
> * If neither GLSL 4.20 nor ARB_shading_language_420pack is supported,
> then require layout qualifiers to precede any other qualifiers;
> continue to disallow multiple layout qualifiers.
> 
> * Remove all other error generation for combining layout with
> invariant / interpolation / (with my other patches) precise.

With the ratonale that the spec provides no guidance where it should be
relative to the other qualifiers.  Looking at the grammar in section 4.8
(Order of Qualification) of the 4.1 spec and inferring from section
4.3.8 (Layout Qualifiers) and its subsections, I think we should require
the layout be before the storage-qualifier (i.e., before "uniform").  I
don't think the spec justifies anything stronger than that.

Does that sound reasonable to you?

> I think this retains all the useful current behavior, and will accept
> all the examples I've seen.
> 
> -- Chris



More information about the mesa-dev mailing list