[Mesa-dev] mesa vs pahole

[Brian Paul]

On 03/20/2015 01:29 AM, Dave Airlie wrote:
> I started running pahole on stuff today and mesa had a bunch of low
> hanging fruit all over the types, the main thing all of this
> does is reduce the mesa context size considerably.
>
> before:
> /* size: 150024, cachelines: 2345, members: 114 */
> after:
> /* size: 146912, cachelines: 2296, members: 114 */
>
> thats about 3k gone.
>
> but I'm sure some of these are kinda pointless
> micro-optimisation, but maybe give some points
> on where we can focus some reductions,
>
> gl_texture_attrib
> gl_image_unit
> being two of the scarier things I hit.

The patches look OK to me.

Acked-by: Brian Paul <brianp at vmware.com>

But as I wrote back on 11/23/2013 in "mesa: Remove the ralloc canary on 
release builds", we could probably save quite a bit of memory in 
dynamically allocated objects, namely textures:

"""
In gl_texture_image, for example, a number of the fields could be 
reduced to GLubyte (like Face, Level, Border, NumSamples, etc) and 
rearranged to reduce the memory used for such objects.

We could potentially reduce gl_texture_image from 80 bytes to 44 bytes 
which would save 324 bytes for a 256x256 mipmapped texture.  It would 
start to add up with a thousand textures or so.
"""

Another possibility is to dynamically allocate some things like 
gl_light_attrib (2664 bytes) and gl_evaluator_attrib (576 bytes) on 
demand since they're seldom used in modern apps.  Then again, this is 
all pretty small stuff on today's machines.

-Brian