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

Paul Berry stereotype441 at gmail.com
Thu Feb 7 09:05:29 PST 2013

On 7 February 2013 08:40, Brian Paul <brianp at vmware.com> 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?
> Otherwise, sounds OK to me, Paul.
> -Brian

That's a good question.  I have an nVidia system--I'll run some tests on it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130207/459ae4d2/attachment-0001.html>

More information about the mesa-dev mailing list