From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Widawsky Subject: Re: [PATCH 07/18] drm/i915: Defer allocation of stolen memory for FBC until actual first use Date: Mon, 5 Nov 2012 15:32:35 +0000 Message-ID: <20121105153235.69dfe98a@bwidawsk.net> References: <1350666204-8101-1-git-send-email-chris@chris-wilson.co.uk> <1350666204-8101-7-git-send-email-chris@chris-wilson.co.uk> <20121105150036.5b856fa3@bwidawsk.net> <275ffc$790b5r@fmsmga002.fm.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from shiva.chad-versace.us (209-20-75-48.static.cloud-ips.com [209.20.75.48]) by gabe.freedesktop.org (Postfix) with ESMTP id 431C09E75F for ; Mon, 5 Nov 2012 07:32:11 -0800 (PST) In-Reply-To: <275ffc$790b5r@fmsmga002.fm.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Chris Wilson Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Mon, 05 Nov 2012 15:28:42 +0000 Chris Wilson wrote: > On Mon, 5 Nov 2012 15:00:36 +0000, Ben Widawsky wrote: > > On Fri, 19 Oct 2012 18:03:13 +0100 > > Chris Wilson wrote: > > > > > As FBC is commonly disabled due to limitations of the chipset upon > > > output configurations, on many systems FBC is never enabled. For those > > > systems, it is advantageous to make use of the stolen memory for other > > > objects and so we defer allocation of the FBC chunk until we actually > > > require it. This increases the likelihood of that allocation failing, > > > which in turns means that we are already taking advantage of the stolen > > > memory! > > > > I'm failing to see how this patch is doing what it advertises to do. At > > least applies to dinq it's only deferring the error check. None of the > > steps that now happen before allocating the stolen compressed fb use > > stolen memory. On any of the errors, we seem to free the stolen memory. > > I see a mode check, a platform/plane check, a tiling check, a debug > > check now happening before we setup compression, but I fail to see how > > that really effects anything.... I'm sorry if I am being obtuse, but > > could you please explain a bit better? > > All of those previous checks are more likely to be false - and > previously we never tried to recover the stolen memory. I can go back to > a single patch as this is now just an optimisation rather than > preventing a permanent loss of memory. > -Chris > On the basis that all the other checks are more likely to be false, it is: Reviewed-by: Ben Widawsky if you want to keep it. Maybe update the commit message if you feel like it. -- Ben Widawsky, Intel Open Source Technology Center