[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Graphics in domU's
M.A. Williamson wrote:
What's the status about domU graphics these days?Anthony Liguori has written a virtual framebuffer driver that can be used to access the guest VTs, etc. This is not in-tree yet but looks promising. It should export to dom0's X server or directly to VNC with decent efficiency, and offer the possibility of running a 2D X server on top. Fully virtualised guests also get a virtual video card device, which provides a similar effect. The idea is that eventually fully-virtualised and paravirtualised guests will be accessible in a similar manner.Jacob Gorm Hansen is working on actually passing 3D operations efficiently from a guest to dom0, allowing good 3D performance from a guest virtual display. There is working code for this, although it's not complete and I'm not sure if a patch is available.It should also be possible to dedicate an entire card / display to a domU using the PCI passthrough feature. There are usually some configuration hiccups when trying to get this to work, but in principle it's quite possible to have a graphics card for each graphics-capable domain. This should give full-speed graphics to the guest.
Yes, I've seen those interesting ideas discussed in devel/users. Especially interesting since PCI-passthru is back in 3.x . In terms of HW, a bit expensive perhaps, but with todays PCIe systems quite goos performance should be obtainable. I could live well with good performance in two domUs/systems, each with their own (~$100) cards, and so-so perfomance for the rest, based on virtual framebuffer or whatever - given that such a scenario /will/ work.
For most users, the solution is "just use network-based graphics". You should be able to do most things you need using X-protocol, VNC, or NX.I'm aware that hypervisor-aware drivers are needed, and none has been written so far, mainly because proprietary vendors hasn't deemed it worth the while as yet (nVidia has opened an RFE, but AFAIK not opened it as a workload),IIRC, this is just a "make the driver work properly in dom0" request, rather than anything more sophisticated.
It was my understanding it would be a far more elaborate process.If not, I fail to understand why nVidia hasn't revealed any work in progress, preprietary or not. It's been half a year or so since Lonni (I think) answered on nvnews that he would be happy to open the RFE.
perhaps because they don't see Xen as interesting on the desktop, or feels that HW accelerated virtualization, permitting unmodified clients, isn't there yet.I know work is in progress WRT GLX, any word on that?Considering traditional drivers, the opensource opencrome.org driver should support 3D acceleration for VIA/S3 Unichrome cards.Wouldn't that one be a good candidate for an Xen-adapted driver?The trouble is that you don't want to emulate a complete hardware graphics device to the guest, because graphics cards are complicated.
I'm aware of that.. I was thinking that VIA/S3 cards are less complex than nVidia/ATI, and already having a fully working OSS driver...
Jacob's and Anthony's drivers skip emulating the device completely: graphics subsystem talks pretty much directly to dom0, which then displays stuff using the hardware it controls.I've heard rumours that there's work going on to build graphics cards that can be directly accessed by multiple virtual machines. For instance, IIRC, MS and NVidia have admitted to talking about it. If this hardware ever comes to light, things will be somewhat simpler: give 3D-capable domains direct access to a virtualisation-aware graphics card and tell the card which bits of the screen to let them render to.
Yes, I've read about that too. It'll go hand in hand with future effords to virtualize the whole platform; kind of a second step after the cpu.
-- Kind regards, Mogens Valentin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
Lists.xenproject.org is hosted with RackSpace, monitoring our