[Mesa-dev] Mesa driver for VirtualBox

[Dave Airlie]

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.  Gallium3D would have the
> advantage that it is a much smaller target surface (if I may use that word)
> than OpenGL.  It has the disadvantage that it is closer to D3D than to
> OpenGL, which may be better for modelling hardware, but perhaps less so for
> proxying OpenGL APIs on a guest to OpenGL APIs on a host.  In particular 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.  Of course, I realise that
> on the other hand this potentially gives us access to shaders in different
> formats, but our main target will still be OpenGL on OpenGL for the
> immediately forseeable future.  I understand that Gallium3D receives shaders
> in a format close to compiled D3D shaders, which suggests that WineD3D might
> be of use.  An alternative is to go straight for a DRI driver rather than a
> Gallium3D one.  I would be interested in any thoughts and suggestions!
>
> For background, I have some knowledge of 3D programming but am certainly no
> expert.  I can browse the Mesa source code and the drivers in it without
> getting too worried, but need to use a search engine as I do so to feel
> confident that I understand what is happening in the code.
>

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.

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.

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.