[Mesa-dev] Reducing get.c size (and get_es1.c and get_es2.c)

[Roland Scheidegger]

On 11.05.2010 20:08, Kristian Høgsberg wrote:
> 2010/5/11 Brian Paul <brianp at vmware.com>:
>> Kristian Høgsberg wrote:
>>> 2010/5/6 Kristian Høgsberg <krh at bitplanet.net>:
>>>> Hi,
>>>>
>>>> Ok, I suppose this is not the most pressing issue in mesa, but I was
>>>> toying with an idea of how to reduce get.c size and integrate
>>>> get_es1.c and get_es2.c and I had to try it out.  Of course it ended
>>>> up being a bigger project and took a couple of days, but in the end I
>>>> think it turned out to be a worthwhile effort.  The result is the two
>>>> patches on the get-optimagix branch in my personal mesa repo:
>>>>
>>>>  http://cgit.freedesktop.org/~krh/mesa/log/?h=get-optimagix
>>> I've updated the patch on the branch here, but I'm still not going to
>>> send it to the list (it's 500k and most of which deletes generated
>>> code).  But I've been going back and forth with Brian about the patch
>>> a few times and we found a few bugs and made the code a little faster.
>>>  Brian cooked up a small micro-benchmark for the glGet*v() functions
>>> and it turned out that the code was actually slower than the old
>>> generated code.  With a little tweaking of the table lookup and adding
>>> a couple of likely() annotations, I got the code from 30s to 23s,
>>> where the old code would take 15s.  That's still 17 million gets per
>>> second, so I doubt the new code is going to be a bottleneck.
>> It looks like piglit's texunits test is failing, compared to Mesa/master.
>>  It may be an issue with flush-current when getting the curren texture
>> coords.
> 
> Fixed, didn't initialize 'unit' in find_custom_value().
> 
>> I'd like to see comments on more of the internal functions, like
>> find_value() to describe the parameters in/out.
> 
> Ok, done.
> 
>> Also, could you replace the #ifdef DEBUG stuff with a separate #ifdef
>> GET_DEBUG or similar to avoid printing the hash table collision info all the
>> time in debug builds?
> 
> Sure, done.
> 
>> There hasn't been any other feedback so I'd so go ahead and commit it to
>> master when these things are fixed.
> 
> Done, and I updated the table with your recent feedback changes.

Just a small nitpick, but I got buried under roughly 300 compiler
warnings (missing initializer). Now that looks pretty harmless, but I
didn't feel like fixing all 300 occasions in the table manually :-(.

Roland