On Fre, 2013-05-03 at 02:00 +0200, Roland Scheidegger wrote: > Am 03.05.2013 00:29, schrieb Dave Airlie: > > On Fri, May 3, 2013 at 6:04 AM, Zack Rusin <za...@vmware.com> wrote: > >>> Well in contrast to the IF/UIF they'd be really redundant unless I'm > >>> missing something so just for supporting negation on inputs or not this > >>> looks like not really worth it (and as said there are also other signed > >>> instructions where supporting negation doesn't really make sense). OTOH > >>> you're right it would be just 3 more instructions (imul/iadd/imad) I > >>> believe so it wouldn't be too bad. But I'm fine with just supporting > >>> negation on unsigned instructions, after all it's just two's complement > >>> negation regardless if it's signed or not. And just document these umul > >>> functions work for both signed and unsigned. > >> > >> k, I'll just push that last patch then. If someone won't like it or we'll > >> decide to do it in some other way we can always redo it later. For now > >> this will be enough to fix the umad handling. > >> > > > > I don't like this, sorry for being slow :-) > > > > Mainly because I don't think any hw has the ability to apply negate on > > non-float instructions (at least radeon doesn't), and I'd like gallium > > to be an interface that reflects the hw. > > > > Granted the hw also doesn't have IMAD/UMAD was have to decompose those > > anyways. > > Well we already said before that negation (but not abs) was supported on > signed inputs, this changes it to just say it's also supported on > unsigned ones, but that's really just because uadd/umul/umad are > ignorant of signedness. > Sorry to hear the hw doesn't support it, but this is supported by d3d10 > so it's quite likely some hw indeed supports it. There's always some > things some hw can't do natively. > I'd be fine to just restrict it to some opcodes, e.g. exclude logic ops > if that helps you.
FWIW, I don't think modifiers make sense for logic ops, as they just operate on individual bits of the operands, regardless of any particular encoding of the whole operands. > Note that tgsi (and d3d10 for that matter) also for instance don't > have a integer SUB opcode, so the natural way for encoding that would > of course just be with a ADD with negate modifier on second arg, and I > bet your hw could do that one. I agree it shouldn't matter that much how this is expressed in TGSI. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
