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

[Paul Berry]

On 16 October 2013 14:19, Ian Romanick <idr at freedesktop.org> wrote:

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

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?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20131016/78473201/attachment-0001.html>