<div dir="ltr"><div><div><div>I apologize for the delay.  It took a while to distill the test case down to something I could share.<br><br>Here is an example program that demonstrates the problem.  It is a variation of a demos/src/glsl test.<br>
</div></div>This shows the problem in the rendered color of the 'z' or 'b' channel from this series of operations.<br>R[2].x = exp2(R[1].xxxx).x;<br>R[2].y = exp2(R[1].yyyy + 0.00000001).y; <br>   R[2].z = exp2(R[1].zzzz).z;<br>
</div>They turn into these instructions.<br><br>   (assign  (x) (var_ref R_2)  (swiz x (expression vec4 exp2 (swiz xxxx (var_ref R_1) )) ))<br>0x00000570: math exp(8)     g8<1>.xF        g7<4,4,1>.xF    null            { align16 WE_normal NoDDClr 1Q };<br>
(assign  (y) (var_ref R_2)  (swiz y (expression vec4 exp2 (expression vec4 + (swiz yyyy (var_ref R_1) )(constant float (0x1.5798eep-27)) ) ) ))<br>0x00000580: add(8)          g80<1>F         g7<4,4,1>.yF    1e-08F          { align16 WE_normal 1Q };<br>
0x00000590: math exp(8)     g8<1>.yF        g80<4,4,1>F     null            { align16 WE_normal NoDDClr,NoDDChk 1Q };<br>(assign  (z) (var_ref R_2)  (swiz z (expression vec4 exp2 (swiz zzzz (var_ref R_1) )) ))<br>
0x000005a0: math exp(8)     g8<1>.zF        g7<4,4,1>.zF    null            { align16 WE_normal NoDDChk 1Q };
<br><br><div>The z channel assignment usually results in 1.0 instead of a correct value near 0.0.<br></div><div>That results in drawing an almost blue grid with a few correct values close to black.<br>The results vary from frame to frame with the same inputs.  (Use 'a','z','Z' keys to step between frames.)<br>
</div><div>I suspect that the channel mask for math writes is not implemented cleanly.<br>The bad value for the z channel may come from the previous value being preserved by one of the other two 'math exp' instructions.<br>
</div><div>(I had to tweak the expression for the y channel to prevent vectorization from commit 4bd6e0d from hiding the problem by using a single math instruction instead of three.)<br><br></div><div>The PRM doesn't say that math instructions mess up with data dependency hinting.<br>
</div><div>But the silicon says that they do.<br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 18, 2014 at 2:08 PM, Eric Anholt <span dir="ltr"><<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><a href="mailto:mike@lunarg.com">mike@lunarg.com</a> writes:<br>
<br>
> From: Mike Stroyan <mike@LunarG.com><br>
><br>
>   Putting NoDDClr and NoDDChk dependency control on instruction<br>
> sequences that include math opcodes can cause corruption of channels.<br>
> Treat math opcodes like send opcodes and suppress dependency hinting.<br>
><br>
> Signed-off-by: Mike Stroyan <mike@LunarG.com><br>
> Tested-by: Tony Bertapelli <<a href="mailto:anthony.p.bertapelli@intel.com">anthony.p.bertapelli@intel.com</a>><br>
<br>
</div>I think we need a testcase for this and some sort of explanation of<br>
what's going on.  Why is math special?<br>
</blockquote></div><br><br clear="all"><br>-- <br><br> Mike Stroyan - Software Architect<br> LunarG, Inc.  - The Graphics Experts<br> Cell:  (970) 219-7905<br> Email: Mike@LunarG.com<br> Website: <a href="http://www.lunarg.com">http://www.lunarg.com</a>
</div>