[REVIEW] DMX2 DIX merge

[Adam Jackson]

On Wed, 2010-01-06 at 17:26 -0800, Keith Packard wrote:
> On Wed, 06 Jan 2010 17:39:15 -0500, Adam Jackson <ajax at nwnk.net> wrote:
> > I described this wrong.  It corrects the RANDR geometry to account for
> > the Xin muxer's idea of the root window size, but XRRGetScreenResources
> > still only gives you the RANDR objects on screen 0.  Not useful
> > enough.
> 
> Right, RandR gets completely scrambled when the panoramix code is
> running. Does anyone feel up to the task of trying to get it all patched
> back together?

I'm working on that, yeah.

> > Basically redirected windows get forced to host memory.  So you're
> > always drawing to them in software, but on the plus side, you're only
> > doing it once, where the normal rendering muxer would serialize that
> > draw across every ScreenRec.
> > 
> > But that's still kind of gross, since your per-screen pixmaps are still
> > going to end up in VRAM, and then read back out to get to the window
> > pixmap, and then back into VRAM for the compositor.
> 
> I don't think I get this piece -- you shouldn't ever have to touch any
> of the pixmaps with the CPU for compositing to work with Xinerama.

The DMX2 pixmap storage change is that window pixmaps for redirected
windows live in host memory, period.  Your XA probably tries to create
new pixmaps in VRAM.  Blitting from that to the window becomes a
readback, which I suppose could be CPU-driven or not.

It doesn't _have_ to work that way, but that's what it looks like DMX2
does.

> > Anyway, was planning to just ignore this part of the patch series for
> > now, since I'm hoping to get lazy pixmap realization working instead.
> 
> Yeah, that's obviously what we want anyway. Not entirely sure how to
> make that work well with Composite as the screen location of the window
> may not reflect the only rendering target for the compositor (think
> active icons).

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.  Redirected
Window Pixmaps are initially created on the ScreenRec whose geometry is
a strict superset of the window geometry, or in host memory otherwise
(root window, panel, etc). [1]

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?

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

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.

- 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/7e7b0a90/attachment.pgp