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

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

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

[Even Rouault]

I've found some free storage online site... If someone knows some other 
alternatives, I'll be interested in.

Here's a link to download the patch : 
http://www.4shared.com/file/6018776/13812e35/qemu_opengl.html

If it doesn't work, go to http://www.4shared.com/, and log as 
opengl@patches.com, password opengl_patches

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

[Fabrice Bellard]

Hi,

I find your patch interesting and I'll try to include it in QEMU ASAP.

My main remark is that the host/guest communication system must be 
changed and I can help you to implement it. I would prefer to use a PCI 
device and to avoid any i386 dependent code. For the PCI device, using 
the Bochs VGA adapter could be a possible idea. All the parameters and 
data should be transmitted as if the PCI device was doing DMA. A single 
I/O port could be used to start executing a list of OpenGL commands.

Once a basic Linux target OpenGL library is OK, it would be good to work 
on the equivalent Windows guest code by reusing the wine D3D code...

Regards,

Fabrice.

Even Rouault wrote:
> 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
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> 

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

[Paul Brook]

> My main remark is that the host/guest communication system must be
> changed and I can help you to implement it. I would prefer to use a PCI
> device and to avoid any i386 dependent code. For the PCI device, using
> the Bochs VGA adapter could be a possible idea. All the parameters and
> data should be transmitted as if the PCI device was doing DMA. A single
> I/O port could be used to start executing a list of OpenGL commands.

I agree, except please make it a memory mapped region rather than an actual IO 
port. This makes it easier to implement on non-x86 architectures. Most CPUs 
don't have a native IO port space like x86 does.

Paul

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

[Stefan Kombrink]

[-- Attachment #1: Type: text/plain, Size: 4833 bytes --]

2006/11/16, Even Rouault <even.rouault@mines-paris.org>:
>
> 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
> Qemu-devel@nongnu.org
> 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^)

[-- Attachment #2: Type: text/html, Size: 5549 bytes --]

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

[Laurent Desnogues]

Even Rouault a écrit :
> TODO list :
> - implement correctly full OpenGL API

Did you consider taking a look at how Wine wraps OpenGL and/or
how Mesa makes its dispatchers?  I think they may be of use,
and their license should be compatible :)


			Laurent

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

[Even Rouault]

Le Jeudi 16 Novembre 2006 23:41, vous avez écrit :
> My main remark is that the host/guest communication system must be
> changed and I can help you to implement it. I would prefer to use a PCI
> device and to avoid any i386 dependent code. For the PCI device, using
> the Bochs VGA adapter could be a possible idea. All the parameters and
> data should be transmitted as if the PCI device was doing DMA. A single
> I/O port could be used to start executing a list of OpenGL commands.

Hi,

I would indeed appreciate help, or at least some pointers to start in the 
direction you propose, as I know hardly anything about hardware programming, 
such as PCI, memory mapped region, DMA, etc... So my questions may sound very 
naive.
As you stated, the current solution is i386 dependent, but this dependancy is 
very thin, so I imagined that it should possible to find equivalent of the 
current int 0x99 trap for other architectures.
Apart from portability to other architectures, what would be the other 
advantages of a solution based on a PCI device ? Better security ? Better 
performance when KQEMU is enabled ?
I've looked at vga.c and I've the feeling that with 
cpu_register_io_memory/cpu_register_physical_memory  you can install callback 
functions that will intercept reads/writes to a range of the physical memory 
of the target machine. Am I right ? 
But I don't see how the replacement libGL can read/write physical memory from 
a userland process. I suppose it needs some special priviledges to use for 
example a ioctl, or maybe writing a kernel module. So it would become guest 
OS dependant. Furthermore, doesn't this solution imply more memcpy that may 
affect performance ? Currently, if a memory range of a guest process (let's 
say a texture) is by chance mapped contiguously into guest physical memory, 
we don't need to do any copy before passing it to the host libGL, though I've 
not benchmarked if it really improves performance.


Regards,
Even

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

[Fabrice Bellard]

Even Rouault wrote:
> Le Jeudi 16 Novembre 2006 23:41, vous avez écrit :
> 
>>My main remark is that the host/guest communication system must be
>>changed and I can help you to implement it. I would prefer to use a PCI
>>device and to avoid any i386 dependent code. For the PCI device, using
>>the Bochs VGA adapter could be a possible idea. All the parameters and
>>data should be transmitted as if the PCI device was doing DMA. A single
>>I/O port could be used to start executing a list of OpenGL commands.
> 
> 
> Hi,
> 
> I would indeed appreciate help, or at least some pointers to start in the 
> direction you propose, as I know hardly anything about hardware programming, 
> such as PCI, memory mapped region, DMA, etc... So my questions may sound very 
> naive.
> As you stated, the current solution is i386 dependent, but this dependancy is 
> very thin, so I imagined that it should possible to find equivalent of the 
> current int 0x99 trap for other architectures.
> Apart from portability to other architectures, what would be the other 
> advantages of a solution based on a PCI device ? Better security ? Better 
> performance when KQEMU is enabled ?

The PCI device is not necessarily an advantage is terms of performance 
and it will be more complicated to implement on both the host and the 
guest. But it is better in terms of security and it avoids adding 
unnecessary hacks in the CPU core (for example, I consider the use of 
virtual addresses as a hack).

> I've looked at vga.c and I've the feeling that with 
> cpu_register_io_memory/cpu_register_physical_memory  you can install callback 
> functions that will intercept reads/writes to a range of the physical memory 
> of the target machine. Am I right ? 

Yes.

> But I don't see how the replacement libGL can read/write physical memory from 
> a userland process. I suppose it needs some special priviledges to use for 
> example a ioctl, or maybe writing a kernel module. So it would become guest 
> OS dependant. Furthermore, doesn't this solution imply more memcpy that may 
> affect performance ? Currently, if a memory range of a guest process (let's 
> say a texture) is by chance mapped contiguously into guest physical memory, 
> we don't need to do any copy before passing it to the host libGL, though I've 
> not benchmarked if it really improves performance.

You have no choice but adding a kernel module to handle the transfers to 
and from the PCI device. Basically you must write a small XFree DRM like 
kernel driver. Since the PCI device will only handle physical memory, 
the kernel driver will convert the virtual addresses to physical 
addresses and ensure that the corresponding pages are not swapped out by 
the guest OS. The PCI device must handle lists of physical I/O regions 
so that no memcpy will be needed to do the transfers (scatter/gather 
DMA). The performance should be the same as your current implementation.

Moreover, your protocol could handle queueing of several OpenGL commands 
in a FIFO because "int 0x99" or the equivalent PCI write command takes 
some time to execute, especially when using kqemu where an exception is 
raised.

Another point is that I fear that your current use of glX is not 
portable and can lead to subtle problems. You should rely on SDL/OpenGL 
on the host side and leave glX on the guest OS.

All in all, what I propose gets very close to adding something like a 
real 3d VGA device in QEMU and a new 3d driver in X11 !

[My intend before your submission was to emulate a recent Intel 3d card 
because their protocols are mostly documented now (at least in the X11 
source !) and because these recent cards support higher level 3d 
operations such as hardware 3d transformations. My guess is that 
converting their DMA commands to OpenGL is easy.

As writing an Intel 3d emulation would take time and is likely to be 
very complicated to tune for closed source guest OSes, I think it is 
safer to begin by improving your proposal.]

Regards,

Fabrice.

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

[Avi Kivity]

Even Rouault wrote:
> Apart from portability to other architectures, what would be the other 
> advantages of a solution based on a PCI device ?
>   

I can think of a two advantages:

 - the device can deliver interrupts to the guest when something is 
completed (I don't know how useful this is to a 3D device)
 - the guest can autodetect the presence of the device by means of a PCI 
ID.  This means that if the guest driver is eventually included in the 
OS (which is possible in Linux), then the driver will be loaded 
automatically by the OS.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

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

[Kazu]

[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]

Sent: Friday, November 17, 2006 5:34 AM Even Rounault wrote:

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

I tried your patch and found some problems.

j<=4 should be j<4 in is_known_arg_vector function.
There are local and global attribDouble[] in helper_opengl.c so that I can't
compile the program on Fedora Core 4/gcc 3.2 host. I think it is probably a
bug of gcc. I deleted the local one to compile it. I can't compile
helper_opengl.c by using -O2 option.

I attached a patch that fix above and more fix warnings. It can be applied
by patch -p1 on my FC4 and gcc32 host.

I copied libGL.so to a FC3 guest and made a link to libGL.so.1 because
glxgears demands libGL.so.1.

guest >$ ln -s libGL.so libGL.so.1

And LD_LIBRARY_PATH sets path to library. So if libGL.so.1 is in current
directory, commands should be '.'  or directory name.

guest >$ LD_LIBRARY_PATH=. glxgears

When there is no acceleration, glxgears is 24 FPS. When accelerated, it
becomes 170 FPS. On host, it is 670 FPS.
It is about 1/4 of host OS. Good work!

Regards,
Kazu

[-- Attachment #2: qemu-20061120-gl.patch.bz2 --]
[-- Type: application/octet-stream, Size: 24811 bytes --]