From mint-bounce@lists.fishpool.fi Mon May 31 08:30:03 2010 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:x-priority:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=lhCcUksEyHYIPDtYbpgQFPwI9yo8g1bkeq5Oml4DivU=; b=gquhUcmspkeHfM7+HoE8TcO2RhYXhW7Tc0ERrwzt4H/RuPokkET9GcwFmgbR2rxjsQ f6dwFNsLbj5IeZk9HMwGAXpafbQnf9a6Dpy7WG1xKoTRIBrVKbJIFae9Esv8CPDZq0AT S7x8H1rhVgK4csCsFjuuHA45mWcyfrfOBA7Rk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; b=erWx2jjIp5s8pdLK89DNtT+U/5msXZBv9MdV6xA2YwnqWTnqM5uEQPmFe4gxRG33QZ PPugUAoqfDrmtbgjF4RnzYqtWcd/PFc/Dw3Ch2+0E3V4XxEbIs0ZvaKj7+rmv1cZsaj3 def86EAIW68je79VjO2I08nFOQUTCu4A9vY9M= Subject: Re: [MiNT] Allocation of video RAM Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Peter Persson X-Priority: 3 In-Reply-To: <9054FE70A0BD42D29D3958A81392C234@mercatus.local> Date: Mon, 31 May 2010 14:27:19 +0200 Cc: "MiNT Mailing List" Message-Id: <696E7EC0-E03A-4D3A-9467-B1C324868CE1@gmail.com> References: <9054FE70A0BD42D29D3958A81392C234@mercatus.local> To: "Jo Even Skarstein" X-Mailer: Apple Mail (2.1078) X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: pep.fishmoose@gmail.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.sparemint.org id o4VCU2Ob028004 31 maj 2010 kl. 14.19 skrev Jo Even Skarstein: > -------------------------------------------------- > From: "Peter Persson" > Sent: Monday, May 31, 2010 1:30 PM > To: "MiNT Mailing List" > Subject: [MiNT] Allocation of video RAM > >> My question is about video RAM (VRAM). Right now there is no functionality for this in the kernel, except Screalloc(). This means that the driver >> has to implement that stuff internally, which has several drawbacks. For example - if an application exits prematurely or doesn't do mfree() on >> allocated VRAM, the memory won't be freed. Furthermore, there will be no memory protection for this additional class of RAM if it isn't >> implemented in the kernel. > > The correct place for this would IMO be the VDI, e.g. to use the offscreen bitmap facility. Or do you want the VRAM to be available for other uses than video? Imo the right way would be to have a low level API for this to ensure that memory protection etc. works as intended. AFAIK the VDI doesn't provide mechanisms for that, at least not any current VDI. Also, the usage scenario for an offscreen bitmap doesn't necessarily mean there is a point in putting it in VRAM (and CPU<>VRAM accesses are generally slower than the CPU<>TTRAM dito). So sure - it could be a point to have a VRAM aware VDI, which could in turn use the low level functionality in question. But right now we have no such thing. -- PeP