On Tue, Mar 31, 2015 at 01:41:42PM +0100, Tvrtko Ursulin wrote: > > On 03/31/2015 01:32 PM, Chris Wilson wrote: > >On Tue, Mar 31, 2015 at 01:23:10PM +0100, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > >> > >>Purpose of this tracking is to know when to flush the cache between the > > > >CPU and the > > > >>non-coherent display engine. Previously to: > > > >s/Previously/Prior/ > > > >> > >> commit 121920faf2ccce9aa66a7e2588415c9647b66104 > >> Author: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > >> Date: Mon Mar 23 11:10:37 2015 +0000 > >> > >> drm/i915/skl: Query display address through a wrapper > >> > >>This worked by a mix of direct flag manipulation and checking for > >>existence of a pinned GGTT VMA. > >> > >>With the introduction of rotated display mappings this approach is > >>no longer correct. > >> > >>New simpler approach is to just keep this count over calls which pin and > >>unpin objects to and from display. > > > >at the slight cost of extra space in every bo. > > Is space is a concern, how about just a flag then? Counter kind of > lost its usefulness at the moment. Space is always a concern with something that we allocate in the tens of thousands - however, we round object sizes up to a cacheline, so keeping the object trim is quite hard and our objects are already quite large. Every now and again we try and go on a diet, but it doesn't last. What's the shortcoming of the counter? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
