[Mesa-dev] Mesa driver for VirtualBox

Dave Airlie airlied at gmail.com
Mon Jun 24 14:38:17 PDT 2013

> 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?

yes its all under standard license, I suspect the shader convertor is
simple because its incredibly naive, I just got things to a stage now
where piglit actually finishes without nuking my VMs and I suspect a
lot of the failure is due to the shader convertor! Though I'm pushing
changes to the shader convertor quite often, at the moment I'm using
the TGSI text across the wire, though I'm not 100% that is the best
plan going forward as TGSI text isn't currently versioned and we do
add features to it.

Well so far I've no real official plans for this code, Red Hat is
currently just letting me do the research on what a possible 3D virt
solution for qemu might look like and I'll probably make some sort of
announcement in a few weeks if I get it to run gnome-shell smoothly,
and not upside down. So you can use the code and if you want to make
some of it shared I'm happy to contribute to something common. I've
pushed a few fixes to the shader code over the last few days now that
I have some piglit coverage.

> 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...)

I suspect the main overhead then is just going to be pushing data
transfers via the shared memory will add an extra copy, this'll suck
mostly for vertex upload where at least in my testing of openarena is
where most things slow down.

More information about the mesa-dev mailing list