[Mesa-dev] [PATCH 1/6] glsl: Optimize pow(x, 2) into x * x.

Eric Anholt eric at anholt.net
Tue Mar 11 11:27:17 PDT 2014


Erik Faye-Lund <kusmabite at gmail.com> writes:

> On Tue, Mar 11, 2014 at 2:50 PM, Erik Faye-Lund <kusmabite at gmail.com> wrote:
>> On Mon, Mar 10, 2014 at 11:54 PM, Matt Turner <mattst88 at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140311/56a8b6a7/attachment.pgp>


More information about the mesa-dev mailing list