[Mesa-dev] Mesa driver for VirtualBox

Michael Thayer michael.thayer at oracle.com
Fri Jun 21 16:10:31 PDT 2013

On 20/06/13 23:37, Dave Airlie wrote:
> On Fri, Jun 21, 2013 at 12:47 AM, Michael Thayer
> <michael.thayer at oracle.com> wrote:
>> Hello,
>> I am looking at the possibility of writing a driver for VirtualBox (ahem,
>> yes) which could partly live inside of the Mesa tree.  My initial idea was
>> to have the driver in two parts, a driver/client part in the Mesa tree and a
>> server part in the VirtualBox tree which would communicate using an
>> agreed-on protocol through a local socket.  The reasons for wanting to split
>> the driver this way are on the one hand that we still don't feel quite ready
>> to commit our host-guest 3D interface to eternity, and on the other that the
>> driver part on the Mesa side might well be useful in other contexts -
>> controlled 3D access (insofar as such a thing is possible) out of a sand box
>> comes to mind.
>> I was considering a textual protocol between client and server which would
>> more or less model the Gallium3D API, with (texture and other) buffers
>> passed using shared memory via file descriptors.  [...]  [The]
>> fact that we can't directly access the GLSL shader source which applications
>> on a guest system are presumably trying to send us, and which we need to
>> pass through to the host, disturbs me somewhat.  [...]
> I can't really speak to how good an idea or not this is, however I
> have written some code to do something similiar, pushing all the
> internal gallium API over a pipe to a GL renderer on the other side of
> the pipe. It isn't complete, it was only a stepping stone on my
> research to qemu 3D work.

Thank you, that looks very interesting.  I will need a bit of time to 
get into the code, but for a start the shader conversion code looks very 
understandably written.  If I turn it into a driver like I described, is 
it something you would be interested in interfacing to? By the way, is 
the code under the usual Mesa licence?

> The biggest issue I see with doing something like that is how to make
> final display of things to the X server and making things like texture
> from pixmap work efficiently.

We already have code to push OpenGL calls to the graphics card on the 
host system, so this would just be an additional layer of indirection. 
Regarding texture to pixmap, I was thinking of making our DDX use this 
interface too for creating and manipulating pixmaps.  All buffers 
created by a VirtualBox guest with accelerated 3D are just buffers 
created on the host by the VirtualBox process, and DDX pixmaps would 
then also be host buffers, so interchangeable with textures.  (Hope that 
makes sense.  It is getting rather late here...)



> The stuff I've done is on the renderer-1 branch of my mesa repo
> http://cgit.freedesktop.org/~airlied/mesa/log/?h=renderer-1
> but its moved on a lot from that point, and I doubt the pipe code I
> wrote even builds anymore, since I've mostly moved to testing it as
> part of qemu now. But it currently just passes TGSI shaders through
> and converts them into GLSL using an assembler that will look
> something like the one in wine I suspect.
> Dave.

ORACLE Deutschland B.V. & Co. KG   Michael Thayer
Werkstrasse 24                     VirtualBox engineering
71384 Weinstadt, Germany           mailto:michael.thayer at oracle.com

Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher

More information about the mesa-dev mailing list