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