On 4 October 2011 23:55, Kenneth Graunke <span dir="ltr"><<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im">On 10/03/2011 03:41 PM, Eric Anholt wrote:<br> </div><div class="im">> The condmod instruction ends up generating garbage condition codes,<br> > because apparently the comparison happens on the accumulator value (33<br> > bits for UD), not the truncated value that would be written.<br> ><br> > Fixes fs-op-neg-*<br> <br> </div>I am uneasy about these two patches for a number of reasons.<br> <br> 1. fs-op-neg-* and vs-op-neg-* fail on AMD (Catalyst 11.7),<br> which makes me wonder if the tests are correct.<br> <br> AMD does the expected behavior if you change the line:<br> uint result = (- arg0);<br> to this:<br> uint result = uint(-int(arg0));<br> or this:<br> uint result = 0 - arg0;<br> <br> While the GLSL spec isn't terribly clear about how unary negate works on<br> unsigned, the fact -arg0 != 0 - arg0 seems horrendously broken. So<br> maybe AMD's driver is just buggy.<br> <br></blockquote><div><br>I personally fall mostly on the "AMD's driver is just buggy" side of this argument. My reasoning is based on this text from the GLSL 1.30 spec (section 4.1.3 "Integers"): "Operations resulting in overflow or underflow will not cause any exception, nor will they saturate, rather they will “wrap” to yield the low-order 32 bits of the result." So even though -1 is not representable in a uint, it seems reasonable to me that it should "wrap" to binary 11111111..., and so on. But I admit we are in fairly dodgy territory here, trying to negate unsigned values :)<br> </div></div>