<div dir="ltr"><div><div>Matt,<br><br></div>  You haven't replied to my mail with an updated shader test that shows the math instructions alone causing trouble.<br></div>Do you now agree that my patch avoiding math instructions in opt_set_dependency_control is the appropriate fix?<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 21, 2014 at 11:30 AM, Mike Stroyan <span dir="ltr"><<a href="mailto:mike@lunarg.com" target="_blank">mike@lunarg.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Matt,<br><br></div>  I still see the math instructions as the troublemakers.  The NoDDChk bit is about write hazards and should not disable checking for read hazards.<br>
<br></div>  Here is a slightly changed shader test that avoids using NoDDChk on the instruction that consumes the result of the 'math exp' instructions.  The only difference between the shaders when applying my patch is the presence of NoDDChk and NoDDClr on the math instructions.  And the z channel still gets almost always incorrect results when NoDDChk is used.<br>

</div><div><br></div></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Thu, Feb 20, 2014 at 7:52 PM, Matt Turner <span dir="ltr"><<a href="mailto:mattst88@gmail.com" target="_blank">mattst88@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Thu, Feb 20, 2014 at 4:55 PM, Mike Stroyan <<a href="mailto:mike@lunarg.com" target="_blank">mike@lunarg.com</a>> wrote:<br>


> Ian,<br>
><br>
>   Here is a shader_test version.  It lacks the sparkling uncertainty of the<br>
> pixel values in the previous animated example program.<br>
> It just gets all vertices uniformly wrong when I run it.<br>
<br>
</div>Thanks for the test Mike. I reproduced it locally.<br>
<br>
Comparing the vertex shader assembly before and after your patch, I<br>
get the attached diff.<br>
<br>
The good news is that it doesn't look like the math instructions'<br>
dependency control flags are broken. The bad news is that our<br>
dependency control optimization has a bug. :)<br>
<br>
After three math exp instructions write to g8.{x,y,z}, we mov.sat<br>
g8.xyz into g116.xyz which we use as a message register. The problem<br>
is that we wrote a 1.0 into g116.w before the exp instructions, and<br>
the dependency control optimization code recognized that the write to<br>
g116.xyz would stall waiting for the write to g116.w and marked the<br>
instructions with NoDDClr/NoDDChk. Unfortunately, marking the write to<br>
g116.xyz with NoDDChk means that the instruction doesn't wait on the<br>
writes to g8 to complete either!<br>
</blockquote></div><br><br clear="all"><br></div></div><div class="">-- <br><br> Mike Stroyan - Software Architect<br> LunarG, Inc.  - The Graphics Experts<br> Cell:  <a href="tel:%28970%29%20219-7905" value="+19702197905" target="_blank">(970) 219-7905</a><br>
 Email: Mike@LunarG.com<br> Website: <a href="http://www.lunarg.com" target="_blank">http://www.lunarg.com</a>
</div></div>
</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>