[Intel-gfx] [PATCH v2] drm/i915: Simplify and fix object to display tracking

Chris Wilson chris at chris-wilson.co.uk
Tue Mar 31 05:52:03 PDT 2015


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 at intel.com>
> >>
> >>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 at intel.com>
> >>    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


More information about the Intel-gfx mailing list