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

[Paulo Zanoni]

2015-08-19 5:24 GMT-03:00 chris at chris-wilson.co.uk <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.

While I understand your idea, I just want to clarify one thing: it
does not apply to _this_ patch, right? I suppose we're discussing
about "[PATCH 15/16] Revert "drm/i915: Allocate fbcon from stolen
memory" here. The memory avoided by this patch (08/16) can still be
used by the other stolen memory users.

For the fbcon patch, can't we adopt a simpler "if FBC is enabled by
default on this platform, don't alloc fbcon from stolen"?.

> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Paulo Zanoni