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

[Fabrice Bellard <fabrice@bellard.org>]

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.