qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] approaches to 3D virtualisation


From: Mark Williamson
Subject: Re: [Qemu-devel] approaches to 3D virtualisation
Date: Sun, 13 Dec 2009 02:13:19 +0000
User-agent: KMail/1.12.2 (Linux/2.6.28-16-generic; KDE/4.3.2; i686; ; )

On Saturday 12 December 2009 01:58:02 Dave Airlie wrote:
> So I've been musing on the addition of some sort of 3D passthrough for
> qemu (as I'm sure have lots of ppl)
> 
> But I think the goals of such an addition need to be discussed prior
> to anyone writing a line of code.
> 
> Current existing solutions in the area:
> a) VMware virtual graphics adapter - based on DX9, has an open
> KMS/Gallium3D driver stack recently released by vmware, has certified
> Windows drivers and has a documented vGPU interface (it could be
> documented a lot better)
> 
> b) VirtualBox - seems to be GL based passthrough based on a Chromium
> backend. DX9 support, looks to be done via Wine DX->GL converter built
> into a Windows driver (not confirmed code base is crazy) I'm assuming
> chromium is being used to stream GL through the passthru but this
> definitely requires more investigation.

There may be an option c) in existence.  The OpenTC project (EU funded) 
included a secure UI project and part of that involved a prototype 
paravirtualised 3D driver.  It was done primarily by a research assistant at 
Cambridge University Computer Lab and basically added a paravirtual GPU device 
that essentially proxied Gallium-level commands across a shared memory 
transport.

There's a short paper on the work here, it was implemented for Xen but I doubt 
it's that Xen-specific:
http://www.xen.org/files/xensummit_oracle09/xensummit_chris.pdf

I think there's a longer paper that might be available somewhere.

I assume this is similar to the VMware approach, however as implemented it did 
require a Gallium 3D stack available on the host also in order to actually 
render the stuff.  ISTR the guy who worked on it mentioning that VMware may 
have implemented a Gallium->high level 3D API translator on the host side 
instead, since most hosts aren't using Gallium drivers yet.

The main reason I mention this is that I *thought* the code was meant to be 
open sourced, in which case it might at least be an interesting starting 
point.  I'm not quite sure where it *is* though!

Cheers,
Mark

PS: Whilst I'm braindumping, I also remember a guy implementing an OpenGL 
guest->host passthrough for Qemu back when Fabrice was maintainer, so that 
code should be in the archives somewhere.  Obviously that's not so useful for 
Windows guests, though Fabrice suggested maybe investigating Wine's DX->GL 
translation code.  Another GL virtualisation project is here, which is also 
GL-only (but despite the name is not Xen-only): 
http://www.cs.toronto.edu/~andreslc/xen-gl/

> Now both of these seem to be local only rendering solutions, though I
> might be underselling the vbox/chromium fun.
> 
> Now to add a remoting 3D rendering protocol is where things get ugly
> fast, and very different from current 2D rendering with offscreen
> pixmaps. The major difference is most server farms will not contain
> any 3D hardware and will not want to contain any 3D hw due to power
> considerations. Now if you have a remote protocol, and the client
> disconnects, you have to keep some sort of transaction log, and either
> replay the transactions when a client reconnects, or have some sort of
> sw rendering kick in on the server as a fallback. Now 3D sw rendering
> solutions are insanely slow and quite CPU intensive. VMware are
> working on an llvm based 3D renderer for something like this situation
> but I'm not convinced of how useable it will be.
> 
> Also with remoting you need to come up with a minimum acceptable level
> of 3D you want to expose to guests OSes depending on what the
> capabilities of the client side hw, or refuse connections unless the
> client can run all the features that you've exposed in side the guest.
> This ranges from DX7->DX11, and GL1.5 to GL3.0 situations.
> 
> I'm not sure how ppl who work with VNC see VNC fitting in with this
> sort of protocol, I expect SPICE is better placed with proper design
> to address this. Though it would firstly be nice to design a vGPU
> interface for the guest OS to work against, I lean towards the VMware
> because of the availability of guest drivers, however the Virtualbox
> one is probably also acceptable if anyone can find where it is
> documented.
> 
> This is just a sort of a brain dump from me, but I'd like to get ppl
> talking about this, since 3D is not to be considered some simple
> extension of 2D functionality,
> its a whole different world, modern GPUs are 98% of silicon dedicated
> to 3D processing, most of the current 2D type accel such as QXL
> interface provides are done using 3D engines on most GPUs, and the
> inability to render 3D on the server side of a link with any useful
> speed in current server hw.
> 
> So I suppose the main questions to answer up front are:
> 1) Rendering done on same hw as VM is running?
> just use VNC to dump the final answer over the network.
> 2) Rendering done on the client viewing end of the link where
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]