From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LLSwm-00055V-8B for qemu-devel@nongnu.org; Fri, 09 Jan 2009 20:47:32 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LLSwl-00054J-GY for qemu-devel@nongnu.org; Fri, 09 Jan 2009 20:47:31 -0500 Received: from [199.232.76.173] (port=39584 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LLSwl-00054D-Dl for qemu-devel@nongnu.org; Fri, 09 Jan 2009 20:47:31 -0500 Received: from mail2.shareable.org ([80.68.89.115]:42703) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LLSwk-0008Lt-Mo for qemu-devel@nongnu.org; Fri, 09 Jan 2009 20:47:30 -0500 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1LLSwi-0001NT-OK for qemu-devel@nongnu.org; Sat, 10 Jan 2009 01:47:28 +0000 Date: Sat, 10 Jan 2009 01:47:28 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] [RFC] Variable video ram size option Message-ID: <20090110014728.GG1972@shareable.org> References: <4967A96B.3020902@eu.citrix.com> <200901091716.00827.paul@codesourcery.com> <4967ECA7.6040809@eu.citrix.com> <200901091747.06462.paul@codesourcery.com> <4967F9C9.3060504@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4967F9C9.3060504@eu.citrix.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 Trolle Selander wrote: > Paul Brook wrote: > >>Trying hard to think up a use for more than 16 Megs in the current case, > >> > > > >I'm pretty sure the current device allows the guest to do page flipping > >(using an oversize virtual framebuffer). > > > >Paul > > > I could have sworn I checked that at some point and found that it > didn't, but looking at the vgabios code now it looks like it's all > implemented. That definitely bumps the useable limit to 32 Megs even in > the current case. Thanks for catching this, I'll add it to the fix list. For games _triple_ buffering is a common technique when there's enough RAM. With double buffering, after you flip away from screen 0 to screen 1, you have to pause until the next vsync before it's safe to draw a new image on screen 0. With triple buffering, this pause isn't required which makes games (etc.) able to run at a higher average frame rate. (More buffers can smooth the average further, which is more useful when playing video than games, because it adds latency but hides individual frame drawing time spikes. But it's not that useful. Triple buffering is relatively common though.) So there's a use for 3 screens in the virtual framebuffer - 48 MB? -- Jamie