[Mesa-dev] [PATCH] [rfc] glsl: allow invariant on fragment shader outputs.

[Andres Gomez]

Hi,

On Mon, 2016-05-23 at 14:18 +1000, Dave Airlie wrote:
> From: Dave Airlie <airlied at redhat.com>
> 
> A CTS test manages to generate this:
> GL45-CTS.shading_language_420pack.qualifier_order
> 
> I cannot find definitive evidence in the spec that it isn't
> allowed. The specs mentions some things can't be used on
> fragment shader outputs, but never specifies invariant as
> one of them. Chris found GLSL1.20 was more explicit about this
> but the language was changed/removed in GLSL 1.30.
> 
> This might be a spec bug, I'm not sure.

Specs are ambiguous, so I think it can be considered a bug in the
specs, since they are not that explicit to ban the qualifier in the FS
outputs.

However, my understanding is that using the qualifier is not valid and,
hence, this patch should be dropped.

>From page 27 (page 33 of the PDF) of the GLSL 1.20 spec:
    
  " Only variables output from a vertex shader can be candidates for
    invariance."
    
But this later changes to:
    
>From page 37 (page 43 of the PDF) of the GLSL 1.30 spec:
    
  " Only variables output from a shader can be candidates for
    invariance."
    
However, there is little sense on allowing this qualifier for the FS
outputs and, actually, we can also read, in this direction:
    
>From page 37 (page 43 of the PDF) of the GLSL 1.30 spec:
    
  " Initially, by default, all output variables are allowed to be
    variant. To force all output variables to be invariant, use the
    pragma
    
      #pragma STDGL invariant(all)
    
    before all declarations in a shader. If this pragma is used after
    the declaration of any variables or functions, then the set of
    outputs that behave as invariant is undefined. It is an error to
    use this pragma in a fragment shader."
    
Then, I think it is safe to assume that the individual use of
"invariant" is also forbidden in FS outputs.

However, would the conclusion be that FS outputs are actually allowed
to be qualified as invariant, this patch LGTM, then.

-- 

Br,

Andres