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

[Brian Paul]

On 07/03/2012 01:43 PM, Kenneth Graunke wrote:
> 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...

I think that's OK.  The GLSL spec says for round():

      Returns a value equal to the nearest integer to x. The
      fraction 0.5 will round in a direction chosen by the
      implementation, presumably the direction that is fastest.
      This includes the possibility that round(x) returns the
      same value as roundEven(x) for all values of x.

It doesn't say the results have to be consistant all the time. 
Consider different VS and FS implementations (HW vs SW) that give 
different results - I think that's acceptable.

If someone really cares about how rounding is done, he should use 
roundEven() or some variation on ceil() or trunc().

And as I said before, I bet sin(x), cos(x), etc. will give somewhat 
different results for CPU vs GPU implementations.  Even simple 
division could give different results.  I don't think it's realistic 
to require identical results for CPU vs. GPU in all cases.


> The real constraint is that it needs to be consistent on both the CPU
> (constants) and GPU (non-constants).

I think that's the crux here and I don't think that's required.


> 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.
>
> Or, just pick one meaning and make everybody do that.

-Brian