[PATCH 18/36] privates: when pixmap privates increase, bump the totalPixmapSize

[Dave Airlie]

On Tue, Jul 3, 2012 at 7:26 PM, Keith Packard <keithp at keithp.com> wrote:
> Dave Airlie <airlied at gmail.com> writes:
>
>> So I'm not sure what you mean by per-screen private data, drivers have
>> requirements for per-pixmap private data as well, currently by modesetting
>> driver stashes the slave framebuffer id from the kernel into a pixmap
>> private.
>
> By per-screen private data, I mean private data in objects which are
> permanently associated with only one screen -- windows, pixmaps, gcs,
> pictures, etc.
>
> Those objects will only ever be used by one driver, and so private space
> for all other drivers need not be allocated in them; DIX should be
> overlaying those allocations so that each object contains only storage
> for the driver which will use it.

This sounds like what we want, do we have any examples of this sort of
thing already, I could take a look tomorrow, though it would be a bit of
a change to drivers that currently allocate privates.

> Expanding the current private API to support this, with the private
> structures themselves stored in a screen-private record so that it too
> is per-screen, would save memory in multi-GPU systems, as well as making
> it possible to reserve private space for new screens after the server
> has started.
>
>> Hence why I have to adjust the total pixmap size, though as ajax pointed
>> out its a bit monotonically increasing for sanity, I'll have to track
>> down it and see.
>
> Given that the relevant drivers aren't ever being unloaded, I'm curious
> as to why we see this increasing? Surely once the privates are allocated
> once, they'll simply get re-used each time?

well modesetting Init adds the private allocation, but since nobody binds to
it initially it never gets its private allocated, until something hotplugs later
then it increases after CSR has run.

Dave.