> iand and ior are commutative, so you don't need both.
--Wait, woaaah, the algebraic generator respects that? Super neat, thank
you!
> Especially without instruction count data
(I'm assuming I won't be able to do shader-db on my hw at this point..)
> For example, if the only use of inot(...som
> We can support all of these with source modifiers because the above three
> aren't really "dest invertable"... For us, they'd be
>
> ~src0 | ~src1
> ~src0 & ~src1
> ~src0 ^ ~src1
>
> Is it really dest_invertable or both_srcs_invertable? :-)
Sure, I wasn't sure how other drivers would want to
On 4/25/19 3:37 PM, Alyssa Rosenzweig wrote:
> In addition to the familiar iand/ior/ixor, some architectures feature
> destination-inverted versions inand/inor/inxor. Certain
> architectures also have source-inverted forms, dubbed iandnot/iornot
> here. Midgard has the all of these opcodes natively
On Thu, Apr 25, 2019 at 5:37 PM Alyssa Rosenzweig
wrote:
> In addition to the familiar iand/ior/ixor, some architectures feature
> destination-inverted versions inand/inor/inxor. Certain
> architectures also have source-inverted forms, dubbed iandnot/iornot
> here. Midgard has the all of these op
On Thu, Apr 25, 2019 at 3:37 PM Alyssa Rosenzweig wrote:
>
> In addition to the familiar iand/ior/ixor, some architectures feature
> destination-inverted versions inand/inor/inxor. Certain
> architectures also have source-inverted forms, dubbed iandnot/iornot
> here. Midgard has the all of these o
In addition to the familiar iand/ior/ixor, some architectures feature
destination-inverted versions inand/inor/inxor. Certain
architectures also have source-inverted forms, dubbed iandnot/iornot
here. Midgard has the all of these opcodes natively. Many arches have
comparible features to implement s
