Bug 98245 - GLES3.1 link negative dEQP "expected linking to fail, but passed."
Summary: GLES3.1 link negative dEQP "expected linking to fail, but passed."
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: glsl-compiler (show other bugs)
Version: git
Hardware: All Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: i965-deqp
  Show dependency treegraph
 
Reported: 2016-10-14 06:19 UTC by Randy
Modified: 2016-11-10 07:11 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Randy 2016-10-14 06:19:04 UTC
Besides two cases in bug 98138, there are another two, tracked separately first.

dEQP-GLES31.functional.shaders.linkage.uniform.block.layout_qualifier_mismatch_3.qpa: <Result StatusCode="Fail">expected linking to fail, but passed.</Result>

dEQP-GLES31.functional.shaders.linkage.io_block.missing_output_block.qpa: <Result StatusCode="Fail">expected linking to fail, but passed.</Result>

Mesa git top commit: 389d6dedbe75defe07216ad761569a9b94f44e58
dEQP git top commit: ca988480be945772473f9256b6ae91fa6aa62bd1

Reproduced on HSW and SKL
Comment 1 Iago Toral 2016-10-21 11:20:17 UTC
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
Comment 2 Iago Toral 2016-10-25 05:58:00 UTC
(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)
Comment 3 Iago Toral 2016-11-04 13:29:30 UTC
I have just sent another patch that fixes the second case:
https://lists.freedesktop.org/archives/mesa-dev/2016-November/134315.html
Comment 4 Iago Toral 2016-11-10 07:11:04 UTC
(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>


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.