From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Widawsky Subject: Re: [PATCH 4/4] drm/i915: Reserve space for FBC (fbcon) Date: Mon, 30 Jun 2014 20:34:53 -0700 Message-ID: <20140701033453.GA981@bwidawsk.net> References: <1403204773-7112-1-git-send-email-benjamin.widawsky@intel.com> <1403204773-7112-4-git-send-email-benjamin.widawsky@intel.com> <20140619192811.GD8476@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail.bwidawsk.net (bwidawsk.net [166.78.191.112]) by gabe.freedesktop.org (Postfix) with ESMTP id CB1F76E1EA for ; Mon, 30 Jun 2014 20:35:00 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20140619192811.GD8476@nuc-i3427.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Chris Wilson , Ben Widawsky , Intel GFX , Jesse Barnes List-Id: intel-gfx@lists.freedesktop.org On Thu, Jun 19, 2014 at 08:28:11PM +0100, Chris Wilson wrote: > On Thu, Jun 19, 2014 at 12:06:13PM -0700, Ben Widawsky wrote: > > This is one part in a few fixes needed to make FBC work with limited > > stolen memory and large resolution displays. It is not the full > > solution, but one (easy) step. > > > > The patch is straight-forward, it attempts to check there will be room > > for FBC before trying to "reclaim" > > But it special cases one particular allocation. Why don't you just > reserve stolen upfront for FBC? Compute the maximum buffer size the > hardware could support and try to claim it during stolen init. > -Chris > I agree this would be the best approach (and what I had planned to do). For one, I didn't find the interfaces I wanted in the drm_mm to do what I needed (though I didn't look very hard). I ended up getting stuck with having to decide whether to reclaim the scanout (and fastboot), or FBC. I believe this should be a decision left to the user, where user is the distro packaging. I'd like to just point out some math at this point too. Common stolen size is 32M 3840 x 2160 x 4 = 31.64M So we have a real problem if we want to reuse any of stolen memory, which the first 3 patches address to some extent. Anyway, I think I was pretty clear that the patch is incomplete, and primarily meant to motivate the relevant parties to figure out how they want to handle the stolen reclaim. -- Ben Widawsky, Intel Open Source Technology Center