[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] [RFC] Variable video ram size option

From: Trolle Selander
Subject: Re: [Qemu-devel] [PATCH] [RFC] Variable video ram size option
Date: Mon, 12 Jan 2009 14:13:30 -0500
User-agent: Thunderbird (X11/20090105)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]