On Fri, Apr 25, 2014 at 6:20 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 25.04.2014 23:19, schrieb Ilia Mirkin: >> On Fri, Apr 25, 2014 at 5:02 PM, Roland Scheidegger <srol...@vmware.com> >> wrote: >>> As for the addc/subb I guess this is an area where just about everything >>> you do won't really match hw in any case. A quick glance at radeonsi >>> tells me that gcn actually _always_ sets the carry bit for normal int >>> adds/subs but does so in the VCC reg - so if you'd want to get this to a >>> "normal" register you'd have to do some other instruction (maybe >>> conditional 0/1 move based on VCC). However, gcn actually has subb/addc >>> instructions, these just do add/sub honoring that VCC bit (and again >>> still outputting VCC bit themselves). >>> But sm5 and glsl agree there - they both have addc/subb with just just 2 >>> inputs (so no carry/borrow input) but an additional "normal" overflow >>> output. Maybe this is easiest to transform into what hw will actually do >>> usually. >> >> I was hoping to not have to deal with carry/borrow at the TGSI level >> at all and just have the GLSL lower to ADD + USLT or so, and then for >> hw capable of dealing with it (not nvc0, or at least the blob driver >> doesn't make use of a mechanism that'd enable it), having a peephole >> opt that converts the USLT to a "recover whereever the flag is at". > I guess an explicit carry instruction makes it somewhat more obvious > this really came from an addc. Not sure if that really matters, though.
Does it really matter where it came from? What if I had the following in glsl: uvec4 a, b, c, d; a = c + d; b = lessThan(a, c); (that should be equivalent to a = uaddCarry(c, d, b) ) Why not rewrite that as ADDC in the backend. I figure if you're going to have to do an optimization down the line _anyways_ to get the benefit, might as well use existing instructions that make sense and can occur naturally in the instruction stream. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev