Keith Packard <[email protected]> writes: > Screen-specific privates areas are only allocated for objects related > to the target screen; objects allocated for other screens will not > have the private space reserved. This saves memory in these objects > while also allowing hot-plug screens to have additional private > allocation space beyond what the core screens are using. > > Drivers are encouraged to switch to this mechanism as it will reduce > memory usage in multi-GPU environments, but it is only required for > drivers which will be loaded after the server starts, like > modesetting. > > Objects providing screen-specific privates *must* be managed by the > screen-specific private API when allocating or initializing privates > so that the per-screen area can be initialized properly. > > The objects which support screen-specific privates are: > > Windows > Pixmaps > GCs > Pictures > > Extending this list to include Colormaps would be possible, but > require slightly more work as the default colormap is created before > all colormap privates are allocated during server startup, and hence > gets a bunch of special treatment. > > Of particular note, glyphs are *not* capable of supporting > screen-specific privates as they are global objects, not allocated on > a screen-specific basis, and so each driver must be able to see their > privates within the glyph. > > Signed-off-by: Keith Packard <[email protected]>
This sequence, including some patches to fix up midispcur to support GPU hotplug has been Merged, with Reviewed-by: Dave Airlie <[email protected]>: ed6daa1..9e4b8b7 master -> master -- [email protected]
pgpLDLZ5knNwL.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
