Erik Faye-Lund <kusmab...@gmail.com> writes:

> On Tue, Mar 11, 2014 at 2:50 PM, Erik Faye-Lund <kusmab...@gmail.com> wrote:
>> On Mon, Mar 10, 2014 at 11:54 PM, Matt Turner <matts...@gmail.com> wrote:
>>> Cuts two instructions out of SynMark's Gl32VSInstancing benchmark.
>>> ---
>>>  src/glsl/opt_algebraic.cpp | 8 ++++++++
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
>>> index 5c49a78..8494bd9 100644
>>> --- a/src/glsl/opt_algebraic.cpp
>>> +++ b/src/glsl/opt_algebraic.cpp
>>> @@ -528,6 +528,14 @@ ir_algebraic_visitor::handle_expression(ir_expression 
>>> *ir)
>>>        if (is_vec_two(op_const[0]))
>>>           return expr(ir_unop_exp2, ir->operands[1]);
>>>
>>> +      if (is_vec_two(op_const[1])) {
>>> +         ir_variable *x = new(ir) ir_variable(ir->operands[1]->type, "x",
>>> +                                              ir_var_temporary);
>>> +         base_ir->insert_before(x);
>>> +         base_ir->insert_before(assign(x, ir->operands[0]));
>>> +         return mul(x, x);
>>> +      }
>>> +
>>
>> Is this safe? Since many GPUs implement pow(x, y) as exp2(log2(x) *
>> y), this will give different results for if y comes from a uniform vs
>> if it's a constant, no?

Yes, but that wouldn't be covered by the "invariant" keyword.

> To be a bit more clear: I don't think this is valid for expressions
> writing to variables marked as invariant (or expressions taking part
> in the calculations that leads up to invariant variable writes).
>
> I can't find anything allowing variance like this in the invariance
> section of the GLSL 3.30 specifications. In particular, the list
> following "To guarantee invariance of a particular output variable
> across two programs, the following must also be true" doesn't seem to
> require the values to be passed from the same source, only that the
> same values are passed. And in this case, the value 2.0 is usually
> exactly representable no matter what path it took there.
>
> Perhaps I'm being a bit too pedantic here, though.

This file would do the same thing on the same expression tree in two
different programs, so "invariant" is fine (we've probably got other
problems with invariant, though).  The keyword you're probably thinking
of is "precise", which isn't in GLSL we implement yet.

Attachment: pgpEqUhBo44bs.pgp
Description: PGP signature

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to