[Top][All Lists]

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

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

From: Fabrice Bellard
Subject: Re: [Qemu-devel] [PATCH] Experimental initial patch providing accelerated OpenGL for Linux i386 (2nd attempt to post)
Date: Sat, 18 Nov 2006 18:40:51 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913

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.


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 ?


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



reply via email to

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