From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KcMJh-0004bR-CV
	for qemu-devel@nongnu.org; Sun, 07 Sep 2008 11:36:45 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KcMJe-0004au-Vo
	for qemu-devel@nongnu.org; Sun, 07 Sep 2008 11:36:44 -0400
Received: from [199.232.76.173] (port=49007 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KcMJe-0004ap-H8
	for qemu-devel@nongnu.org; Sun, 07 Sep 2008 11:36:42 -0400
Received: from mail.codesourcery.com ([65.74.133.4]:35364)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1KcMJe-0003H8-4e
	for qemu-devel@nongnu.org; Sun, 07 Sep 2008 11:36:42 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window
Date: Sun, 7 Sep 2008 16:35:54 +0100
References: <48B81423.9050502@eu.citrix.com>
	<200809071603.31181.paul@codesourcery.com>
	<20080907151254.GP4307@implementation>
In-Reply-To: <20080907151254.GP4307@implementation>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200809071635.54858.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: qemu-devel@nongnu.org

> > > Which part(s) of the framebuffer?
> >
> > 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.

Page granularity dirtyness is trivial. In fact qemu already does this. I'd be 
surprised if finer granularity gave any real benefit.

It also depends what testcase you're benchmarking. A few pixels changing every 
frame is IMHO not a particularly interesting case. The only time this really 
happens is mouse movement, and there are better ways of fixing that (proper 
hardware mouse cursors). The interesting cases are guest completely idle, and 
large screen updates.

Paul