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

[Ian Romanick]

On 02/07/2013 08:40 AM, Brian Paul wrote:
> On 02/06/2013 03: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?
>
> Have you tested NVIDIA or AMD's driver to see what they do for GLSL
> 1.30, 1.40, etc?  That is, do they follow the spec to the letter or are
> they more lax?

I was going to ask the same question.  If everyone follows the 150+ 
behavior even when '#version 130' is specified, we should do that too.

> Otherwise, sounds OK to me, Paul.
>
> -Brian