Bug 93339 - glLinkProgram() should fail when a varying is never written to in a previous stage
Summary: glLinkProgram() should fail when a varying is never written to in a previous ...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: glsl-compiler (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium enhancement
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-10 21:28 UTC by Link Mauve
Modified: 2016-02-16 00:27 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Testcase exhibiting this bug, red patterns randomly happen when line 55 is commented. (5.06 KB, text/plain)
2015-12-10 21:28 UTC, Link Mauve
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Link Mauve 2015-12-10 21:28:01 UTC
Created attachment 120455 [details]
Testcase exhibiting this bug, red patterns randomly happen when line 55 is commented.

If a varying is declared in one stage and read from in the next stage, without having been written to, the link step don’t fail and will generate a working program object, but that varying will read from seemingly uninitialized video memory (at least on i965, llvmpipe seems to read from 0-initialized memory instead).

I haven’t looked at the specification, but I can’t see any usecase for this specific behaviour, which should imo be reported to the user before they can use the program object.
Comment 1 Tapani Pälli 2015-12-14 08:02:12 UTC
I don't see that GL specification would state link failure for variables that are read but not written. There are number of instances of "Values for any inputs that are not written by a shader are undefined." within description of different shader stages.

When using separate shader objects on desktop, one is able to even combine programs with interfaces that do not match exactly, on GL ES they have to be exact match (same amount of outputs and inputs)
Comment 2 Kenneth Graunke 2015-12-14 09:28:29 UTC
Perhaps we should generate a link time warning in this case, when GL_PROGRAM_SEPARABLE is not set?  That seems like it could be helpful.

I'm tempted to change the subject and reopen this as an enhancement.
Comment 3 Tapani Pälli 2015-12-14 09:37:09 UTC
(In reply to Kenneth Graunke from comment #2)
> Perhaps we should generate a link time warning in this case, when
> GL_PROGRAM_SEPARABLE is not set?  That seems like it could be helpful.
> 
> I'm tempted to change the subject and reopen this as an enhancement.

I guess it should be possible to generate warning. I'm not sure if we currently track if some variable was written in to during/after optimizations etc though.
Comment 4 Link Mauve 2015-12-17 17:13:27 UTC
There is actually already an error being emitted, only in GLSL 1.20: “program shader 10 compile for <both> failed : error: fragment shader varying some_varying not written by vertex shader”

If I just change the GLSL version to 1.30 for example the program will link properly and the GPU will read from uninitialized memory.

I’m fine with only emitting a warning in this case, if the specification allows it.
Comment 5 Timothy Arceri 2016-02-15 03:07:52 UTC
I sent a patch for this to the mailing list:

https://lists.freedesktop.org/archives/mesa-dev/2016-February/107686.html
Comment 6 Mark Janes 2016-02-15 16:32:01 UTC
Is there a piglit test for this functionality?
Comment 7 Timothy Arceri 2016-02-16 00:27:57 UTC
(In reply to Mark Janes from comment #6)
> Is there a piglit test for this functionality?

The bug title is wrong we shouldn't fail to link in this case. The Mesa change is to warn in GL as well as ES which we already do. As for failing in version 1.20 and below there could be a test in the /shaders dumping ground I had a quick look but couldn't find anything obvious.

Fixed by:

commit	00a1bd13b5c6b565b5d15409a6f814b0df2fbe29
glsl: warn in GL as well as ES when varying not written

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93339


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.