Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf
Although I'm not sure we actually really wanted that rounding behavior in the first place - it's possible the only reason it was used is just because it had an easy implementation... From: Matt Turner Sent: Friday, November 16, 2018 8:02:00 PM To: Dylan Baker Cc: Roland Scheidegger; ML mesa-dev; erik.faye-l...@collabora.com Subject: Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf On Fri, Nov 16, 2018 at 10:34 AM Dylan Baker wrote: > > Quoting Roland Scheidegger (2018-11-13 18:41:00) > > Am 14.11.18 um 03:21 schrieb Matt Turner: > > > On Tue, Nov 13, 2018 at 6:03 PM Roland Scheidegger > > > wrote: > > >> > > >> Am 13.11.18 um 23:49 schrieb 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? > > >> Oh indeed, I didn't check the code too closely (I was just assuming > >
Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf
On Tue, Nov 13, 2018 at 6:41 PM Roland Scheidegger wrote: > > Am 14.11.18 um 03:21 schrieb Matt Turner: > > On Tue, Nov 13, 2018 at 6:03 PM Roland Scheidegger > > wrote: > >> > >> Am 13.11.18 um 23:49 schrieb 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? > >> Oh indeed, I didn't check the code too closely (I was just assuming > >> _mm_round_ss() was used because it is possible to use round-to-nearest > >> regardless the actual rounding mode, but that's not the case). > >> > >> But actually I misread this code: the point of mesa_roundevenf is to > >> round to float WITHOUT conversion to int. In which case it makes more > >> sense at least at first look... > >> > >> But if you want to round to nearest integer WITH conversion to int, you > >> probably really want to use something else. nearbyint family doesn't > >> have variants which give you ints. There's rint functions which give you > >> ints directly, but they are likely a very bad idea (aside from exception > > > > Why? > Not sure what the why refers to here? Why is rint a very bad idea? > > > >> handling, not quite sure if this really causes the compiler to do > >> something different) because of giving you long (or long long) results - > >> meaning that you can't use the simple cpu instructions giving you 32bit > >> results (because conversion to 64bit long + trunc to 32bit will give you > >> defined (although meaningless) results in some cases where direct > >> conversion to 32bit int wouldn't). > >> So ideally you'd pick a variant where the compiler is smart enough to > >> recognize it can be done with a single instruction. I would guess > >> nearbyintf + int cast should do just about everywhere, at least as long > >> as x64 or x86 + sse2 is used, my suspicion is the old IROUND function > >> was done in a time where x87 was still relevant. Or maybe rintf + int > >> cast, no idea how the compiler really handles them differently (I tried > >> to quickly look at it in gcc source, but no idea where those are > >> buried). As a side note, I hate it when the assembly solution is obvious > >> and you can't really figure out how the hell you should coax the > >> compiler in giving you the right answer (I mean, high level languages > >> are there to help, not get in your way...). > > > > Please read the commit
Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf
On Fri, Nov 16, 2018 at 10:34 AM Dylan Baker wrote: > > Quoting Roland Scheidegger (2018-11-13 18:41:00) > > Am 14.11.18 um 03:21 schrieb Matt Turner: > > > On Tue, Nov 13, 2018 at 6:03 PM Roland Scheidegger > > > wrote: > > >> > > >> Am 13.11.18 um 23:49 schrieb 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? > > >> Oh indeed, I didn't check the code too closely (I was just assuming > > >> _mm_round_ss() was used because it is possible to use round-to-nearest > > >> regardless the actual rounding mode, but that's not the case). > > >> > > >> But actually I misread this code: the point of mesa_roundevenf is to > > >> round to float WITHOUT conversion to int. In which case it makes more > > >> sense at least at first look... > > >> > > >> But if you want to round to nearest integer WITH conversion to int, you > > >> probably really want to use something else. nearbyint family doesn't > > >> have variants which give you ints. There's rint functions which give you > > >> ints directly, but they are likely a very bad idea (aside from exception > > > > > > Why? > > Not sure what the why refers to here? > > > > > > > > > >> handling, not quite sure if this really causes the compiler to do > > >> something different) because of giving you long (or long long) results - > > >> meaning that you can't use the simple cpu instructions giving you 32bit > > >> results (because conversion to 64bit long + trunc to 32bit will give you > > >> defined (although meaningless) results in some cases where direct > > >> conversion to 32bit int wouldn't). > > >> So ideally you'd pick a variant where the compiler is smart enough to > > >> recognize it can be done with a single instruction. I would guess > > >> nearbyintf + int cast should do just about everywhere, at least as long > > >> as x64 or x86 + sse2 is used, my suspicion is the old IROUND function > > >> was done in a time where x87 was still relevant. Or maybe rintf + int > > >> cast, no idea how the compiler really handles them differently (I tried > > >> to quickly look at it in gcc source, but no idea where those are > > >> buried). As a side note, I hate it when the assembly solution is obvious > >
Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf
Quoting Roland Scheidegger (2018-11-13 18:41:00) > Am 14.11.18 um 03:21 schrieb Matt Turner: > > On Tue, Nov 13, 2018 at 6:03 PM Roland Scheidegger > > wrote: > >> > >> Am 13.11.18 um 23:49 schrieb 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? > >> Oh indeed, I didn't check the code too closely (I was just assuming > >> _mm_round_ss() was used because it is possible to use round-to-nearest > >> regardless the actual rounding mode, but that's not the case). > >> > >> But actually I misread this code: the point of mesa_roundevenf is to > >> round to float WITHOUT conversion to int. In which case it makes more > >> sense at least at first look... > >> > >> But if you want to round to nearest integer WITH conversion to int, you > >> probably really want to use something else. nearbyint family doesn't > >> have variants which give you ints. There's rint functions which give you > >> ints directly, but they are likely a very bad idea (aside from exception > > > > Why? > Not sure what the why refers to here? > > > > > >> handling, not quite sure if this really causes the compiler to do > >> something different) because of giving you long (or long long) results - > >> meaning that you can't use the simple cpu instructions giving you 32bit > >> results (because conversion to 64bit long + trunc to 32bit will give you > >> defined (although meaningless) results in some cases where direct > >> conversion to 32bit int wouldn't). > >> So ideally you'd pick a variant where the compiler is smart enough to > >> recognize it can be done with a single instruction. I would guess > >> nearbyintf + int cast should do just about everywhere, at least as long > >> as x64 or x86 + sse2 is used, my suspicion is the old IROUND function > >> was done in a time where x87 was still relevant. Or maybe rintf + int > >> cast, no idea how the compiler really handles them differently (I tried > >> to quickly look at it in gcc source, but no idea where those are > >> buried). As a side note, I hate it when the assembly solution is obvious > >> and you can't really figure out how the hell you should coax the > >> compiler in giving you the right answer (I mean, high level languages > >> are there to help, not get in your way...). > > > > Please read the commit message of > > > > commit
Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf
On Tue, 2018-11-13 at 22:13 +, 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-devdata=02%7C01%7Csroland%40vmware.com%7C5f77a09021be4da94a1c08d649899668%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636777252795733409sdata=ZS9kXWZAg0jOYt5bXyPV2rqlnhqN1ojr675tb8kKPTg%3Dreserved=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
Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf
On Tue, 2018-11-13 at 09:00 -0800, Dylan Baker wrote: > 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. Because we'd end up calling rintf, which I suspected had to update errno, like many CRT math functions require. But looking a the POSIX spec, it seems this isn't the case, so this change looks fine to me. Sorry for the noise. Anyway, regardless of your change, perhaps we should consider adding something like "assert(fegetround() == FE_TONEAREST)" to validate the assumption? > 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) Nice :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf
Am 14.11.18 um 03:21 schrieb Matt Turner: > On Tue, Nov 13, 2018 at 6:03 PM Roland Scheidegger wrote: >> >> Am 13.11.18 um 23:49 schrieb 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? >> Oh indeed, I didn't check the code too closely (I was just assuming >> _mm_round_ss() was used because it is possible to use round-to-nearest >> regardless the actual rounding mode, but that's not the case). >> >> But actually I misread this code: the point of mesa_roundevenf is to >> round to float WITHOUT conversion to int. In which case it makes more >> sense at least at first look... >> >> But if you want to round to nearest integer WITH conversion to int, you >> probably really want to use something else. nearbyint family doesn't >> have variants which give you ints. There's rint functions which give you >> ints directly, but they are likely a very bad idea (aside from exception > > Why? Not sure what the why refers to here? > >> handling, not quite sure if this really causes the compiler to do >> something different) because of giving you long (or long long) results - >> meaning that you can't use the simple cpu instructions giving you 32bit >> results (because conversion to 64bit long + trunc to 32bit will give you >> defined (although meaningless) results in some cases where direct >> conversion to 32bit int wouldn't). >> So ideally you'd pick a variant where the compiler is smart enough to >> recognize it can be done with a single instruction. I would guess >> nearbyintf + int cast should do just about everywhere, at least as long >> as x64 or x86 + sse2 is used, my suspicion is the old IROUND function >> was done in a time where x87 was still relevant. Or maybe rintf + int >> cast, no idea how the compiler really handles them differently (I tried >> to quickly look at it in gcc source, but no idea where those are >> buried). As a side note, I hate it when the assembly solution is obvious >> and you can't really figure out how the hell you should coax the >> compiler in giving you the right answer (I mean, high level languages >> are there to help, not get in your way...). > > Please read the commit message of > > commit dd0d3a2c0fb388745519c8a3be800720541eccfe > Author: Matt Turner > Date: Tue Mar 10 17:55:21 2015 -0700 > > mesa: Replace _mesa_round_to_even() with _mesa_roundeven(). > > for a lot of the background. > > I expect IROUND_POS can be replaced with the _mesa_lroundevenf
Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf
Am 14.11.18 um 03:02 schrieb Roland Scheidegger: > Am 13.11.18 um 23:49 schrieb 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? > Oh indeed, I didn't check the code too closely (I was just assuming > _mm_round_ss() was used because it is possible to use round-to-nearest > regardless the actual rounding mode, but that's not the case). > > But actually I misread this code: the point of mesa_roundevenf is to > round to float WITHOUT conversion to int. In which case it makes more > sense at least at first look... > > But if you want to round to nearest integer WITH conversion to int, you > probably really want to use something else. nearbyint family doesn't > have variants which give you ints. There's rint functions which give you > ints directly, but they are likely a very bad idea (aside from exception > handling, not quite sure if this really causes the compiler to do > something different) because of giving you long (or long long) results - > meaning that you can't use the simple cpu instructions giving you 32bit > results (because conversion to 64bit long + trunc to 32bit will give you > defined (although meaningless) results in some cases where direct > conversion to 32bit int wouldn't). > So ideally you'd pick a variant where the compiler is smart enough to > recognize it can be done with a single instruction. I would guess > nearbyintf + int cast should do just about everywhere, at least as long > as x64 or x86 + sse2 is used, my suspicion is the old IROUND function > was done in a time where x87 was still relevant. Or maybe rintf + int > cast, no idea how the compiler really handles them differently (I tried > to quickly look at it in gcc source, but no idea where those are > buried). As a side note, I hate it when the assembly solution is obvious > and you can't really figure out how the hell you should coax the > compiler in giving you the right answer (I mean, high level languages > are there to help, not get in your way...). > > All that said, I still don't really see the point of the manual sse41 > assembly (even for the case when we don't want to convert to int) - > assuming there is an easy solution to get the compiler to do the right > thing... Err, I tried it out and was completely unable to come up with something which wouldn't generate huge amounts of crap code (or library calls). WTF. (But might depend on compiler, of course.) So I guess maybe for round conversion to int you actually want to manually do sse2 inline asm
Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf
On Tue, Nov 13, 2018 at 6:03 PM Roland Scheidegger wrote: > > Am 13.11.18 um 23:49 schrieb 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? > Oh indeed, I didn't check the code too closely (I was just assuming > _mm_round_ss() was used because it is possible to use round-to-nearest > regardless the actual rounding mode, but that's not the case). > > But actually I misread this code: the point of mesa_roundevenf is to > round to float WITHOUT conversion to int. In which case it makes more > sense at least at first look... > > But if you want to round to nearest integer WITH conversion to int, you > probably really want to use something else. nearbyint family doesn't > have variants which give you ints. There's rint functions which give you > ints directly, but they are likely a very bad idea (aside from exception Why? > handling, not quite sure if this really causes the compiler to do > something different) because of giving you long (or long long) results - > meaning that you can't use the simple cpu instructions giving you 32bit > results (because conversion to 64bit long + trunc to 32bit will give you > defined (although meaningless) results in some cases where direct > conversion to 32bit int wouldn't). > So ideally you'd pick a variant where the compiler is smart enough to > recognize it can be done with a single instruction. I would guess > nearbyintf + int cast should do just about everywhere, at least as long > as x64 or x86 + sse2 is used, my suspicion is the old IROUND function > was done in a time where x87 was still relevant. Or maybe rintf + int > cast, no idea how the compiler really handles them differently (I tried > to quickly look at it in gcc source, but no idea where those are > buried). As a side note, I hate it when the assembly solution is obvious > and you can't really figure out how the hell you should coax the > compiler in giving you the right answer (I mean, high level languages > are there to help, not get in your way...). Please read the commit message of commit dd0d3a2c0fb388745519c8a3be800720541eccfe Author: Matt Turner Date: Tue Mar 10 17:55:21 2015 -0700 mesa: Replace _mesa_round_to_even() with _mesa_roundeven(). for a lot of the background. I expect IROUND_POS can be replaced with the _mesa_lroundevenf function. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org
Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf
Am 13.11.18 um 23:49 schrieb 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? Oh indeed, I didn't check the code too closely (I was just assuming _mm_round_ss() was used because it is possible to use round-to-nearest regardless the actual rounding mode, but that's not the case). But actually I misread this code: the point of mesa_roundevenf is to round to float WITHOUT conversion to int. In which case it makes more sense at least at first look... But if you want to round to nearest integer WITH conversion to int, you probably really want to use something else. nearbyint family doesn't have variants which give you ints. There's rint functions which give you ints directly, but they are likely a very bad idea (aside from exception handling, not quite sure if this really causes the compiler to do something different) because of giving you long (or long long) results - meaning that you can't use the simple cpu instructions giving you 32bit results (because conversion to 64bit long + trunc to 32bit will give you defined (although meaningless) results in some cases where direct conversion to 32bit int wouldn't). So ideally you'd pick a variant where the compiler is smart enough to recognize it can be done with a single instruction. I would guess nearbyintf + int cast should do just about everywhere, at least as long as x64 or x86 + sse2 is used, my suspicion is the old IROUND function was done in a time where x87 was still relevant. Or maybe rintf + int cast, no idea how the compiler really handles them differently (I tried to quickly look at it in gcc source, but no idea where those are buried). As a side note, I hate it when the assembly solution is obvious and you can't really figure out how the hell you should coax the compiler in giving you the right answer (I mean, high level languages are there to help, not get in your way...). All that said, I still don't really see the point of the manual sse41 assembly (even for the case when we don't want to convert to int) - assuming there is an easy solution to get the compiler to do the right thing... Roland > > Dylan > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf
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
Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf
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@lists.freedesktop.org > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Csroland%40vmware.com%7C5f77a09021be4da94a1c08d649899668%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636777252795733409sdata=ZS9kXWZAg0jOYt5bXyPV2rqlnhqN1ojr675tb8kKPTg%3Dreserved=0 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf
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) Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf
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... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf
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. I'll add that to the commit message. Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/28] Replace IROUND_POS with _mesa_roundevenf
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...
> ---
> src/mesa/drivers/x11/xm_api.c | 2 +-
> src/mesa/main/imports.h| 10 --
> src/mesa/swrast/s_aaline.c | 3 +--
> src/mesa/swrast/s_aatriangle.c | 3 +--
> 4 files changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/src/mesa/drivers/x11/xm_api.c
> b/src/mesa/drivers/x11/xm_api.c
> index e8405950656..6ff1269d07d 100644
> --- a/src/mesa/drivers/x11/xm_api.c
> +++ b/src/mesa/drivers/x11/xm_api.c
> @@ -151,7 +151,7 @@ gamma_adjust( GLfloat gamma, GLint value, GLint
> max )
> }
> else {
>double x = (double) value / (double) max;
> - return IROUND_POS((GLfloat) max * pow(x, 1.0F/gamma));
> + return _mesa_roundevenf((GLfloat) max * pow(x, 1.0F/gamma));
> }
> }
>
> diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
> index 59133643442..fbb7e59ca06 100644
> --- a/src/mesa/main/imports.h
> +++ b/src/mesa/main/imports.h
> @@ -136,16 +136,6 @@ static inline GLint64 IROUND64(float f)
> }
>
>
> -/**
> - * Convert positive float to int by rounding to nearest integer.
> - */
> -static inline int IROUND_POS(float f)
> -{
> - assert(f >= 0.0F);
> - return (int) (f + 0.5F);
> -}
> -
> -
> /***
> ***
> * Functions
> */
> diff --git a/src/mesa/swrast/s_aaline.c b/src/mesa/swrast/s_aaline.c
> index de5b42b9f6b..e86d0b5015c 100644
> --- a/src/mesa/swrast/s_aaline.c
> +++ b/src/mesa/swrast/s_aaline.c
> @@ -25,7 +25,6 @@
>
> #include "c99_math.h"
> #include "main/glheader.h"
> -#include "main/imports.h"
> #include "main/macros.h"
> #include "main/mtypes.h"
> #include "main/teximage.h"
> @@ -181,7 +180,7 @@ solve_plane_chan(GLfloat x, GLfloat y, const
> GLfloat plane[4])
>return 0;
> else if (z > CHAN_MAX)
>return CHAN_MAX;
> - return (GLchan) IROUND_POS(z);
> + return (GLchan) _mesa_roundevenf(z);
> #endif
> }
>
> diff --git a/src/mesa/swrast/s_aatriangle.c
> b/src/mesa/swrast/s_aatriangle.c
> index b5109870437..20d0a9d3043 100644
> --- a/src/mesa/swrast/s_aatriangle.c
> +++ b/src/mesa/swrast/s_aatriangle.c
> @@ -31,7 +31,6 @@
> #include "main/glheader.h"
> #include "main/context.h"
> #include "main/macros.h"
> -#include "main/imports.h"
> #include "main/state.h"
> #include "s_aatriangle.h"
> #include "s_context.h"
> @@ -124,7 +123,7 @@ solve_plane_chan(GLfloat x, GLfloat y, const
> GLfloat plane[4])
>return 0;
> else if (z > CHAN_MAX)
>return CHAN_MAX;
> - return (GLchan) IROUND_POS(z);
> + return (GLchan) _mesa_roundevenf(z);
> #endif
> }
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
