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

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to