Re: [PATCH] drm/i915: Mark pending batches correctly on reset

[Mika Kuoppala <mika.kuoppala@linux.intel.com>]

Chris Wilson <chris@chris-wilson.co.uk> writes:

> On Wed, Oct 26, 2016 at 03:07:59PM +0300, Mika Kuoppala wrote:
>> For contexts that get their requests NOPed after a reset,
>> correctly count them as pending.
>> 
>> Testcase: igt/tests/gem_reset_stats
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
>
> We agreed that this was an incorrect interpretation of the robustness
> api, that neither handles tdr nor scales to multiple timlines.
>

I remember agreeing with the active one atleast. Perhaps being
ignorant on the multiple timelines case.

Is the reasoning here that there is no actual benefit of marking
batches pending as it is superflous in replay case. In another
words, the distinction between batch being queued before
submission and after, is a moot from userspace point of view?

> Currently, we only mark as innocent the contexts/batch executing on the
> hw on the good rings at the time of the reset.
>

I am ok with this. The interpretation of 'pending' changes but it
is more meaningful if one thinks pending on hardware.

-Mika

>>  drivers/gpu/drm/i915/i915_gem.c | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
>> index 87018df9..e025542 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -2615,6 +2615,7 @@ static void reset_request(struct drm_i915_gem_request *request)
>>  		head = 0;
>>  	}
>>  	memset(vaddr + head, 0, request->postfix - head);
>> +	i915_set_reset_status(request->ctx, false);
>
> This does not handle all the multiple timelines we have that are not
> even submitted yet.
> -Chris
>
> -- 
> Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx