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

Roland Scheidegger sroland at vmware.com
Tue Nov 13 22:13:00 UTC 2018


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


> 
> 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
> 



More information about the mesa-dev mailing list