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

[Kenneth Graunke]

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.