[REVIEW] DMX2 DIX merge

[Adam Jackson]

On Thu, 2010-01-07 at 08:02 -0800, Keith Packard wrote:
> On Thu, 07 Jan 2010 10:04:45 -0500, Adam Jackson <ajax at nwnk.net> wrote:
> > If we consider a non-transformative, non-GL compositor, then I think
> > it's pretty straightforward.  Pixmaps created relative to the root
> > window start life in system memory, and can then be lazily bound
> > whichever ScreenRec ends up needing them as a source image.
> 
> I'm sure we could come up with magic to try and get the pixmaps to vram
> sooner, but guessing wrong means pulling data back from vram. Something
> as simple as a per-client hint might be OK though, where you guess that
> a pixmap will be used on the same card(s) as a recent window. Lots of
> possibilities here, we don't have to solve the problem right away at least.

Right.  We did at least get cairo fixed to do create_surface_similar
relative to the source surface, instead of the source surface's root
window.  That's a relatively straightforward hint that has the bonus of
being encodable in the core protocol, but one can imagine wanting
something more complex.

The challenge is that both the app and the compositor want to hint.

> > Transformation makes this one degree harder; a RWP that fits on GPU 0 in
> > the X geometry may be displayed on GPU 1, so now it needs to cross
> > memory domains.  Not great.  Do you just evict the pixmap to host memory
> > for good when that happens?
> 
> I'd like to avoid ever using host memory and instead manage objects that
> need to be used on multiple cards by replicating pixmaps, and having
> some way to de-replicate at appropriate times. That would avoid needing
> to try and make host memory shared across cards...

Seems like a good strategy.

De-replicating might not really be that necessary for application
pixmaps.  GTK and Qt tend to throw away their backing pixmaps after a
single use.  For RWPs, I guess you encode this in the Xin muxer itself:
you iterate rendering across all the ScreenRecs that a pixmap is
instantiated on (and instantiate it when it moves into the ScreenRec's
geometry), but after N rendering ops that would be logically clipped
away by screen geometry to a given ScreenRec, you tear down the pixmap
storage for that ScreenRec.

Long-lived pixmaps also tend to not be the kind of thing that gets
rendered to often.  The desktop background, for example.

> > GL makes it one degree harder still, because now you have to figure out
> > how to implement TFP.  For indirect GLX, the server has to bind the
> > pixmap (on some GPU) to potentially any number of DRI textures on
> > arbitrary numbers of GPUs.  You can be lazy about it, of course, but if
> > you do so you're making the inherent TFP sync problems even worse;
> > presumably we want a TFP texture to have the same texels on all the GPUs
> > it's used on...
> 
> At least with indirect GL it's possible to make it all work with a
> suitably large hammer. I don't even know if AIGLX ever worked under
> Xinerama though. Did it?

Not even a little.  DRI1 turned itself off when Xinerama is active, DRI2
probably does too.

> > I'm not even really sure what "direct rendered GLX" means in the context
> > of Xinerama.  I can see a plausible definition if all the GPUs are of
> > similar enough programming family that they can be driven by the same
> > DRI driver logic (all R800, for example), but if you're heterogeneous...
> > Direct rendered TFP would still require getting the GEM handle for the
> > pixmap to cross DRM device boundaries, even if you're homogeneous.
> 
> Yeah, I'd say that we should try to get AIGLX working and then consider
> whether we could make homogeneous direct rendering work sometime later.

Sounds like a plan.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-devel/attachments/20100107/67fcca36/attachment.pgp