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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
