| Summary: | glLinkProgram() should fail when a varying is never written to in a previous stage | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Link Mauve <bugs> |
| Component: | glsl-compiler | Assignee: | Ian Romanick <idr> |
| Status: | RESOLVED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Severity: | enhancement | ||
| Priority: | medium | CC: | lemody |
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Testcase exhibiting this bug, red patterns randomly happen when line 55 is commented. | ||
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) 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. (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. 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. I sent a patch for this to the mailing list: https://lists.freedesktop.org/archives/mesa-dev/2016-February/107686.html Is there a piglit test for this functionality? (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. How we collect and use information is described in our Privacy Policy.
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.