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

[Erik Faye-Lund]

On Tue, 2018-11-13 at 22:13 +0000, Roland Scheidegger wrote:
> Am 13.11.18 um 18:00 schrieb Dylan Baker:
> > 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.
> > 
> > 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)
> FWIW I'm not entirely sure it's useful to have a sse41 implementation
> -
> since all sse2 capable cpus can natively do rintf. Although maybe it
> should be pointed out that the sse41 implementation will use a
> defined
> rounding mode, whereas rintf will use current rounding mode. But I
> don't
> think anyone ever cares for the results if a different rounding mode
> would be set. Although of course rint and its variant do not actually
> guarantee the even part of it (but well if it's a sse41 capable box
> we
> pretty much know it would do just that anyway)...

According to POSIX, this is actually guaranteed:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/rint.html

"If the current rounding mode rounds towards nearest, then rint()
differs from round in that halfway cases are rounded to even rather
than away from zero."

>  (And technically
> nearbyintf would probably be an even better solution, since we never
> want to get involved with the clunky exceptions, otherwise it's
> identical. But there might be reasons why it isn't used.)
> 
> Roland
> 
> 
> > Dylan
> > 
> > 
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=02%7C01%7Csroland%40vmware.com%7C5f77a09021be4da94a1c08d649899668%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636777252795733409&sdata=ZS9kXWZAg0jOYt5bXyPV2rqlnhqN1ojr675tb8kKPTg%3D&reserved=0
> > 
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev