Re: [PATCH 1/4] drm/i915: Pin fence for iomap

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

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@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

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx