On 20/06/13 23:37, Dave Airlie wrote:
On Fri, Jun 21, 2013 at 12:47 AM, Michael Thayer
<michael.tha...@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...)
Regards,
Michael
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.tha...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
