[Mesa-dev] [PATCH 1/3] glsl: Add support for constant expression evaluation on round(), roundEven().

[Eric Anholt]

t
-------------- next part --------------
On Tue, 04 Oct 2011 23:58:27 -0700, Kenneth Graunke <kenneth at whitecape.org> wrote:
> On 10/04/2011 01:23 PM, Eric Anholt wrote:
> > On Tue, 4 Oct 2011 04:42:55 +0200, Henri Verbeet <hverbeet at gmail.com> wrote:
> >> On 4 October 2011 00:41, Eric Anholt <eric at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20111005/f53772a2/attachment.pgp>