2015-08-19 5:24 GMT-03:00 chris@xxxxxxxxxxxxxxxxxx <chris@xxxxxxxxxxxxxxxxxx>: > 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@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
