[Mesa-dev] [PATCH 01/12] nir: Add an "exact" bit to nir_alu_instr

[Matt Turner]

On Thu, Mar 17, 2016 at 6:21 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
> On Thu, Mar 17, 2016 at 6:10 PM, Matt Turner <mattst88 at gmail.com> wrote:
>>
>> On Thu, Mar 17, 2016 at 5:51 PM, Jason Ekstrand <jason at jlekstrand.net>
>> wrote:
>> > ---
>> >  src/compiler/nir/nir.h       | 11 +++++++++++
>> >  src/compiler/nir/nir_clone.c |  1 +
>> >  src/compiler/nir/nir_print.c |  2 ++
>> >  3 files changed, 14 insertions(+)
>> >
>> > diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
>> > index 34f31eb..94b981b 100644
>> > --- a/src/compiler/nir/nir.h
>> > +++ b/src/compiler/nir/nir.h
>> > @@ -671,6 +671,17 @@ extern const nir_op_info
>> > nir_op_infos[nir_num_opcodes];
>> >  typedef struct nir_alu_instr {
>> >     nir_instr instr;
>> >     nir_op op;
>> > +
>> > +   /** Indicates that this ALU instruction generates an exact value
>> > +    *
>> > +    * This is kind-of a mixture of GLSL "precise" and "invariant" and
>> > not
>>
>> "kind of" isn't hyphenated.
>
>
> Thanks
>
>>
>> > +    * really equivalent to either.  This indicates that the value
>> > generated by
>> > +    * this operation is high-precision and any code transformations
>> > that touch
>> > +    * it must ensure that the resulting value is bit-for-bit identical
>> > to the
>> > +    * original.
>>
>> I think this is a lot of the problem -- we don't seem to have a good
>> idea of what these keywords mean, concretely.
>>
>> Precise is more clear to me: don't optimize things in such a way as to
>> change the result.
>>
>> Invariant is much less clear to me though. I've read the GLSL spec of
>> course, but can someone give me an example?
>
>
> The best docs I've found are in the ES 3.2 spec.  Basically it means that
> you're allowed to optimize it in an imprecise way as long as you always
> optimize the computation exactly the same way.  One of the places this gets
> us in trouble is in the fma peephole where we decide whether to fuse a
> mul+add or not based on how many users the add has and if they're all mul.
> This means that if we have a mul+add in an invariant expression and another,
> unrelated, user of the mul, it won't get fused.  If you dead-code the other
> unrelated user of the mul, things change and we fuse them.  This is the kind
> of thing that's not allowed.  Does that make more sense?

Yes, thank you. That's a very good example.

I'll take a look at the ESSL 3.2 spec.

> Unfortunately, invariant is horrifically difficult to think about.  It's
> much easier to just implement it as precise which is also a valid way to do
> it.

Yeah.