On 4 October 2011 23:55, Kenneth Graunke <kenn...@whitecape.org> wrote:
> On 10/03/2011 03:41 PM, Eric Anholt wrote: > > The condmod instruction ends up generating garbage condition codes, > > because apparently the comparison happens on the accumulator value (33 > > bits for UD), not the truncated value that would be written. > > > > Fixes fs-op-neg-* > > I am uneasy about these two patches for a number of reasons. > > 1. fs-op-neg-* and vs-op-neg-* fail on AMD (Catalyst 11.7), > which makes me wonder if the tests are correct. > > AMD does the expected behavior if you change the line: > uint result = (- arg0); > to this: > uint result = uint(-int(arg0)); > or this: > uint result = 0 - arg0; > > While the GLSL spec isn't terribly clear about how unary negate works on > unsigned, the fact -arg0 != 0 - arg0 seems horrendously broken. So > maybe AMD's driver is just buggy. > > 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 :)
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
