Bug 98245

These seem to be two different issues so I think it is probably best to create two different bug reports.

I have sent a patch for review that fixes the first one:
https://lists.freedesktop.org/archives/mesa-dev/2016-October/132896.html

(In reply to Iago Toral from comment #1)
> These seem to be two different issues so I think it is probably best to
> create two different bug reports.
> 
> I have sent a patch for review that fixes the first one:
> https://lists.freedesktop.org/archives/mesa-dev/2016-October/132896.html

This patch is now in master:

commit 537dce06ec8e0fa4becd42d5e4b3d07cf722387f
Author: Iago Toral Quiroga <itoral@igalia.com>
Date:   Fri Oct 21 13:15:41 2016 +0200

    glsl: add matrix layout information to interface block types
    
    So far we have been checking that interface block definitions had matching
    matrix layouts by comparing the definitions of their fields, however, this
    does not cover the case where the interface blocks are defined with
    mismatching matrix layouts but don't define any field with a matrix type.
    In this case Mesa will not fail to link because none of the fields will
    inherit the mismatching layout qualifier.
    
    This patch fixes the problem in the same way we fixed it for packing layout
    information: we add the the layout information to the interface type and then
    we check it matches during the uniform block linking process.
    
    v2: Fix unit tests so they pass the new parameter to
        glsl_type::get_interface_instance()
    
    Fixes:
    dEQP-GLES31.functional.shaders.linkage.uniform.block.layout_qualifier_mismatch_3
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98245
    Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v1)

I have just sent another patch that fixes the second case:
https://lists.freedesktop.org/archives/mesa-dev/2016-November/134315.html

(In reply to Iago Toral from comment #3)
> I have just sent another patch that fixes the second case:
> https://lists.freedesktop.org/archives/mesa-dev/2016-November/134315.html

This should now be fixed with:

commit 89334175658ffc4bae2e2b4f3efa9ea3a21cfa93
Author: Iago Toral Quiroga <itoral@igalia.com>
Date:   Fri Nov 4 13:37:58 2016 +0100

    glsl: validate output blocks against input blocks
    
    Until now were validating in/out blocks by listing the inputs in the
    consumer stage and then, for each output of the producer, we checked that
    it was a match if it was consumed. This method does not catch the case
    where the consumer has an input that is not present as an output in the
    producer stage, because it only generates link errors for outputs present
    in the producer stage that don't match the inputs in the consumer stage.
    The current method does catch the case were an output from the producer
    stage is not consumed, which is irrelevant and is ignored.
    
    By reversing the way we do this, we can detect this situation, so this
    patch lists the outputs of the producer stage and then validates inputs
    of the consumer stage against them. If we see an input in the consumer
    for which there is no associated output in the producer, we produce a
    link error.
    
    The only exception to this is the special built-in input block gl_in[],
    since this is implicitly generated for geometry and tessellation stages,
    but we don't generate it if the producer stage does not write to any of
    the pre-defined outputs (for example, if the vertex shader does not write
    to gl_Position, etc). Since writing to these is not mandatory, do not
    produce a link error in that case. There is a CTS tessellation test
    (GL45-CTS.tessellation_shader.program_object_properties) that has an
    empty vertex shader (so it does not produce gl_in[]) and would fail to
    link if we don't do this.
    
    This fixes the following dEQP test:
    dEQP-GLES31.functional.shaders.linkage.io_block.missing_output_block
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98245
    Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>