From: Trolle Selander <trolle.selander@eu.citrix.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] [RFC] Variable video ram size option
Date: Mon, 12 Jan 2009 14:13:30 -0500 [thread overview]
Message-ID: <496B965A.9000701@eu.citrix.com> (raw)
>
> 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
next reply other threads:[~2009-01-12 19:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-12 19:13 Trolle Selander [this message]
2009-01-14 20:07 ` [Qemu-devel] [PATCH] [RFC] Variable video ram size option Paul Brook
2009-01-14 20:41 ` Trolle Selander
2009-01-14 21:30 ` Paul Brook
2009-01-14 22:47 ` Trolle Selander
2009-01-15 13:08 ` Jamie Lokier
2009-01-15 15:37 ` Rene Rebe
2009-01-15 16:23 ` Jamie Lokier
2009-01-15 17:36 ` Gerd Hoffmann
2009-01-15 20:57 ` Jamie Lokier
2009-01-15 21:41 ` Gerd Hoffmann
-- strict thread matches above, loose matches on Subject: below --
2009-01-09 19:45 Trolle Selander
2009-01-10 0:02 ` Paul Brook
2009-01-10 1:26 ` Trolle Selander
2009-01-10 6:45 ` Blue Swirl
[not found] ` <4967E7D7.4040605@eu.citrix.com>
[not found] ` <200901091716.00827.paul@codesourcery.com>
2009-01-10 1:27 ` Trolle Selander
[not found] ` <4967ECA7.6040809@eu.citrix.com>
[not found] ` <200901091747.06462.paul@codesourcery.com>
2009-01-10 1:28 ` Trolle Selander
2009-01-10 1:47 ` Jamie Lokier
2009-01-11 7:53 ` Avi Kivity
2009-01-12 17:43 ` Trolle Selander
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=496B965A.9000701@eu.citrix.com \
--to=trolle.selander@eu.citrix.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).