From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNa0V-0001CD-Uy for qemu-devel@nongnu.org; Thu, 15 Jan 2009 16:44:08 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNa0U-0001Aa-5o for qemu-devel@nongnu.org; Thu, 15 Jan 2009 16:44:07 -0500 Received: from [199.232.76.173] (port=37536 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNa0T-0001AR-QF for qemu-devel@nongnu.org; Thu, 15 Jan 2009 16:44:05 -0500 Received: from mx2.redhat.com ([66.187.237.31]:53182) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LNa0S-0000iC-Ug for qemu-devel@nongnu.org; Thu, 15 Jan 2009 16:44:05 -0500 Message-ID: <496FADA7.9000404@redhat.com> Date: Thu, 15 Jan 2009 22:41:59 +0100 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] [RFC] Variable video ram size option 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> <20090115205743.GF5440@shareable.org> In-Reply-To: <20090115205743.GF5440@shareable.org> Content-Type: text/plain; charset=ISO-8859-1 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 Cc: Paul Brook Jamie Lokier wrote: > 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? Has been quite a while that I looked closer at the fb code and followed fb development. IIRC it has to do something with the scrollback (Shift-PgUp/Down) implementation: The video memory is used as scrollback buffer. Thus some information is kept in the video memory *only*. > My experience with real hardware is it makes scrolling noticably faster. Well, maybe it has been changed then. I remember having seen some discussion on changing the scrollback implementation to not depend on video memory, which could have fixed this too. cheers, Gerd