[Qemu-devel] [PATCH] Experimental initial patch providing accelerated OpenGL for Linux i386 (2nd attempt to post)

[Even Rouault]

Here's an attempt of providing accelerated OpenGL for QEMU.
I must underline first that it should really really be considered as 
experimental or a proof-of-concept. There's
still a lot of work to do to make it reliable and releasable.
So what is it exactly ?
- a patch for QEMU itself that intercepts any call to 'int $0x99' which is the 
interface I have chosen to dedicate to
  communication between guest user programs and QEMU. The modification of QEMU 
existing code is very slight.
  The essential of code on the guest side is in new files.
- a replacement libGL.so library that must be used inside the Linux guest. The 
library redirects guest OpenGL and GLX calls
  to host side, where your host libGL.so will do the real job.

It works currently only with Linux x86 as guest and host OS.

Now, the good news : which programs do currently work with this patch ?
- glxinfo
- glxgears. I get ~330 FPS with QEMU/GL (direct GLX), ~210 FPS through a SSH 
console on the guest OS (indirect GLX)
- some mesa demos programs.
    * tunnel     : ~26 FPS with QEMU/GL,  ~3 FPS through a SSH console on the 
guest OS
    * teapot     : ~50 FPS with QEMU/GL,  ~7 FPS through a SSH console on the 
guest OS
    * fire       : ~14 FPS with QEMU/GL,  ~2 FPS through a SSH console on the 
guest OS
    * arbfplight : ~100 FPS with QEMU/GL,  not possible through a SSH console 
on the guest OS (GL_ARB_vertex_program not available)
- ... and ppracer ! (some crash from time to time. Starting at ~20 FPS at the 
beginning of the race, and finishing at ~10 FPS... strange...)

How fast is it ? Enough fast to have 15 FPS in ppracer with KQEMU disabled.
When KQEMU is enabled, paradoxically, the performance is really poor :-(

Successfully tested on the following platforms :
- Ubuntu Edgy x86 as host with ATI FGLRX driver / FC5 x86 as guest
- Ubuntu Dapper x86 as host with NVIDIA Proprietary driver / Ubuntu Dapper x86 
as guest

Which programs do not work : probably most for the moment ;-)
I'd like to make it work with XGL (I've downloaded the latest Mandriva 2007 
Live CD and I'm quite
impatient to enable the 3D in it) and GoogleEarth.

How to use it ? (ONLY on Linux i386 and with only i386-softmmu as target-list)
* Apply the patch and recompile QEMU 
* Lauch QEMU with -enable-gl option
* Get the compiled libGL.so from ./i386-softmmu and copy it to the guest OS
* In the guest OS : LD_LIBRARY_PATH=/path/to/replacement/libGL.so glxgears

TODO list :
- implement correctly full OpenGL API
- improve vertex arrays support
- maybe fix how the end of the guest process is detected
- make replacement libGL work when compiled with optimization flags
- integrate in a better way the window that popups on the guest side with the 
main qemu window
- integrate it properly into QEMU build system (helper_opengl.c can't compile 
with -O2 : 'unable to find a register to spill in class `DIREG'')
- understand why it's slower when KQEMU enabled and try to fix that if 
possible
- enable several guest OS processes to use OpenGL at the same time
- make it run on x86_64, and allowing any combination guest x86/x86_64 and 
host x86/x86_64, other archs
- port it to other UNIX-like OS with X
- improve security if possible (preventing malicious guest code from crashing 
host qemu)
- clean the code !
- much testing and debugging
- port it to Windows platform (first OpenGL / WGL, then D3D through Wine 
libs ?)
- make a patch to Valgrind to make it happy with 'int $0x99' when running on 
guest side
- ...

The new files :
- opengl_client.c  : the OpenGL guest library
- helper_opengl.c : main guest-side code
- gl_func.h, server_stub.c, client_stub.c : generated files by parse_gl_h.c 
from gl.h parsing
- glgetv_cst.h  : generated file from parsing of a man page
- gl_func_perso.h, opengl_func.h : hand-written "prototypes"

In the mean time, enjoy !

PS :
I posted a similar message thursday, but it didn't get to the list apparently, 
maybe because of the two big attached patch (500 kB). I have reduced the size 
of the patch to 160 KB by not including generated source files. I will send 
it just after, so this message has a chance of coming. If you don't see a 
following message with the patch attached, I'll have to figure out where to 
store the patch...