On Thu, Mar 17, 2016 at 6:21 PM, Jason Ekstrand <ja...@jlekstrand.net> wrote:
> On Thu, Mar 17, 2016 at 6:10 PM, Matt Turner <matts...@gmail.com> wrote:
>>
>> On Thu, Mar 17, 2016 at 5:51 PM, Jason Ekstrand <ja...@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
