|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC] Xen Virtual Framebuffer
You don't need a network outside of the box; you just treat all of the domains as being wired together with a virtual network inside of the box. Sure thing; I'm just expecting users to break their network configuration with alacrity ;-) Something that's zero-config would be nice to have available as a baseline. As a bonus it also gives us the opportunity to support things like QT Embedded, GTK, elinks, etc when those are configured to render direct to the framebuffer device. To be fair, these users are likely to be relatively uncommon. X already uses Unix domain sockets to talk between apps and the X server. I would expect a virtualized network running inside the box to have about the same performance as Unix domain sockets. The X server already support this socket model today, no new code needs to be written, Xen just needs to provide the internal virtual network.It should also give better performance, as James mentioned. Eventually, it'd be nice to support accelerated OpenGL in domUs but that may be some way off.Virtual framebuffer is not going to give you better performance than the X socket system. I wrote this paper a while ago, it should give you a good feel of the complexities involved. http://dri.freedesktop.org/~jonsmirl/graphics.html It seems relatively unfortunate to have to transfer data over the internal network when we could just use framebuffer memory which would be shared dom0 <-> domU (although I'm not sure if that overhead would actually matter to us). Surely it'd also be beneficial to enable X<->app shared memory tricks etc, rather than running over a network socket? Btw, that paper had been on my "must read" list for a while, thanks for reminding me. Kudos for your work on Xgl, too bad you weren't supported more. Cheers, Mark Cheers, Mark On Dec 6 2005, James Harper wrote: >Some things just work better when you can enable shared memory >extensions under X, which obviously can't be done over the network. > >Also, X isn't the only thing that can make use of a framebuffer. > >James > >> -----Original Message----- >> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel- >> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jon Smirl >> Sent: Tuesday, 6 December 2005 11:36 >> To: Anthony Liguori >> Cc: xen-devel >> Subject: Re: [Xen-devel] [RFC] Xen Virtual Framebuffer >> >> I haven't tried playing with X and Xen, but why doesn't it work to >> just treat the multiple domains like a network? You run X in dom0 and >> give it full access to the video hardware. Then you ssh into each >> domain and start X apps, just like you do when using X remotely. >> OpenGL will even work this way and be accelerated (as soon as X fixes >> indirect acceleration). This model should let you get apps up from >> each domain simultaneously on the X display in dom0. >> >> -- >> Jon Smirl >> jonsmirl@xxxxxxxxx >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@xxxxxxxxxxxxxxxxxxx >> http://lists.xensource.com/xen-devel > > >_______________________________________________ >Xen-devel mailing list >Xen-devel@xxxxxxxxxxxxxxxxxxx >http://lists.xensource.com/xen-devel >-- Jon Smirl jonsmirl@xxxxxxxxx _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |