On 7 February 2013 08:40, Brian Paul <bri...@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.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
