On Tue, Mar 11, 2014 at 7:27 PM, Eric Anholt <e...@anholt.net> wrote: > 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.
Are you saying that this only rewrites "x = pow(y, 2.0)" and not "const float e = 2.0; x = pow(y, e);"? If so, my point is moot, indeed. But if that's *not* the case, then I think we're in trouble still. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev