On 07/03/2012 03:41 PM, Eric Anholt wrote:
[snip]
> 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 expre
Kenneth Graunke 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.
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
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 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 c
