[Mesa-dev] RFC: Considering changing Mesa's interpretation of when is the "flat" keyword is required.

[Kenneth Graunke]

On 02/06/2013 02:10 PM, Paul Berry wrote:
> Background:
>
> All of the GLSL specs from GLSL 1.30 (and GLSL ES 3.00) onward contain
> language requiring certain integer variables to be declared with the
> "flat" keyword, but they differ in exactly *when* the rule is enforced:
>
> (a) GLSL 1.30 and 1.40 say that vertex shader outputs having integral
> type must be declared as "flat".  There is no restriction on fragment
> shader inputs.
>
> (b) GLSL 1.50 through 4.30 say that fragment shader inputs having
> integral type must be declared as "flat".  There is no restriction on
> vertex shader outputs.
>
> (c) GLSL ES 3.00 says that both vertex shader outputs and fragment
> shader inputs having integral type must be declared as "flat".
>
> Mesa's current behaviour is consistent with (a).
>
> In a world without geometry shaders, the difference hardly matters,
> since the linker always matches up vertex shader outputs with fragment
> shader inputs.  So (a) allows non-flat integral fragment shader inputs,
> but only if they're not linked up to a vertex shader output (and hence
> contain undefined values).  And (b) allows non-flat integral vertex
> shader outputs, but only if they're not linked up to a fragment shader
> input (and hence never used).  Those seem like pathological cases.
>
> But once we add geometry shaders, the difference is important, and (b)
> really seems like the right choice, because it requires "flat" in just
> the situations where it matters.  It's no surprise that behaviour (b)
> was introduced in GLSL 1.50, at the same time that geometry shaders were
> introduced.
>
>
> Proposal:
>
> I would like to change Mesa to follow rule (c) when compiling ES
> shaders, and follow rule (b) when compiling non-ES shaders, even though
> technically speaking this is a violation of the GLSL 1.30 and GLSL 1.40
> specs.
>
> Rationale: since the difference between (a) and (b) really only matters
> when geometry shaders are present, it seems reasonable to think of the
> change from (a) to (b) as correcting a spec mistake, rather than
> imposing a deliberate behavioural change.  The only apps that would be
> broken by this change are pathological ones.  Also, if we ever want to
> be able to support ARB_geometry_shader4 with GLSL 1.30 or 1.40, it will
> be nicer if we implement behaviour (b) uniformly, since that's the
> behaviour that makes sense in the presence of geometry shaders.
>
>
> Does that seem reasonable?

Seems reasonable to me.  (b) makes the most sense anyway, since the 
fragment stage is the first where interpolation actually matters.

It wouldn't be terribly hard to support (a) and (b) based on language 
version.  But I suspect the only gain there would be passing some 
negative conformance tests.