[Intel-gfx] [PATCH 06/42] drm/i915: Support asynchronous waits on struct fence from i915_gem_request

[Tvrtko Ursulin]

On 07/10/2016 17:12, Chris Wilson wrote:
> On Fri, Oct 07, 2016 at 04:51:14PM +0100, Tvrtko Ursulin wrote:
>> On 07/10/2016 10:45, Chris Wilson wrote:
>>> We will need to wait on DMA completion (as signaled via struct fence)
>>> before executing our i915_gem_request. Therefore we want to expose a
>>> method for adding the await on the fence itself to the request.
>>>
>>> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
>>> ---
>>>   drivers/gpu/drm/i915/i915_gem_request.c | 40 +++++++++++++++++++++++++++++++++
>>>   drivers/gpu/drm/i915/i915_gem_request.h |  2 ++
>>>   2 files changed, 42 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/drivers/gpu/drm/i915/i915_gem_request.c
>>> index 8832f8ec1583..e1f7a32d4080 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem_request.c
>>> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
>>> @@ -23,6 +23,7 @@
>>>    */
>>>   #include <linux/prefetch.h>
>>> +#include <linux/fence-array.h>
>>>   #include "i915_drv.h"
>>> @@ -495,6 +496,45 @@ i915_gem_request_await_request(struct drm_i915_gem_request *to,
>>>   	return 0;
>>>   }
>>> +int
>>> +i915_gem_request_await_fence(struct drm_i915_gem_request *req,
>>> +			     struct fence *fence)
>>> +{
>>> +	struct fence_array *array;
>>> +	int ret;
>>> +	int i;
>>> +
>>> +	if (test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->flags))
>>> +		return 0;
>>> +
>>> +	if (fence_is_i915(fence))
>>> +		return i915_gem_request_await_request(req, to_request(fence));
>>> +
>>> +	if (!fence_is_array(fence)) {
>>> +		ret = i915_sw_fence_await_dma_fence(&req->submit,
>>> +						    fence, 10*HZ,
>>> +						    GFP_KERNEL);
>>> +		return ret < 0 ? ret : 0;
>>> +	}
>>> +
>>> +	array = to_fence_array(fence);
>>> +	for (i = 0; i < array->num_fences; i++) {
>>> +		struct fence *child = array->fences[i];
>> 1. What is the advantage in manually waiting on array elements
>> rather than just the array? Is the existance of signal_on_any a
>> problem?
> We can wait on native fences much more efficiently. In the typical case,
> we don't even need the wait at all since the ordering is imposed by the
> timeline. Or we can hook into the submission fence to avoid the
> interrupt. Failing that we have to respond to the interrupt. Also note
> that foriegn fences handle autosignaling differently to native fences,
> as we cannot rely on third parties having a working hangcheck.
>   
>> 2. Can child be another array?
> Yes, but we don't want to recurse (or at least need to bound the
> recursion).

In that case could the array have been created in the signal_on_any mode 
and how would we handle that?

Regards,

Tvrtko