[Mesa-dev] [PATCH] faster util_next_power_of_two() function

Brian Paul brian.e.paul at gmail.com
Mon Jun 6 13:10:55 PDT 2011


On Mon, Jun 6, 2011 at 11:57 AM, Benjamin Bellec <b.bellec at gmail.com> wrote:
> Le 06/06/2011 17:34, Roland Scheidegger a écrit :
>> Am 05.06.2011 03:55, schrieb Benjamin Bellec:
>>> Le 05/06/2011 03:05, Matt Turner a écrit :
>>>> On Sat, Jun 4, 2011 at 7:14 PM, Benjamin Bellec <b.bellec at gmail.com> wrote:
>>>>> Le 03/06/2011 06:09, Matt Turner a écrit :
>>>>>> Also, if you want to check if the value is already a power-of-two,
>>>>>> instead of a case statement for every POT (including 0), just do the
>>>>>> standard is-power-of-two check:
>>>>>>
>>>>>> (x & (x - 1)) == 0
>>>>>
>>>>> My own tests (on a Core2) shows that it's less efficient to do that, at
>>>>> least with -O2 optimization enabled. With -O0, it's equal.
>>>>
>>>> For what input set? Powers of two?
>>> Both, my test case loops with 29 POT and 6 NPOT.
>>> I'm doing this because the OpenGL games that I have tested call the
>>> function more often with "good" values.
>>>
>>>>
>>>> Doesn't really matter, since the function isn't a hot path or
>>>> anything, but I'd suppose that the Linux kernel has its
>>>> is_power_of_2() function for a reason--that it's pretty ugly to have
>>>> lots of case statements like powers of two.
>>>>
>>>> Matt
>>> Ok, so here is a v3 patch which replace the switch statement.
>>
>> I like this one better too.
>> Do we actually need the x == 0 special case or would it be ok if we just
>> remove that (which will return 0)?
>>
>> Roland
>
> If we delete this check, we need to specify (in a comment) that the
> function have an undetermined behavior when passing 0 in parameters. Why
> not, but then the most important thing to know is from where the
> parameters came from: "mesa" or "GL apps"? If it's from GL apps it could
> be dangerous to change the result of this function, even if 0 is a
> stupid input (no?).

After a cursory look at the callers, I don't think 0 is ever passed as
an argument.  But to play it safe I'd probably keep the current
behaviour.

-Brian


More information about the mesa-dev mailing list