[Intel-gfx] [PATCH 1/4] drm/i915: Pin fence for iomap
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Tue Jul 4 11:19:17 UTC 2017
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? 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
More information about the Intel-gfx
mailing list