qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrzej Zaborowski
Subject: [Qemu-devel] [PATCH 0/6] OpenGL passthrough support once again
Date: Mon, 9 Jan 2012 08:57:50 +0100

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

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)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]