[Intel-gfx] [PATCH 08/16] drm/i915: avoid the last 8mb of stolen on BDW/SKL

[chris at chris-wilson.co.uk]

On Tue, Aug 18, 2015 at 09:49:34PM +0000, Zanoni, Paulo R wrote:
> Em Sáb, 2015-08-15 às 09:29 +0100, Chris Wilson escreveu:
> > On Fri, Aug 14, 2015 at 06:34:13PM -0300, Paulo Zanoni wrote:
> > > The FBC hardware for these platforms doesn't have access to the
> > > bios_reserved range, so it always assumes the maximum (8mb) is 
> > > used.
> > > So avoid this range while allocating.
> > > 
> > > This solves a bunch of FIFO underruns that happen if you end up
> > > putting the CFB in that memory range. On my machine, with 32mb of
> > > stolen, I need a 2560x1440 mode for that.
> > 
> > If the restriction applies only to FBC, apply it to only fbc.
> 
> That's what the patch is doing. The part where we set the unusual
> start/end is at intel_fbc.c:find_compression_threshold(). Everything
> else should be behaving just as before.
> 
> Maybe you're being confused by the addition of the stolen_usable_size
> variable.

Hmm, I expected to see the constaint being passed into the search
routine.a It looked like you were adjusting the stolen_size probably the
root of my confusion.

Anyway we have a quandary. You want to reserve stolen space, and I want
to make sure as much of it gets used as possible (especially for long
lived objects).

What I have in mind is adding a priority to the search and allow us to
evict anything of lower priority. We can use a page replacement
algorithm even for the pinned fbcon (since only the GGTT itself is
pinned and we can swap the pages underneath). This of course requires a
callback for low priority evictable objects. I have 3 priorities in mind
plus the evictable flag: USER, KERNEL, POWER (with FBC taking the
highest priority of POWER). That will allow us to do the BIOS takeover
and only if we run out of space force the copy.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre