On 16 October 2013 14:19, Ian Romanick <i...@freedesktop.org> wrote: > On 10/16/2013 02:04 PM, Paul Berry wrote: > > On 16 October 2013 13:50, Ian Romanick <i...@freedesktop.org > > <mailto:i...@freedesktop.org>> wrote: > > > > On 10/16/2013 01:46 PM, Ian Romanick wrote: > > > On 10/16/2013 07:43 AM, Paul Berry wrote: > > >> On 16 October 2013 00:26, Jordan Justen <jljus...@gmail.com > > <mailto:jljus...@gmail.com>> wrote: > > >>> Also, perhaps we should log a spec bug to ask the spec to > > clarify this? > > >> > > >> IMHO, the intent is already clear from the fact that all the > > >> redeclaration examples in the spec include the in/out qualifier. > The > > >> fact that the NVIDIA compiler sometimes misbehaves if in/out is > > absent > > >> seems like adequate confirmation to me. Spec bugs frequently > > take weeks > > >> or months to get resolved, so I guess I'm having trouble > convincing > > >> myself that it's worth it in this case. > > >> > > >> Anyone else want to weigh in with an opinion on this? Idr? > > > > > > I think the spec is already clear, and NVIDIA's implementation is > just > > > buggy. > > > > Arg... but let me be clear. It is already explicitly an error to do: > > > > in vec4 foo; > > vec4 foo; > > > > or > > > > vec4 foo; > > centroid in vec4 foo; > > > > or > > > > in vec4 foo; > > centroid in vec4 foo; // this one is okay. > > > > > > Actually my reading of GLSL 1.50 is that only built-ins can be > > redeclared for purposes of changing their interpolation qualifiers. So > > I think this is illegal too. Does that change your opinion? > > Maybe... I would have to dig around with the spec. Is there some > specific text you had in mind? >
3.7 (Identifiers) says: "However, as noted in the specification, there are some cases where previously declared variables can be redeclared to change or add some property, and predeclared "gl_" names are allowed to be redeclared in a shader only for these specific purposes. More generally, it is an error to redeclare a variable, including those starting "gl_"." And the text that allows redeclaration to change interpolation qualifiers is in section 4.3.9.1 (Redeclaring Built-in Interpolation Variables in the Compatibility Profile). It begins: "The following predeclared variables can be redeclared with an interpolation qualifier when using the compatibility profile:" I can't find any text saying that non-built-in variables can be redeclared with an interpolation qualifier, so the text from 3.7 saying that it's an error to redeclare a variable seems like it applies. > > If this is in fact the case, then NVIDIA may well be following the > letter of the spec in the fragment shader. Redeclaring gl_ClipDistance > without "in" makes it a plain global variable... that is never > initialized, so reading results in garbage data. Lol. > I suspect this is what the driver is doing, but I don't see any spec text indicating that it's ok. Changing an input into an ordinary global is definitely *not* one of the "specific purposes" that the spec outlines where redeclaration is allowed. At the moment I'm fairly convinced that redeclaring gl_ClipDistance to remove "in" should be an error, and NVIDIA's compiler is just failing to detect the error condition and going off into the weeds. > > > vec4 foo; // this one is not. > > > > There is no reason to believe built-in variables should have a > different > > set of rules. Right? > >
_______________________________________________ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
