From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNZHl-0007MG-J2 for qemu-devel@nongnu.org; Thu, 15 Jan 2009 15:57:53 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNZHk-0007Lb-4J for qemu-devel@nongnu.org; Thu, 15 Jan 2009 15:57:53 -0500 Received: from [199.232.76.173] (port=59284 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNZHj-0007LQ-Uj for qemu-devel@nongnu.org; Thu, 15 Jan 2009 15:57:51 -0500 Received: from mail2.shareable.org ([80.68.89.115]:39448) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LNZHj-0002eq-BJ for qemu-devel@nongnu.org; Thu, 15 Jan 2009 15:57:51 -0500 Date: Thu, 15 Jan 2009 20:57:43 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] [RFC] Variable video ram size option Message-ID: <20090115205743.GF5440@shareable.org> References: <496B965A.9000701@eu.citrix.com> <200901142007.42812.paul@codesourcery.com> <496E4E00.3060105@eu.citrix.com> <200901142130.00991.paul@codesourcery.com> <496E6B93.2080107@eu.citrix.com> <20090115130848.GB32368@shareable.org> <5E237914-B830-420A-99BE-4C1959DDFC66@exactcode.de> <20090115162347.GA5440@shareable.org> <496F740C.7000405@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <496F740C.7000405@redhat.com> 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 Cc: Paul Brook Gerd Hoffmann wrote: > Jamie Lokier wrote: > > I don't know why "ypan" is off by default; > > Performance. When reaching the end of video memory ypan does a memcpy > on the framebuffer. ywrap doesn't need the memcpy, but doesn't work on > all hardware. The memcpy is painful slow because framebuffer *read* > access isn't something gfx cards are optimized for. Why read the framebuffer at all? In fact why even redraw everything, when you can redraw only the text which changes during scroll, which is what vesafb does by default for normal scrolling? > > If you're using Linux guest with VESA framebuffer console, rather than > > a text-mode console, I'd recommend kernel boot option "video=vesafb:ypan", > > to save considerable CPU when scrolling the console. > > Should work inside qemu because you should not face the slow-reads issue > then. On real hardware it very likely makes scrolling noticeable slower. My experience with real hardware is it makes scrolling noticably faster. -- Jamie