[Piglit] [RFC PATCH] Test that in/out qualifiers are required when redeclaring gl_ClipDistance.

[Ian Romanick]

On 10/16/2013 02:04 PM, Paul Berry wrote:
> On 16 October 2013 13:50, Ian Romanick <idr at freedesktop.org
> <mailto:idr at 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 <jljusten at gmail.com
>     <mailto:jljusten at 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?