From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNCYr-0000zl-C8 for qemu-devel@nongnu.org; Wed, 14 Jan 2009 15:42:01 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNCYq-0000yc-B9 for qemu-devel@nongnu.org; Wed, 14 Jan 2009 15:42:00 -0500 Received: from [199.232.76.173] (port=60239 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNCYq-0000yH-1S for qemu-devel@nongnu.org; Wed, 14 Jan 2009 15:42:00 -0500 Received: from smtp.eu.citrix.com ([62.200.22.115]:44997) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LNCYp-0007lL-Jv for qemu-devel@nongnu.org; Wed, 14 Jan 2009 15:41:59 -0500 Message-ID: <496E4E00.3060105@eu.citrix.com> Date: Wed, 14 Jan 2009 15:41:36 -0500 From: Trolle Selander MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] [RFC] Variable video ram size option References: <496B965A.9000701@eu.citrix.com> <200901142007.42812.paul@codesourcery.com> In-Reply-To: <200901142007.42812.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: Paul Brook Cc: qemu-devel@nongnu.org Paul Brook wrote: >> 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. >> > > You're missing the point. There is no "usable max". The only limits are those > implied by 16-bit coordinates, address space, and the imagination of the > programmer. > > Paul > > True, but my thought was mainly that most of these "vram tricks" are very unlikely to be used by any software run in the VM and thus ending up going to waste and moreover (probably) pointless in a virtual architecture where there is no slow bus between videocard ram and system ram. In any case, the discussion here has made me reconsider whether we should not enforce any "artificial" limit, and just put recommendations for "sane" in the manpage, since ultimately, my reason for putting the limit in was mostly to prevent users from naively allocationg "pointless" amounts of vram that will almost certainly be wasted. The amounts of "graphic card ram" common today might easily cause new users to make this mistake. What's everyone else's thoughts on this? I'm preparing a slightly updated version of the patch, and I'd like to hear whether everyone agrees there should be no artificial limit enforced. Just out of curiosity, does anyone have any example of an existing application using VBE that makes use of more than triple-buffered (xres * yres * 4) RAM? -- Trolle