On 7 February 2013 17:33, Ian Romanick <i...@freedesktop.org> wrote:
> 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 >> > > 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.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
