From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KcM9r-0008CV-KI for qemu-devel@nongnu.org; Sun, 07 Sep 2008 11:26:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KcM9m-000825-R0 for qemu-devel@nongnu.org; Sun, 07 Sep 2008 11:26:35 -0400 Received: from [199.232.76.173] (port=44228 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KcM9m-00081q-IG for qemu-devel@nongnu.org; Sun, 07 Sep 2008 11:26:30 -0400 Received: from toccata.ens-lyon.org ([140.77.166.68]:42583) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KcM9m-0001vI-7e for qemu-devel@nongnu.org; Sun, 07 Sep 2008 11:26:30 -0400 Date: Sun, 7 Sep 2008 17:12:54 +0200 From: Samuel Thibault Subject: Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window Message-ID: <20080907151254.GP4307@implementation> References: <48B81423.9050502@eu.citrix.com> <200809071536.51498.paul@codesourcery.com> <20080907144221.GN4307@implementation> <200809071603.31181.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200809071603.31181.paul@codesourcery.com> Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org Paul Brook, le Sun 07 Sep 2008 16:03:30 +0100, a =E9crit : > On Sunday 07 September 2008, Samuel Thibault wrote: > > Paul Brook, le Sun 07 Sep 2008 15:36:51 +0100, a =E9crit : > > > > Ideally, once switched to fullscreen you could just let the guest > > > > directly write to the actual video memory (particularly interesti= ng for > > > > Xen and KVM). > > > > > > You really don't want to have the guest writing directly to host vi= deo > > > ram. Video ram tends to be high-latency, so you want to write to re= gular > > > memory, then use a wide block transfer or DMA to copy to video ram. > > > > How often? =20 >=20 > You probably want to sync the updates to the vertical refresh. Updating= more=20 > often than that is pointless. Sure. > > Which part(s) of the framebuffer?=20 >=20 > Whichever parts have changed. Sure, how do you detect that? The previous Xen memcmp method was eating 10% cpu for a 30Hz refresh, just for the memcmp. Now it uses the pagetable dirty bits and after some idleness, trapping, but having the guest just write to actual video memory (when it _has_ to be shown on the screen anyway) seems the fastest way. Samuel