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

[Jordan Justen]

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?

-Jordan