

It's working with the proprietary NVIDIA/AMD drivers and the Intel classic Mesa driver, but not much else in terms of the other Mesa / Gallium3D drivers. This part is not dependent upon QEMU but just having a host with OpenGL 2.1+ support. There's also another library in-development that does the EGL / GLES 1.1 / GLES 2.0 translations to GLX, Windows GL, and Apple GL. This would also be needed for potential upstream QEMU acceptance.

This component though is targeted for being rewritten so that it's much cleaner. There's then some hacked-up QEMU code that reads these OpenGL ES calls from registers and copies the buffers from the guest user-space memory to host user-space. This fake library passes the calls onto a kernel module via iomem. This Ubuntu-developed OpenGL QEMU acceleration method works by having a fake OpenGL ES library on the guest that implements the EGL, OpenGL ES 1.1, and OpenGL ES 2.0 APIs. This would also make it possible to use Canonical's Unity desktop in a virtualized environment.Ĭode was already written to accelerate OpenGL in QEMU when using x86 software on the guest and host, followed by support for an ARM guest on an x86 system, and then a library was also written for translating OpenGL ES calls to OpenGL. The need for OpenGL ES 2.0 support in QEMU guests has come up since it's used in emulating Maemo / MeeGo for development environments.

One of the items brought up this week at UDS Budapest was about providing OpenGL / OpenGL ES support for QEMU guests.
