[Mesa-dev] [PATCH v4 17/17] glsl linker: compare interface blocks during interstage linking

[Ian Romanick]

On 05/21/2013 11:44 AM, Jordan Justen wrote:
> On Tue, May 21, 2013 at 12:11 AM, Kenneth Graunke <kenneth at whitecape.org> wrote:
>> On 05/16/2013 05:44 PM, Jordan Justen wrote:
>>>
>>> Verify that interface blocks match when linking separate shader
>>> stages into a program.
>>>
>>> Fixes piglit glsl-1.50 tests:
>>> * linker/interface-blocks-vs-fs-member-count-mismatch.shader_test
>>> * linker/interface-blocks-vs-fs-member-order-mismatch.shader_test
>>>
>>> Signed-off-by: Jordan Justen <jordan.l.justen at intel.com>
>>> ---
>>>    src/glsl/interface_blocks.cpp |   47
>>> +++++++++++++++++++++++++++++++++++++++--
>>>    src/glsl/interface_blocks.h   |    4 ++++
>>>    src/glsl/linker.cpp           |    6 ++++++
>>>    3 files changed, 55 insertions(+), 2 deletions(-)
>>
>>
>> I have a few annoying spec questions:
>>
>> 1. What happens if the producer has output interfaces not used by the next
>> stage?  Is that legal (like unused varyings)?
>>
>> For example,
>>     [vertex shader]
>>     out foo { vec4 a };
>>     out bar { int b };
>>
>>     [fragment shader]
>>     in foo { vec4 a };
>>     // FS does not reference bar
>
> I'd been assuming this was allowed, similar to unused varyings.
>
>> 2. What happens if the consumer has input interfaces not declared in the
>> previous stage?  Is that legal?  If so, does it get populated with undefined
>> values?
>>
>> For example,
>>     [vertex shader]
>>     out foo { vec4 a };
>>     // VS does not declare/write bar
>>
>>     [fragment shader]
>>     in foo { vec4 a };
>>     in bar { int b };
>>
>> The text in the spec is really obnoxious...it's so hand-wavy and full of
>> examples and prose...
>
> I'd been assuming that this would be a link error.
>
> Do you think these assumptions are reasonable, or should I investigate
> the behavior of other drivers?

Yes and yes.  My assumption is that the existing language in the spec 
about inputs and outputs is supposed to apply to interfaces.  We should 
verify that other drivers have made the same assumptions.  Whatever the 
result, we should also suggest some tighter spec language to Khronos.

> -Jordan
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>