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

[Jason Ekstrand]

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?

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.
--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160317/8fe896bc/attachment-0001.html>