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

Brian Paul brianp at vmware.com
Thu Feb 7 08:40:49 PST 2013


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?

Otherwise, sounds OK to me, Paul.

-Brian


More information about the mesa-dev mailing list