From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LLSdE-0004IX-Rv for qemu-devel@nongnu.org; Fri, 09 Jan 2009 20:27:20 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LLSdD-0004Gq-Ff for qemu-devel@nongnu.org; Fri, 09 Jan 2009 20:27:20 -0500 Received: from [199.232.76.173] (port=60237 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LLSdD-0004Gd-0V for qemu-devel@nongnu.org; Fri, 09 Jan 2009 20:27:19 -0500 Received: from smtp.ctxuk.citrix.com ([62.200.22.115]:22758 helo=SMTP.EU.CITRIX.COM) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LLSdC-0006cb-23 for qemu-devel@nongnu.org; Fri, 09 Jan 2009 20:27:18 -0500 Message-ID: <4967F973.3050405@eu.citrix.com> Date: Fri, 09 Jan 2009 20:27:15 -0500 From: Trolle Selander MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] [RFC] Variable video ram size option References: <4967A96B.3020902@eu.citrix.com> <200901091702.22432.paul@codesourcery.com> <4967E7D7.4040605@eu.citrix.com> <200901091716.00827.paul@codesourcery.com> In-Reply-To: <200901091716.00827.paul@codesourcery.com> 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 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