[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: |
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
- [Qemu-devel] [PATCH] Experimental initial patch providing accelerated OpenGL for Linux i386 (2nd attempt to post), Even Rouault, 2006/11/16
- Re: [Qemu-devel] [PATCH] Experimental initial patch providing accelerated OpenGL for Linux i386 (2nd attempt to post), Even Rouault, 2006/11/16
- Re: [Qemu-devel] [PATCH] Experimental initial patch providing accelerated OpenGL for Linux i386 (2nd attempt to post), Fabrice Bellard, 2006/11/16
- Re: [Qemu-devel] [PATCH] Experimental initial patch providing accelerated OpenGL for Linux i386 (2nd attempt to post), Stefan Kombrink, 2006/11/17
- Re: [Qemu-devel] [PATCH] Experimental initial patch providing accelerated OpenGL for Linux i386 (2nd attempt to post), Laurent Desnogues, 2006/11/17
- Re: [Qemu-devel] [PATCH] Experimental initial patch providingaccelerated OpenGL for Linux i386 (2nd attempt to post), Kazu, 2006/11/19