I first thought it was an ubuntu bug. Happened after upgrading ubuntu 12.10 to 13.4 Before filing the bug, ubuntu assembled a lot of info about the system. I cannot reproduce that here. Please see https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1234565 I now found out that with the ubuntu upgrade, mesa went from 9.0 to 9.1.4. Tested on two notebooks (old HP and new Dell). On both machines after the mesa update. Problem in short: OpenGl shading language (GLSL) uniform variables seem to stay undefined, or lose their value somewhere. Tested with a WebGl app as well as a C++ (Qt) application.
Can you provide any information about reproducing the bug? There's basically no information here or in the Ubutntu bug.
Created attachment 87352 [details] see the "!!!" comments in the code. The values of the uniforms are set in Qt-C++. E.g. "contrast" can be changed; confirmed visually when the app runs. However in the main function uniforms are/become undefined. Same problem with a similar shader in WebGL. Changing types bool to float does not help.
(In reply to comment #1) > Can you provide any information about reproducing the bug? There's > basically no information here or in the Ubutntu bug. Thanks. Sorry, I accidently added the fragment shader instead of vertex shader. See, correction below.
(In reply to comment #1) > Can you provide any information about reproducing the bug? There's > basically no information here or in the Ubutntu bug. Do you need more info, apart from shader source i attached beow?
I don't think so, I've just been really busy. Reassigning to intel-3d-bugs@lists.freedesktop.org so that other people on the team see the bug.
Created attachment 97083 [details] Minimal shader_runner test to reproduce the issue This test case reproduces the issue, and it appears to not have anything to do with the boolean flag uniform. It appears to have something to do with the way the global variables are set using the "contrast" uniform. See the WORK_AROUND bits in the test case. I haven't investigated this more in the compiler or driver.
Bisected to: commit c9e48e5b083b6cf97ecdb2d17c874ea631203b06 Author: Eric Anholt <eric@anholt.net> Date: Wed Aug 1 19:35:18 2012 -0700 i965: Generalize VS compute-to-MRF for compute-to-another-GRF, too. No statistically significant performance difference on glbenchmark 2.7 (n=60). It reduces cycles spent in the vertex shader by 3.3% +/- 0.8% (n=5), but that's only about .3% of all cycles spent according to the fixed shader_time. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Created attachment 97090 [details] Side-by-side diff of the before-and-after vertex shader assembly
Created attachment 97091 [details] Side-by-side diff of the before-and-after vertex shader assembly
This is fixed in Mesa master by following commit: --- 8< --- 72bb3f81c621931e42759148bc8bddc511266dd0 is the first bad commit commit 72bb3f81c621931e42759148bc8bddc511266dd0 Author: Matt Turner <mattst88@gmail.com> Date: Tue Sep 2 14:43:43 2014 -0700 i965/vec4: Don't iterate between blocks with inst->next/prev. The register coalescing portion of this patch hurts three shaders in Guacamelee by one instruction each, but examining the diff makes me believe that what we were generating was (perhaps harmlessly) incorrect.
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.