On 10/04/2011 01:23 PM, Eric Anholt wrote: > On Tue, 4 Oct 2011 04:42:55 +0200, Henri Verbeet <hverb...@gmail.com> wrote: >> On 4 October 2011 00:41, Eric Anholt <e...@anholt.net> wrote: >>> They're both implemented the same in GLSL IR (since round() has >>> undefined behavior for n + 0.5). The specification of the C function >>> in use here is a bit unclear: rint(3) says that nearbyint() is like >>> rint() in that it uses the current rounding direction from >>> fesetround(3). fesetround(3) says behavior is according to >>> FLT_ROUNDS, which on this system is 1 ("Rounding is toward nearest >>> number"), but doesn't specify behavior for n + 0.5 in that case. >>> However, round(3) says that rint(3) has roundEven()'s behavior for n + >>> 0.5. >>> >> Does this depend on applications not touching the rounding mode? > > Yeah, just like our existing IROUND calls used in glGet, glDrawPixels, > and more, as far as I can see.
That might be worth fixing. I think this case is probably worth fixing. However, if you think it's symptomatic of a larger issue, perhaps just file a bug and come back to it. After all, failing to support constant expressions involving round/roundEven at all is a lot worse than rounding in the wrong direction in a few cases. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev