[Mesa-dev] [PATCH] mesa/glsl: add ir_unop_round

[Eric Anholt]

Kenneth Graunke <kenneth at whitecape.org> writes:

> On 07/03/2012 09:00 AM, Brian Paul wrote:
>> The GLSL round() and roundEven() functions were both generating the
>> ir_unop_round_even instruction but the GLSL spec allows some leeway for
>> implementing round().  This change allows drivers to take advantage of
>> that.  For i965, they still equate to the same thing.
>> 
>> v2: implement ir_unop_round for constant expressions.
> [snip]
>> +   case ir_unop_round:
>> +      assert(op[0]->type->base_type == GLSL_TYPE_FLOAT);
>> +      for (unsigned c = 0; c < op[0]->type->components(); c++) {
>> +	 data.f[c] = roundf(op[0]->value.f[c]);
>> +      }
>> +      break;
>
> This really has the same problem: ir_unop_round now has two different
> meanings.  On the CPU, you've chosen to make it round away from zero.
> On i965, it rounds toward the nearest even number.  On other drivers, it
> does...something...
>
> The real constraint is that it needs to be consistent on both the CPU
> (constants) and GPU (non-constants).  The only way I see to solve this
> is to have drivers set a flag indicating how they'd like round to
> behave, and to check that in the constant expression evaluation code.

I can't find spec text explicitly justifying it, but I was quite sure
that we have total leeway to be inconsistent between constant expression
handling (CPU) and variable expression handling -- you just need to be
invariant in constant expression handling between shader targets, not
between a constant expression and a variable expression operating on the
same values.

Otherwise, we don't get to use sinf and friends in
ir_constant_expression.cpp.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120703/4d0a15db/attachment.pgp>