diff options
author | Matt Turner <[email protected]> | 2015-03-10 17:55:21 -0700 |
---|---|---|
committer | Matt Turner <[email protected]> | 2015-03-18 21:06:26 -0700 |
commit | dd0d3a2c0fb388745519c8a3be800720541eccfe (patch) | |
tree | c825d6c3580455cee47ce55610767ed2eda39bac /src/glsl/nir/nir_opcodes.py | |
parent | bb22aa08e4b08c9688c5d5c6558ac01663d0163a (diff) |
mesa: Replace _mesa_round_to_even() with _mesa_roundeven().
Eric's initial patch adding constant expression evaluation for
ir_unop_round_even used nearbyint. The open-coded _mesa_round_to_even
implementation came about without much explanation after a reviewer
asked whether nearbyint depended on the application not modifying the
rounding mode. Of course (as Eric commented) we rely on the application
not changing the rounding mode from its default (round-to-nearest) in
many other places, including the IROUND function used by
_mesa_round_to_even!
Worse, IROUND() is implemented using the trunc(x + 0.5) trick which
fails for x = nextafterf(0.5, 0.0).
Still worse, _mesa_round_to_even unexpectedly returns an int. I suspect
that could cause problems when rounding large integral values not
representable as an int in ir_constant_expression.cpp's
ir_unop_round_even evaluation. Its use of _mesa_round_to_even is clearly
broken for doubles (as noted during review).
The constant expression evaluation code for the packing built-in
functions also mistakenly assumed that _mesa_round_to_even returned a
float, as can be seen by the cast through a signed integer type to an
unsigned (since negative float -> unsigned conversions are undefined).
rint() and nearbyint() implement the round-half-to-even behavior we want
when the rounding mode is set to the default round-to-nearest. The only
difference between them is that nearbyint() raises the inexact
exception.
This patch implements _mesa_roundeven{f,}, a function similar to the
roundeven function added by a yet unimplemented technical specification
(ISO/IEC TS 18661-1:2014), with a small difference in behavior -- we
don't bother raising the inexact exception, which I don't think we care
about anyway.
At least recent Intel CPUs can quickly change a subset of the bits in
the x87 floating-point control register, but the exception mask bits are
not included. rint() does not need to change these bits, but nearbyint()
does (twice: save old, set new, and restore old) in order to raise the
inexact exception, which would incur some penalty.
Reviewed-by: Carl Worth <[email protected]>
Diffstat (limited to 'src/glsl/nir/nir_opcodes.py')
-rw-r--r-- | src/glsl/nir/nir_opcodes.py | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/glsl/nir/nir_opcodes.py b/src/glsl/nir/nir_opcodes.py index 77f3bb8266d..062cd628b8d 100644 --- a/src/glsl/nir/nir_opcodes.py +++ b/src/glsl/nir/nir_opcodes.py @@ -183,7 +183,7 @@ unop("ftrunc", tfloat, "truncf(src0)") unop("fceil", tfloat, "ceilf(src0)") unop("ffloor", tfloat, "floorf(src0)") unop("ffract", tfloat, "src0 - floorf(src0)") -unop("fround_even", tfloat, "_mesa_round_to_even(src0)") +unop("fround_even", tfloat, "_mesa_roundevenf(src0)") # Trigonometric operations. |