[Mesa-dev] RFC: Considering changing Mesa's interpretation of when is the "flat" keyword is required.

[Paul Berry]

On 7 February 2013 17:33, Ian Romanick <idr at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130208/33fd2aaf/attachment.html>