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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
