On Fri, Apr 16, 2010 at 11:41:51AM -0400, Adam Jackson wrote: > On Fri, 2010-04-16 at 10:47 +0200, Rafal Wojtczuk wrote: > > On Wed, Apr 14, 2010 at 03:59:39PM -0400, Adam Jackson wrote: > > > I'm assuming by "composition buffer" you mean the thing you're actually > > > scanning out on the display. > > > > No. I mean the per-window offscreen storage mechanism, activated by > > XCompositeRedirectSubwindows() function. Referred to as "windows backing > > pixmap" in http://ktown.kde.org/~fredrik/composite_howto.html. Apologies if > > I did not make it clear enough. > > Window pixmaps are like any other pixmap. Where they live is entirely > up to the driver. Unaccelerated drivers keep them in host memory with > malloc(). While we are at it: assuming nonaccelerated driver (in fact, in the actual setup, dummy_drv.so is used), is the pixmap->devPrivate.ptr field guaranteed to hold the pointer to actual pixels, or is it purely implementation (X server version) dependent and may change in future ? You can see the actual code at http://gitweb.qubes-os.org/gitweb/?p=mainstream/gui.git;a=blob;f=xf86-input-mfndev/src/qubes.c;h=6b898c25f2bc4d7c68da45764c565157b96ddd4a;hb=aca457004e731da0b642486d8b6f01a9f2b76c4d#l404
> Accelerated drivers do that sometimes, and then sometimes put > them in video memory. Remember that you can have more video memory than > you can see through a PCI BAR, so you might not be able to address the > pixmap from the CPU at all. > > > Briefly, the goal is to get the location of a composition buffer created by > > X server running in virtual machine A, and map it in the address space of > > virtual machine B. Such mapping has to be defined in terms of physical > > addresses; consequently, it is crucial to make sure that the frames backing > > a > > composition buffer do not change in time. > > That's not going to do anything useful without some synchronization > work. Window pixmaps aren't created afresh for each frame. They're > long-lived. If you manage to get a pixmap shared between VMs A and B, > there's nothing to stop A from rendering into it while B is reading from > it. Currently synchronization is done by damage extension events. It seems to work: a video player running in A in full screen is correctly displayed in B, all other apps work fine as well. > The way compositing managers handle this is by taking an X server grab > while reading out of the window pixmap, which does prevent other client > rendering from happening. And as soon as you're doing _that_, just > XGetImage the pixels out instead of playing funny MMU games, it'll > probably be faster. I beg to differ. XGetImage is a hopeless CPU hog - it transfers actual pixels over the connection to Xserver, so over the unix socket ? So, you would need XGetImage+copy XImage to B+XPutImage, which is 3 memory copies, 2 of them involving additional unix socket overhead. With MIT SHM extensions you can get rid of unix socket transfers, but still it is 3 memcpys. In the current qubes code, X server running in B maps the composition buffers from A, and then uses (slightly extended version of) XShmPutImage to display them. No memory copies, besides ones needed by XShmPutImage to push content to VGA. BTW, it is possible that in case of accelerated driver, XShmPutImage uses DMA from the MIT SHM region directly to VGA memory ? Regards, Rafal Wojtczuk The Qubes OS Project http://qubes-os.org _______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
