[Intel-gfx] [PATCH 1/4] drm/i915: Pin fence for iomap

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-07-04 12:19:17)
> 
> On 04/07/2017 11:04, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2017-07-04 10:53:53)
> >>
> >> On 03/07/2017 11:14, Chris Wilson wrote:
> >>> We probably want for the caller to specify whether the fence should be
> >>> pinned for their usage, but at the moment all callers do want the
> >>> associated fence, or none, so take it on their behalf.
> >> Wouldn't this be wasting fences for ring buffers?
> > 
> > No. We don't claim a fence unless used (the or none clause above). If
> > the object is untiled, like ringbuffers, we don't assign a fence. The
> > problem I'm thinking about for the future is having an iomap cached for
> > fenced and unfenced access, i.e. we need to track the type of iomap
> > similarly to regular vmaps.
> 
> I missed that i915_vma_get_fence only sets one up for tiled objects. 
> Code looks fine to me then, but the commit message reads like the main 
> paragraph is missing. With that improved a bit:
> 
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> 
> But for the series as a whole - what is the cover story?

Just working towards de-struct_mutexing the display paths.

> What does it do 
> on the high level? Less waiting in eb path, and instead sets up awaits? 

Yes, that's the merit of pipelining the fence changes.

> Fences are still reserved in advance so when it is runnable it is 
> guaranteed which one it is getting?

Yes.
-Chris