Kenneth Graunke <kenn...@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.
pgpZPO0VsjtEJ.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
