[Mesa-dev] [PATCH 1/2] gallivm: allow negation of all integer types

[Michel Dänzer]

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 <zackr at 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