Bug exposed by the FS precompile patch, but shouldn't be caused by it.
>> valgrind ./bin/glslparsertest tests/spec/glsl-1.00/compiler/qualifiers/fn-inout-array-allowed-cstyle.vert pass 1.00 --check-link
==2246== Memcheck, a memory error detector
==2246== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==2246== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==2246== Command: ./bin/glslparsertest tests/spec/glsl-1.00/compiler/qualifiers/fn-inout-array-allowed-cstyle.vert pass 1.00 --check-link
==2246== Conditional jump or move depends on uninitialised value(s)
==2246== at 0x990A83D: fs_visitor::emit_fb_writes() (brw_fs_visitor.cpp:2188)
==2246== by 0x98F5CF2: fs_visitor::run() (brw_fs.cpp:1992)
==2246== by 0x98F617E: brw_wm_fs_emit (brw_fs.cpp:2093)
==2246== by 0x98CE4E9: do_wm_prog (brw_wm.c:305)
==2246== by 0x98F674A: brw_fs_precompile(gl_context*, gl_shader_program*) (brw_fs.cpp:2207)
==2246== by 0x991029D: brw_shader_precompile(gl_context*, gl_shader_program*) (brw_shader.cpp:70)
==2246== by 0x991089E: brw_link_shader (brw_shader.cpp:215)
==2246== by 0x9E616DC: _mesa_glsl_link_shader (ir_to_mesa.cpp:3159)
==2246== by 0x9CD29BE: link_program (shaderapi.c:773)
==2246== by 0x9CD384B: _mesa_LinkProgramARB (shaderapi.c:1281)
==2246== by 0x50C312F: stub_glLinkProgram (generated_dispatch.c:13971)
==2246== by 0x401862: test (glslparsertest.c:187)
This causes tests to chew through a lot of time, since it's looping for some non-deterministic amount of time.
Wow, this totally broke Piglit something awful (at least with precompiles on) :(
Patch on mailing list:
Fixed in master by:
Author: Kenneth Graunke <email@example.com>
Date: Wed Aug 29 01:51:17 2012 -0700
i965/fs: Initialize output_components by filling it with zeros.
Prior to commit 2f1869822, emit_fb_writes() looped from 0 to 3, writing
all four components of a vec4 color output. However, that broke for
smaller output types (float, vec2, or vec3). To fix that, I introduced
a new variable (output_components) containing the size of the output
type for each render target.
Unfortunately, I forgot to actually initialize it in the constructor,
which meant that unless a shader wrote to gl_FragColor, or the specific
output for each render target, output_components would contain a garbage
value, and we'd loop for a completely non-deterministic amount of time.
Not actually emitting any color writes seems like the right approach.
We may still need to emit a render target write (to terminate the
thread), but don't have to put in any sensible values (the shader didn't
write anything, after all).
Fixes a regression since 2f18698220d8b27991fab550c4721590d17278e0.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunke <firstname.lastname@example.org>
Reviewed-by: Paul Berry <email@example.com>
Tested-by: Ian Romanick <firstname.lastname@example.org>
Changing version to 8.0 - this needs to get cherry-picked, but I want to let it sit on master for a little while first to make sure it doesn't break things even worse.
*** Bug 54258 has been marked as a duplicate of this bug. ***
Backported to the 8.0 branch as commit 77e711cfca1a1e8908be7e4a744b2306094c65e0.
on Jan 20, 2017 at 11:54:49.
(provided by the Example extension).