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
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
