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: Even Rouault
Subject: Re: [Qemu-devel] [PATCH] Experimental initial patch providing accelerated OpenGL for Linux i386 (2nd attempt to post)
Date: Sat, 18 Nov 2006 13:59:24 +0100
User-agent: KMail/1.9.5

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




reply via email to

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