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