[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-users] Xen handling of graphics card
> -----Original Message----- > From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Jean-Eric Cuendet > Sent: 12 January 2006 10:10 > To: xen-users@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Xen-users] Xen handling of graphics card > > > > In any form of VT/SVM system, as of right now, the entire system's > > hardware accesses are routed to an emulator (qemu for most > operations, > > internal hypervisor emulator for a few select hardware > items, such as > > the interrupt controller & timer). So Windows, or any other > OS, will > > have a QEMU graphics window that displays it's output. So it's a > > "faked card bridged by Xen" in your words. > > > > When Xen 3.x re-implements the Dom0 device hiding, you > could, at least > > in theory, have two graphics cards and use one directly in Windows. > > But would it be possible to tell Xen to "give" the entire > card to Windows and then get it back to dom0 and then back to > Linux X11 domU and then to Windows domU, etc... ? > What you explain is that the only way of "sharing" the card > between 2 domU OSes is through a QEmu windows so no *Real* > full screen neither full Windows acceleration. That means the > desktop Linux/Windows in Xen will be hard to do. This is non-trivial: 1. Windows and Dom0 needs to run in parallel, or the device accesses that are virtualized on behalf of the DomU would not be performed. So, you'd be spending more time swapping graphics content than anything else in the system - ever tried saving away 128 MB of graphics data to replace it with another 128MB? [And no, you can't just get away with saving a little bit of the frame buffer memory, unless the driver(s) involved agree to not use all of the memory]. 2. It would require a "neat" transition - what if the Windows driver has sent a complex drawing request to the graphics card and is currently sitting waiting for an interrupt from the completion of that request, and at that very moment the Dom0 takes over the card? Who gets that interrupt? Obviously, with a Xen-aware graphics driver, it would be possible to solve both of these problems. It is, however, not entirely trivial to write such a driver for a decent modern graphics card. Trust me, I used to work for 3DLabs as a driver developer, the source code for 2D side of the driver is several megabytes, and the 3D parts of the driver are MUCH larger than that. And I think an nVidia or ATI driver is even larger - at least the binary is... Xen's primary target is for servers, so high performance graphics isn't really high priority - this doesn't mean that noone will ever do graphics drivers specifically to support this stuff, but at the moment it's not the highest priority. -- Mats > -jec > > > _______________________________________________ > Xen-users mailing list > Xen-users@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-users > > _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |