[Qemu-devel] approaches to 3D virtualisation

[Dave Airlie]

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.
2) Rendering done on the client viewing end of the link where