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.
Hrm... that's weird. ARB_sso came with 4.1, so it predates the relaxation of the ordering rules. `precise` came in 4.0. The 4.0 and 4.1 specs provide approximately jack squat for guadance that I can find. > I propose relaxing the rules in type_qualifier as follows: > > * If neither GLSL 4.20 nor ARB_shading_language_420pack is supported, Do you mean supported or enabled (in the shader)? ARB_shading_language_420pack is supported by every driver that supports GLSL 1.30. > 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. > > I think this retains all the useful current behavior, and will accept > all the examples I've seen. > > -- Chris _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
