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

[Roland Scheidegger]

Am 12.03.2015 um 23:53 schrieb Carl Worth:
> 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.
> 
>> Maybe I should send a patch to the Linux man-pages project too.
> 
> That definitely wouldn't hurt.
> 
>>>         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.
> 
>> Also it requires adding code for MSVC since it doesn't have
>> fegetround().
> 
> Not code, no. I'd be happy with just the #ifndef to hide the call from
> MSVC. I won't ask you find equivalent functionality for MSVC.
> 


Honestly I'm not sure it makes all that much sense to have an assert
here. Because imho such things should be reserved to detect internal
inconsistencies, but obviously this is something mesa has absolutely no
control of. The caller gets what it called for. I don't think other
system libraries would assert if you'd call them with non-standard
rounding modes. Plus app developers probably wouldn't notice anyway.
Reporting through some debug mechanism would probably make more sense if
anything, but just ignoring it is fine by me too - there's tons of other
calculations done in mesa in other places which will return different
results based on rounding modes.

Roland