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? What does it do
on the high level? Less waiting in eb path, and instead sets up awaits?
Fences are still reserved in advance so when it is runnable it is
guaranteed which one it is getting?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
