Re: [Qemu-devel] [PATCH 0/6] OpenGL passthrough support once again

[Alon Levy]

On Mon, Jan 09, 2012 at 08:57:50AM +0100, Andrzej Zaborowski wrote:

Hi Andrzej,

> This is the host part of an OpenGL passthrough framework to make apps
> run faster.  It has initially lived on nongnu.org as a separate project
> by Even Rouault, later was picked up by me to use in the Poky
> meta-distribution and later was picked up by various platform SDKs
> for application developers.  It's still evolving but it would be good
> to reduce maintaining cost and parallel evolution in different trees
> by having it upstream.
> 
> In 2010 Ian Molton started a discussion about it [1] and got some
> feedback which I tried to address in these patches.  The code has gone
> through major refactoring but I may have missed some things not having
> the distance when looking at the code.  Suggestions welcome.
> 
> Some discussion points:
> 
> One of Anthony's comments in the old thread was that this could be a
> temporary solution but where we really should be heading is towards a
> paravirtual VGA (like the vmware-svga or the Spice one) that will be
> OpenGL independent and secure.  While having such a thing would be
> good, it's less likely to achieve near 1:1 performace and performance
> is the whole point of the passhtrough.  Also it's apparently quite
>  difficult to do, but seems that VMWare have managed it, so it's
> possible.  I'd personally prefer to put effort in the emulation of
> one of the real moden GPUs instead.

I think you are right to push a passthrough implementation into qemu,
for one it gives something working now. Not sure the performance will be
any different then a paravirtual approach (just talking about server
side rendering here), since it's basically doing the same thing, but it
would certainly be simpler.

Do you have further thoughts about real GPU emulation? would you target
an ATI (AMD) GPU, since they released specs?

> 
> I think instead of going towards a paravirtual vga, this should be
> going in the direction of a generic, almost-no-overhead virtio-based
> RPC mechanism.  From what I read qmp provides a json based RPC
> mechanism, this is totally not what we want here.  What I'd want is
> a very simple binary RPC where, optimally, big buffers can be passed
> as parameters to remote function calls with no single memcpy.  This
> could be done by having a guest kernel driver allocate continuous
> physical memory chunks on requests and pass physical addresses to host.

qmp is not suitable for this, sure. Something like the qxl/svga device
would work fine - you have a BAR for the continuous allocations. You
could also do a device like that based on virtio queues.

> 
> In any case, Anthony suggested that instead of using a separate
> virtio protocol we use virtio-serial transport as a first stab and
> this is what I do in this series.  It has a couple of disadvantages,
> but it works.  The "serial-transport" branch of
> https://meego.gitorious.org/meego-developer-tools/meego-emulator-libgl-x86
> should be used on the guest.
> 
> As has been mentioned in the old thread, the passthrough code does
> not attempt to be secure at this point, the guest software needs
> to be fully trusted.  This is similar to the problems Web GL is
> supposedly having with security, but I find that the OpenGL API
> actually lends itself to buffer size checks etc., so it can be
> done and I'm probably going to work on it.  Hopefully without
> compromising performance.
> 
> It has been tested with some Nvidia, Intel and ATI cards on the
> host at different points in time, and usually this didn't make
> much difference.  I've done my testing with MacOS and Linux as
> hosts, Windows is also supported but I haven't really had a
> chance to ever test it, hopefully my refactoring has not broken
> it too badly.
> 
> In the Meego SDK this same code was being used to accelerate GL ES
> applications by using libdgles2 on the guest to translate GL ES
> into OpenGL.  I imagine the same thing could be done for Direct X
> support using some Wine libraries.
> 
> 1. http://thread.gmane.org/gmane.linux.kernel/1045340
> 
> (Actual authors of each file are listed in the file headers, not
> in the Signed-off-by)

You can change the author of the patches with git commit --amend --author __,
seems a little nicer.

Running scripts/check-patch.pl on these I get multiple errors, but I
guess you are waiting for some input before fixing those..

> 
> Andrzej Zaborowski (6):
>   gl: Add an OpenGL offscreen rendering API and backends.
>   gl: Add mesa OpenGL headers.
>   gl: OpenGL passthrough implementation.
>   virtio-serial: Call .guest_ready when new space is available in the queue.
>   gl: virtio-serial port driver for OpenGL passthrough.
>   gl: -enable-gl run time switch to enable the GL virtio port.
> 
>  Makefile.target             |   17 +-
>  configure                   |   42 +
>  gl/beginend_funcs.sh        |   41 +
>  gl/gloffscreen-common.c     |  579 ++++
>  gl/gloffscreen-wgl.c        |  832 +++++
>  gl/gloffscreen-xcomposite.c |  518 +++
>  gl/gloffscreen.h            |  138 +
>  gl/mesa_gl.h                | 2251 +++++++++++++
>  gl/mesa_glext.h             | 7279 
> +++++++++++++++++++++++++++++++++++++++++++
>  gl/mesa_glu.h               |  354 +++
>  gl/mesa_mipmap.c            |  826 +++++
>  gl/mesa_mipmap.h            |   27 +
>  gl/parse-gl-h.c             | 1480 +++++++++
>  gl/range_alloc.h            |  195 ++
>  gl/vmgl-exec.c              | 3300 ++++++++++++++++++++
>  gl/vmgl-func-perso.h        |  120 +
>  gl/vmgl-func.h              |  611 ++++
>  gl/vmgl-process.h           |   32 +
>  gl/vmgl.h                   |   34 +
>  hw/virtio-gl-port.c         |  241 ++
>  hw/virtio-serial-bus.c      |    8 +
>  qemu-options.hx             |   24 +
>  vl.c                        |   36 +
>  23 files changed, 18984 insertions(+), 1 deletions(-)
>  create mode 100644 gl/beginend_funcs.sh
>  create mode 100644 gl/gloffscreen-common.c
>  create mode 100644 gl/gloffscreen-wgl.c
>  create mode 100644 gl/gloffscreen-xcomposite.c
>  create mode 100644 gl/gloffscreen.h
>  create mode 100644 gl/mesa_gl.h
>  create mode 100644 gl/mesa_glext.h
>  create mode 100644 gl/mesa_glu.h
>  create mode 100644 gl/mesa_mipmap.c
>  create mode 100644 gl/mesa_mipmap.h
>  create mode 100644 gl/parse-gl-h.c
>  create mode 100644 gl/range_alloc.h
>  create mode 100644 gl/vmgl-exec.c
>  create mode 100644 gl/vmgl-func-perso.h
>  create mode 100644 gl/vmgl-func.h
>  create mode 100644 gl/vmgl-process.h
>  create mode 100644 gl/vmgl.h
>  create mode 100644 hw/virtio-gl-port.c
> 
> -- 
> 1.7.4.4
> 
>