qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] Experimental initial patch providing accelerate


From: Stefan Kombrink
Subject: Re: [Qemu-devel] [PATCH] Experimental initial patch providing accelerated OpenGL for Linux i386 (2nd attempt to post)
Date: Fri, 17 Nov 2006 08:16:02 +0100



2006/11/16, Even Rouault <address@hidden>:
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...


_______________________________________________
Qemu-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Congrats!

I find this very promising.
Seems like in the upcoming era of XGL and Vista there will be faster drawing speeds with qemu possible finally :)

SK >8^)

reply via email to

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