[Mesa-dev] RFC: Considering changing Mesa's interpretation of when is the "flat" keyword is required.
Paul Berry
stereotype441 at gmail.com
Wed Feb 6 14:10:04 PST 2013
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130206/f14e352d/attachment.html>
More information about the mesa-dev
mailing list