From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [PATCH 07/18] drm/i915: Defer allocation of stolen
	memory for FBC until actual first use
Date: Mon, 05 Nov 2012 15:28:42 +0000
Message-ID: <275ffc$790b5r@fmsmga002.fm.intel.com>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
	by gabe.freedesktop.org (Postfix) with ESMTP id 3675E9E75F
	for <intel-gfx@lists.freedesktop.org>;
	Mon,  5 Nov 2012 07:29:34 -0800 (PST)
In-Reply-To: <20121105150036.5b856fa3@bwidawsk.net>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=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: Ben Widawsky <ben@bwidawsk.net>
Cc: intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

On Mon, 5 Nov 2012 15:00:36 +0000, Ben Widawsky <ben@bwidawsk.net> wrote:
> On Fri, 19 Oct 2012 18:03:13 +0100
> Chris Wilson <chris@chris-wilson.co.uk> 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

-- 
Chris Wilson, Intel Open Source Technology Centre