<div dir="ltr"><div><div><div>Reviewed-by: Mike Stroyan <<a href="mailto:mike@lunarg.com" target="_blank">mike@lunarg.com</a>> </div>That does show the math dependency problem. </div>The same problem can also be demonstrated with other math opcodes than exp2. </div> </div><div class="gmail_extra"> <div class="gmail_quote">On Mon, Mar 31, 2014 at 5:21 PM, Matt Turner <<a href="mailto:mattst88@gmail.com" target="_blank">mattst88@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">--- tests/shaders/dependency-hints/exp2.shader_test | 72 +++++++++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 tests/shaders/dependency-hints/exp2.shader_test diff --git a/tests/shaders/dependency-hints/exp2.shader_test b/tests/shaders/dependency-hints/exp2.shader_test new file mode 100644 index 0000000..c7584e6 --- /dev/null +++ b/tests/shaders/dependency-hints/exp2.shader_test @@ -0,0 +1,72 @@ +[require] +GLSL >= 1.10 + +[vertex shader] +/* On Sandybridge and newer chips in the i965 family, writes into separate + * channels of the same register stall. The compiler marks independent writes + * with NoDDClr and/or NoDDChk to allow the instructions to issue without + * stalling. + * + * Empirically, marking "math" instructions with these dependency control + * hints leads to broken dependency tracking. The following shader, compiled + * with the i965/vec4 backend unaware of this fact generates the following + * assembly: + * + * math exp(8) g3<1>.xF g1<0,4,1>.xF null { align16 WE_normal NoDDClr 1Q }; + * add(8) g7<1>F g1<0,4,1>.yF 1e-08F { align16 WE_normal 1Q }; + * math exp(8) g3<1>.yF g7<4,4,1>F null { align16 WE_normal NoDDClr,NoDDChk 1Q }; + * math exp(8) g3<1>.zF g1<0,4,1>.zF null { align16 WE_normal NoDDChk 1Q }; + * mul.sat(8) g116<1>.xyzF g3<4,4,1>.xyzzF 0.5F { align16 WE_normal NoDDClr 1Q }; + * mov.sat(8) g116<1>.wF 1F { align16 WE_normal NoDDChk 1Q }; + * mov(8) g114<1>D 0D { align16 WE_normal 1Q }; + * mov(8) g115<1>F g2<4,4,1>F { align16 WE_normal 1Q }; + * mov(8) g113<1>UD g0<4,4,1>UD { align16 WE_all 1Q }; + * or(1) g113.5<1>UD g0.5<0,1,0>UD 0x0000ff00UD { align1 WE_all }; + * send(8) null g113<4,4,1>F + * urb 0 urb_write used complete mlen 5 rlen 0 { align16 WE_normal 1Q EOT }; + * + * The shader calculates the color exp2(vec3(0.1, 0.2 + 0.00000001, 0.3)) * 0.5 + * and expects to read back (0.535886, 0.5743491, 0.6155722). + * + * On affected platforms, the .x and .y components are correctly calculated, + * but .z is left to be 0.0. + */ + +uniform vec3 exp; + +void main(){ + gl_Position = gl_Vertex; + + /* Calling exp2() on a single component swizzle and then picking a single + * channel from its result works around the vec4 backend's inability to + * properly register coalesce. + */ + gl_FrontColor.x = exp2(exp.xxxx).x; + + /* Adding 0.00000001 is essentially a no-op, but it prevents the GLSL + * compiler's opt_vectorize pass from combining the three exp2() calls + * into a single one. + */ + gl_FrontColor.y = exp2(exp.yyyy + 0.00000001).y; + + gl_FrontColor.z = exp2(exp.zzzz).z; + + /* Scale the result back into the 0.0 to 1.0 range */ + gl_FrontColor.xyz *= 0.5; + + /* Moving this assignment before the previous statement causes the test + * to sporadically fail, returning 1.0 (unrelated to value stored in .w) + * in all channels. + */ + gl_FrontColor.w = 1.0; +} + +[fragment shader] +void main() { + gl_FragColor = gl_Color; +} + +[test] +uniform vec3 exp 0.1 0.2 0.3 +draw rect -1 -1 2 2 +probe rgb 1 1 0.535886 0.5743491 0.6155722 -- 1.8.3.2 _______________________________________________ Piglit mailing list <a href="mailto:Piglit@lists.freedesktop.org">Piglit@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/piglit" target="_blank">http://lists.freedesktop.org/mailman/listinfo/piglit</a> </blockquote></div> -- Mike Stroyan - Software Architect LunarG, Inc. - The Graphics Experts Cell: (970) 219-7905 Email: Mike@LunarG.com Website: <a href="http://www.lunarg.com">http://www.lunarg.com</a> </div>