From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LMSEC-0003Ch-CJ for qemu-devel@nongnu.org; Mon, 12 Jan 2009 14:13:36 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LMSEA-0003CV-Ur for qemu-devel@nongnu.org; Mon, 12 Jan 2009 14:13:35 -0500 Received: from [199.232.76.173] (port=47262 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LMSEA-0003CS-Mn for qemu-devel@nongnu.org; Mon, 12 Jan 2009 14:13:34 -0500 Received: from smtp.eu.citrix.com ([62.200.22.115]:57655) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LMSEA-0005cH-Co for qemu-devel@nongnu.org; Mon, 12 Jan 2009 14:13:34 -0500 Message-ID: <496B965A.9000701@eu.citrix.com> Date: Mon, 12 Jan 2009 14:13:30 -0500 From: Trolle Selander MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] [RFC] Variable video ram size option Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 > > 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 > While I have my doubts about there being any applications or games using VBE & triple buffering that will actually run at 2560x1600 with any kind of decent performance , I also see no reason to set this limit any lower than the theoretically usable max, so 48 Megs it is. -- Trolle