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? 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. > 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
