[Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf

[Erik Faye-Lund]

On Tue, 2018-11-13 at 09:00 -0800, Dylan Baker wrote:
> Quoting Erik Faye-Lund (2018-11-13 01:34:53)
> > On Mon, 2018-11-12 at 09:22 -0800, Dylan Baker wrote:
> > > Quoting Erik Faye-Lund (2018-11-12 04:51:47)
> > > > On Fri, 2018-11-09 at 10:40 -0800, Dylan Baker wrote:
> > > > > Which has the same behavior.
> > > > 
> > > > Does it? I'm not so sure... IROUND_POS seems to round to
> > > > nearest
> > > > integer depending on the FPU rounding mode, _mesa_roundevenf
> > > > rounds
> > > > to
> > > > the nearest *even* value regardless of the FPU rounding mode,
> > > > no?
> > > > 
> > > > I'm not sure if it matters or not, but *at least* point that
> > > > out in
> > > > the
> > > > commit message. Unless I'm missing something, of course...
> > > 
> > > I should put it in the commit message, but there is a comment in
> > > rounding.h that
> > > if you change the rounding mode you get to keep the pieces.
> > 
> > Well, this might regress performance pretty badly. Especially in
> > the
> > swrast code, this could be bad...
> > 
> 
> Why? we have the assumption that you don't change the rounding mode
> already in
> core mesa and many of the drivers.

Because we'd end up calling rintf, which I suspected had to update
errno, like many CRT math functions require. But looking a the POSIX
spec, it seems this isn't the case, so this change looks fine to me.
Sorry for the noise.

Anyway, regardless of your change, perhaps we should consider adding
something like "assert(fegetround() == FE_TONEAREST)" to validate the
assumption?

> For performance, I measured a simple 1000 loops of rounding, and
> found that the
> only way the rounding.h function was slower is if you used the
> __SSE4_1__
> path... (It was the same performance as the int cast +0.5
> implementation)

Nice :)