Bug 105731 - linker error "fragment shader input ... has no matching output in the previous stage" when previous stage's output declaration in a separate shader object
Summary: linker error "fragment shader input ... has no matching output in the previou...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: glsl-compiler (show other bugs)
Version: git
Hardware: All Linux (All)
: medium minor
Assignee: mesa-dev
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-24 18:14 UTC by Marcel Heinz
Modified: 2018-10-29 11:08 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments
C/OpenGL code to trigger the issue (3.26 KB, text/x-csrc)
2018-03-24 18:14 UTC, Marcel Heinz 		Details
updated reproducer code (3.32 KB, text/x-csrc)
2018-10-12 20:00 UTC, Marcel Heinz 		Details
View All

Description Marcel Heinz 2018-03-24 18:14:23 UTC 
Created attachment 138342 [details]
C/OpenGL code to trigger the issue

GLSL spec (using version 4.30 here, section "4.3.4 Input variables", page 43f) states that there should be no link error if an input variable is used for which there is no static use in the previous stage, but a valid output declaration.

Mesa's linker seems to adhere to this not in every case. If the declaration is in a separate shader object, it fails to link. See the attached example code. The key point is the following vertex shader:

    static const char *vs_part1=
        "out vec4 foo;\n"
        "void unused() {foo=vec4(1);}\n";

    static const char *vs_part2=
        "in vec4 pos;\n"
        "void main() { gl_Position = pos; }\n";

used in conjunction with this fragment shader:
    static const char *fs_part1=
        "in vec4 foo;\n"
        "out vec4 color;\n"
        "void main() {color=foo;}\n";

When this is created as a single GL_VERTEX_SHADER with both strings concatenated (via glShaderSource), the resulting program will link, just with a warning

    warning: fragment shader varying foo not written by vertex shader

which is conforming behavior.

However, when vs_part1 and vs_part2 are compiled as separate shader objects, the final link fails with

    error: fragment shader input `foo' has no matching output in the previous 
           stage

which (in my interpretation of the spec) should not happen.

Tested with:
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile 
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.1.1 (git-092c485)

as well as:
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile 
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.1.0-devel (git-ff0e3fa1fe)
Comment 1 vadym 2018-08-28 07:37:24 UTC 
Patch: https://patchwork.freedesktop.org/patch/246171/
Comment 2 Timothy Arceri 2018-08-29 10:11:58 UTC 
Should be fixed by:

Author: vadym.shovkoplias <vadym.shovkoplias@globallogic.com>
Date:   Tue Aug 28 10:32:18 2018 +0300

    glsl/linker: Link all out vars from a shader objects on a single stage
    
    During intra stage linking some out variables can be dropped because
    it is not used in a shader with the main function. But these out vars
    can be referenced on later stages which can lead to further linking
    errors.
    
    Signed-off-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com>
    Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105731
Comment 3 Mark Janes 2018-08-29 19:21:43 UTC 
Vadym, can you make a piglit test for this bug?
Comment 4 Timothy Arceri 2018-08-30 01:00:11 UTC 
(In reply to Mark Janes from comment #3)
> Vadym, can you make a piglit test for this bug?

Hi Mark, this was already done :)

commit c98669cbd1f801c8fda25aceab23b5c54de76b9e
Author: Vadym Shovkoplias <vadim.shovkoplias@gmail.com>
Date:   Mon Aug 27 15:19:40 2018 +0300

    glsl-1.30: add linker test for inter stage in/out vars usage
    
    This test exposes a Mesa GLSL linker bug. The test fails with the
    following error message:
    
       error: fragment shader input `foo' has no matching output in the previous
              stage
    
    Signed-off-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com>
    Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105731
Comment 5 Marcel Heinz 2018-10-12 20:00:18 UTC 
Created attachment 142005 [details]
updated reproducer code
Comment 6 Marcel Heinz 2018-10-12 20:06:29 UTC 
Comment on attachment 142005 [details]
updated reproducer code

The bugfix from https://patchwork.freedesktop.org/patch/246171/ did solve the issue for my first reproducer, the issue is not completely resolved.

This is an updated version of the reproducer code, which triggers the issue again.

The only changes are that there are now _two_ VS outputs which are not written to, but both are used in the fragment shader:
Comment 7 Marcel Heinz 2018-10-12 20:09:01 UTC 
Reopened bug because bug was not completely resolved. See the second attachment with the updated reproducer code for another case to tirgger the issue.
Comment 8 vadym 2018-10-24 11:22:09 UTC 
(In reply to Marcel Heinz from comment #7)
> Reopened bug because bug was not completely resolved. See the second
> attachment with the updated reproducer code for another case to tirgger the
> issue.

Hi Marcel,

Thanks for the new test. I also able to reproduce this. Already found the reason and pushed new patch: https://patchwork.freedesktop.org/patch/258176/
Comment 9 Marcel Heinz 2018-10-27 13:24:26 UTC 
Hi Vadym,

thank you for that patch. Again, it does fix the updated reproducer, but the issue is still not completely resolved in the real application. However, it is down from 17 failing programs to only 2, so we are getting closer.

I will try to isolate the issue in the two remaining programs, and report back my findings.
Comment 10 Marcel Heinz 2018-10-27 15:34:30 UTC 
Hi Vadym,

I have to take my last comment back. It turned out that in the two remaining cases, there was actually no output declaration for the variable in question, so mesa's behavior was perfectly right already.

Changed bug to RESOLVED status.

Thank You very much.
Comment 11 vadym 2018-10-29 11:08:51 UTC 
Hi Marcel,

Glad to hear this issue is finally fixed! Thanks a lot for such a high quality bug report and assistance/testing. 

Piglit test is also updated with the additional out variable: https://patchwork.freedesktop.org/patch/258899/

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.