qemu-devel
[Top][All Lists]
Advanced

[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: Fri, 09 Jan 2009 20:27:15 -0500
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

Paul Brook wrote:
I'm pretty sure this is wrong. VBE alows arbritary sized virtual
framebuffers.

VBE does, but the stdvga/VBE device model currently cannot _make use_ of
more, since there highest resolution provided is 2560x1600x32 = 16Megs. The
features required to make use of VRAM that is not used for the framebuffer
itself are not there, either, and hence any additional memory would just be
wasted. Anyone who would want to add features to the stdvga device or to
the VBE bios can easily remove or change this check.

Are you sure? I haven't actually tried it, but it looks like it should all just work.

Paul


It's not a matter of it not "working", it's a matter of the extra vram
not being in any way _usable_ to a guest OS or to the emulated device
without additional code in the stdvga device or implentation of VBE/AF
functions in vgabios. Moreover, most of the things that extra
"off-screen" vram would be useful for on real hardware are not helpful
in an emulated device. For example, in a real card you may want to store
pixmaps, fonts, etc in off-screen vram for fast copy to avoid having to
move it over a potentially "slow" bus between system ram and frambuffer
ram, but in an emulated device, vram and system ram are of course all
really system ram, and copies are no faster or slower, although
implementing "emulation" of on-card system ram and mechanisms to copy
and cache over the emulated PCI bus would add additional complexity that
would only make things _slower_.
Trying hard to think up a use for more than 16 Megs in the current case,
I could think of adding horizontally doubled resolutions to provide vm
screens that span Xinerama multi-monitor displays without needing to
emulate multi-display inside the actual VM, but I think such use cases
will be rather rare, and in case someone DOES want it, all that's needed
is to add those resolutions to vbetable-gen and bump the vram limit in
the code to the appropriate number (say 32M for a dual 2560x1600 display).

-- Trolle





reply via email to

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