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

Keith Packard keithp at keithp.com
Tue Jul 3 11:26:58 PDT 2012

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.

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?

keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20120703/96deb894/attachment.pgp>

More information about the xorg-devel mailing list