Re: [PATCH 07/18] drm/i915: Defer allocation of stolen memory for FBC until actual first use

[Ben Widawsky <ben@bwidawsk.net>]

On Mon, 05 Nov 2012 15:28:42 +0000
Chris Wilson <chris@chris-wilson.co.uk> wrote:

> 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
> 

On the basis that all the other checks are more likely to be false, it
is:
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>

if you want to keep it. Maybe update the commit message if you feel like
it.

-- 
Ben Widawsky, Intel Open Source Technology Center