<div dir="ltr"><div><div><div><div><div><div><div><div>Ken,<br><br></div>  The defect depends on details of the shader compiler reusing registers.<br></div>Old register values are sometimes left in some channels when the write-after-write hints are used.<br>
</div>Further reducing the GLSL test case would be tricky because the reuse of g8 would be likely to be changed.<br></div>I did already spend quite a long time reducing a larger shader to this relatively small example.<br>
</div>The GLSL is not anyone's source code.  It results from at least two levels of machine translation and my own rewrite.<br><br></div>The difference in the resulting native code is now very simple.<br></div>The only difference from my patch is the presence of NoDDClr and NoDDChk hints on the three math opcodes.<br>
</div><div>The results are then used by an opcode without any NoDDChk hinting.<br></div>With math data dependency hints in place the results are often incorrect.  They clearly don't work reliably.<br><div><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)          g81<1>F         g7<4,4,1>.yF    1e-08F          { align16 WE_normal 1Q };<br>0x00000590: math exp(8)     g8<1>.yF        g81<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>
   (assign  (xyz) (var_ref gl_FrontColor)  (expression vec3 * (swiz xyz (var_ref R_2) )(constant vec3 (0.999999 0.999999 0.999999)) ) ) <br>0x000005b0: mul(8)          g4<1>.xyzF      g8<4,4,1>.xyzzF 0.999999F       { align16 WE_normal 1Q };<br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 18, 2014 at 4:05 PM, Kenneth Graunke <span dir="ltr"><<a href="mailto:kenneth@whitecape.org" target="_blank">kenneth@whitecape.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 02/28/2014 02:35 PM, Mike Stroyan wrote:<br>
> Matt,<br>
><br>
>   You haven't replied to my mail with an updated shader test that shows<br>
> the math instructions alone causing trouble.<br>
<br>
</div>I don't think Matt has time to do that.  Could you please trim down your<br>
shader test to a smaller case which demonstrates the problem?  As is,<br>
it's pretty large.  It also looks like it was ripped directly out of<br>
someone's application, which makes us nervous about copyright infringement.<br>
<div class=""><br>
> Do you now agree that my patch avoiding math instructions in<br>
> opt_set_dependency_control is the appropriate fix?<br>
<br>
</div>I see no documentation indicating that there are bugs with dependency<br>
control and math instructions.  I also don't see any workarounds for<br>
that in the Windows driver.<br>
<br>
--Ken<br>
<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>