From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DLd28-0006WM-O7 for qemu-devel@nongnu.org; Wed, 13 Apr 2005 04:15:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DLd22-0006VY-Op for qemu-devel@nongnu.org; Wed, 13 Apr 2005 04:15:32 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DLcrn-000484-To for qemu-devel@nongnu.org; Wed, 13 Apr 2005 04:04:55 -0400 Received: from [217.204.41.189] (helo=kula.newsnow.net) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DLcsc-0008JT-3z for qemu-devel@nongnu.org; Wed, 13 Apr 2005 04:05:46 -0400 Received: from r3j188.chello.upc.cz ([213.220.201.188] helo=[192.168.0.4]) by kula.newsnow.net with esmtp (Exim 3.35 #1 (Debian)) id 1DLcs8-0004OS-00 for ; Wed, 13 Apr 2005 09:05:16 +0100 Message-ID: <425CD2F0.2030400@praguespringpeople.org> Date: Wed, 13 Apr 2005 10:06:08 +0200 From: Struan Bartlett MIME-Version: 1.0 Subject: Re: [Qemu-devel] qvm86, kqemu and video speed References: <425A84B0.60200@praguespringpeople.org> <20050412183843.1a3ad827@caprice.artificis.hu> <425C21E8.6090306@bellard.org> In-Reply-To: <425C21E8.6090306@bellard.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Fabrice Bellard wrote: > Alex Beregszaszi wrote: > >>> Struan Bartlett wrote: >>> >>> I understand qvm86 and kqemu provide some virtualisation of the host >>> machine, including allowing the guest some direct memory access. Is >>> it conceivable for these modules to be extended to allow the guest >>> machine to directly write to host video memory, or else to a host >>> memory buffer that is copied into the Qemu window? >> >> I'm working on such a Direct Host Graphics custom "videocard". > > You can do that, but there is also a lot of optimisation opportunities > in the existing Cirrus driver. My feeling is that using a driver for a > virtual card will add only marginal gains (except in 3d) for a bigger > amount of work (you need specific drivers in the guest OSes). > > For example, in the Cirrus driver, it could be possible for the > virtual CPU to access the virtual frame buffer (currently a callback > is always used). A specific virtual CPU support is needed to change > dynamically the type of a physical memory mapping - that's why I did > not implement it when I enhanced the Cirrus driver. It will be even > more critical soon with a more optimized version of kqemu. Thanks Fabrice for Qemu and for your input to this question. What you describe sounds like the sort of thing I was imagining. Are you suggesting your next version of kqemu will provide the "specific virtual CPU support" needed to do this? If so, please keep us posted. > Moreover, it could be possible to suppress one memcpy from the virtual > frame buffer to the SDL/X11 frame buffer, and another memcpy if full > screen mode is used (in this case, the virtual CPU accesses directly > the host frame buffer). > > Finally, the Cirrus bitblt operations could be redirected to the > corresponding X11 DGA operations in full screen mode. Or, do you think, as James Mastros suggested, the corresponding SDL operations in non-full-screen mode? Struan