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

[Dave Airlie]

Oops gmail send this, silly laptop has a mind of its own sometimes.

On Sat, Dec 12, 2009 at 11:58 AM, Dave Airlie <address@hidden> 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.
>
> 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.

This requires 3D rendering hw on the client, this could be your laptop
or desktop in the office, in which case its probably fine nto so good
if its server hw in a rack.

> 2) Rendering done on the client viewing end of the link where the viewer is,

Have to transport 3D to the client, but more likely the client end
will have 3D hardware to actually render stuff at a reasonable speed.

So I suppose lets discuss ;-)

Dave.
(btw I work for Red Hat but not in this capacity or near virt teams,
this is purely a personal itch).