t
On Tue, 04 Oct 2011 23:58:27 -0700, Kenneth Graunke <kenn...@whitecape.org>
wrote:
> 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.Yeah, I'd rather deal with rounding-in-general separately later, than worry about it right now.
pgpbq6S9EkU1x.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
