[Mesa-dev] [PATCH 1/3] mesa: Replace _mesa_round_to_even() with _mesa_roundeven().

[Matt Turner]

On Thu, Mar 12, 2015 at 3:53 PM, Carl Worth <cworth at cworth.org> wrote:
> On Thu, Mar 12 2015, Matt Turner wrote:
>> I think you misread. rint() *does* provide the behavior we want
>> (round-to-nearest, half to even) when the rounding mode is the default
>> round-to-nearest.
>
> Thanks. I did at least verify that behaviorally as I just mentioned in a
> separate mail.
>
>> As Eric noted in his original patch, the man pages for
>> rint(3)/nearbyint(3) don't describe the half-to-even behavior but
>> round(3) does:
>
> Ah. Yes, I was using the man pages, so that was the source of my
> confusion.

I did some more research. The draft C99 spec I have doesn't say
anything about how rint/nearbyint should round halfway cases. Its
description of the round() functions is explicit though: "rounding
halfway cases away from zero".

I think this is because it's not C that specifies how rint/nearbyint
should round halfway cases -- it's IEEE-754 that says round to nearest
(and halfway cases go to even). Maybe if you're on a VAX these
functions round halfway cases differently. :)

But round() is explicitly defined by the language itself to round
halfway cases in a particular way, which explains the text in
round(3).

>> Maybe I should send a patch to the Linux man-pages project too.
>
> That definitely wouldn't hurt.

Done!

>>>         assert (fegetround() == FE_TONEAREST);
>>
>> I don't really want to do this. We rely on the default rounding mode
>> everywhere. I don't think asserting here is useful.
>
> What's useful is increasing the likelihood that when somebody does
> violate the assumption, they are alterted to the issue, rather than
> having Mesa quietly misbehave in hard-to-predict ways.
>
> It seems obvious to me that we should improve robustness when we've
> already identified exactly where (at least one piece) of fragility lies
> in Mesa.

I don't really know that it is fragile. Though the GL spec doesn't say
anything on the matter, I can't really imagine that libGL is expected
to operate identically under different rounding modes.

I certainly wouldn't expect that from other system libraries -- cairo
for instance.

This seems like an intractable problem short of saving and restoring
the rounding mode in each GL entry point. (Not a real suggestion :)