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