<div dir="ltr">On 7 February 2013 17:33, Ian Romanick <span dir="ltr"><<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 02/07/2013 08:40 AM, Brian Paul wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 02/06/2013 03:10 PM, Paul Berry wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Background:<br>
<br>
All of the GLSL specs from GLSL 1.30 (and GLSL ES 3.00) onward contain<br>
language requiring certain integer variables to be declared with the<br>
"flat" keyword, but they differ in exactly *when* the rule is enforced:<br>
<br>
(a) GLSL 1.30 and 1.40 say that vertex shader outputs having integral<br>
type must be declared as "flat".  There is no restriction on fragment<br>
shader inputs.<br>
<br>
(b) GLSL 1.50 through 4.30 say that fragment shader inputs having<br>
integral type must be declared as "flat".  There is no restriction on<br>
vertex shader outputs.<br>
<br>
(c) GLSL ES 3.00 says that both vertex shader outputs and fragment<br>
shader inputs having integral type must be declared as "flat".<br>
<br>
Mesa's current behaviour is consistent with (a).<br>
<br>
In a world without geometry shaders, the difference hardly matters,<br>
since the linker always matches up vertex shader outputs with fragment<br>
shader inputs.  So (a) allows non-flat integral fragment shader<br>
inputs, but only if they're not linked up to a vertex shader output<br>
(and hence contain undefined values).  And (b) allows non-flat<br>
integral vertex shader outputs, but only if they're not linked up to a<br>
fragment shader input (and hence never used).  Those seem like<br>
pathological cases.<br>
<br>
But once we add geometry shaders, the difference is important, and (b)<br>
really seems like the right choice, because it requires "flat" in just<br>
the situations where it matters.  It's no surprise that behaviour (b)<br>
was introduced in GLSL 1.50, at the same time that geometry shaders<br>
were introduced.<br>
<br>
<br>
Proposal:<br>
<br>
I would like to change Mesa to follow rule (c) when compiling ES<br>
shaders, and follow rule (b) when compiling non-ES shaders, even<br>
though technically speaking this is a violation of the GLSL 1.30 and<br>
GLSL 1.40 specs.<br>
<br>
Rationale: since the difference between (a) and (b) really only<br>
matters when geometry shaders are present, it seems reasonable to<br>
think of the change from (a) to (b) as correcting a spec mistake,<br>
rather than imposing a deliberate behavioural change.  The only apps<br>
that would be broken by this change are pathological ones.  Also, if<br>
we ever want to be able to support ARB_geometry_shader4 with GLSL 1.30<br>
or 1.40, it will be nicer if we implement behaviour (b) uniformly,<br>
since that's the behaviour that makes sense in the presence of<br>
geometry shaders.<br>
<br>
<br>
Does that seem reasonable?<br>
</blockquote>
<br>
Have you tested NVIDIA or AMD's driver to see what they do for GLSL<br>
1.30, 1.40, etc?  That is, do they follow the spec to the letter or are<br>
they more lax?<br>
</blockquote>
<br></div></div>
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.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Otherwise, sounds OK to me, Paul.<br>
<br>
-Brian<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div><div class="gmail_extra">I just checked on my nVidia system, and it follows the 150+ behaviour even when "#version 130" or "#version 140" is specified.  So I'm going to go ahead with my proposal.<br>
</div></div>