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

[Dylan Baker]

Quoting Roland Scheidegger (2018-11-13 14:13:00)
> 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)... (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

I'm not convinced we want it either, since it seems to be slower than glibc's
rintf. I guess it probably does make sense to use the nearbyintf instead.

As an aside (since I know 0 about assembly), does _MM_FROUND_CUR_DIRECTION not
check the rounding mode?

Dylan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181113/a24ff7cc/attachment.sig>