mesa: Fix bug in unclamped float to ubyte conversion.
authorManfred Ernst <ernstm@chromium.org>
Thu, 13 Jun 2013 03:03:02 +0000 (20:03 -0700)
committerStéphane Marchesin <marcheu@chromium.org>
Thu, 13 Jun 2013 03:24:48 +0000 (20:24 -0700)
commitbf2c074a2fb122bafbbe0f3c7978b89685f2698b
treea6be04e9ebc0ec3fbdc71697d7d9c3af4dfd5830
parent3475b2213381cdbda7a620d4c0c7708f6969f489
mesa: Fix bug in unclamped float to ubyte conversion.

Problem: The IEEE float optimized version of UNCLAMPED_FLOAT_TO_UBYTE
in macros.h computed incorrect results for inputs in the range
0x3f7f0000 (=0.99609375) to 0x3f7f7f80 (=0.99803924560546875)
inclusive.  0x3f7f7f80 is the IEEE float value that results in 254.5
when multiplied by 255.  With rounding mode "round to closest even
integer", this is the largest float in the range 0.0-1.0 that is
converted to 254 by the generic implementation of
UNCLAMPED_FLOAT_TO_UBYTE.  The IEEE float optimized version
incorrectly defined the cut-off for mapping to 255 as 0x3f7f0000
(=255.0/256.0). The same bug was present in the function
float_to_ubyte in u_math.h.

Fix: The proposed fix replaces the incorrect cut-off value by
0x3f800000, which is the IEEE float representation of 1.0f. 0x3f7f7f81
(or any value in between) would also work, but 1.0f is probably
cleaner.

The patch does not regress piglit on llvmpipe and on i965 on sandy
bridge.

Tested-by Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
src/gallium/auxiliary/util/u_math.h
src/mesa/main/macros.h