[Mesa-dev] mesa vs pahole

[Dave Airlie]

On 21 March 2015 at 00:13, Brian Paul <brianp at vmware.com> wrote:
> 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.
> """

Yeah I might look at this as well, though byte access can be slower
for some people than nice aligned uint32_ts,
but if it makes more stuff fit in a cacheline, it can't be a bad idea.

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

On modern machines it mostly about cachelines, rather than RAM in
terms of what is fast,

reducing gl context size is probably less important than reordering it
so used things are closer together.

I also wonder if we could split gl_context into gl_context and
gl_legacy_context so core profile apps don't need
to drag along all the old deprecated stuff, but that may be a large bit of work.

Dave.