[Intel-gfx] [PATCH 11/15] drm/i915/execlists: Cancel banned contexts on schedule-out
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Mon Oct 14 13:19:19 UTC 2019
On 14/10/2019 14:13, Chris Wilson wrote:
> Quoting Chris Wilson (2019-10-14 13:34:35)
>> Quoting Tvrtko Ursulin (2019-10-14 13:25:58)
>>>
>>> On 14/10/2019 13:06, Chris Wilson wrote:
>>>> Quoting Tvrtko Ursulin (2019-10-14 13:00:01)
>>>>>
>>>>> On 14/10/2019 10:07, Chris Wilson wrote:
>>>>>> +static void cancel_active(struct i915_request *rq,
>>>>>> + struct intel_engine_cs *engine)
>>>>>> +{
>>>>>> + struct intel_context * const ce = rq->hw_context;
>>>>>> +
>>>>>> + /*
>>>>>> + * The executing context has been cancelled. Fixup the context so that
>>>>>> + * it will be marked as incomplete [-EIO] upon resubmission and not
>>>
>>> (read below first)
>>>
>>> ... and not misleadingly say "Fixup the context so that it will be
>>> marked as incomplete" because there is nothing in this function which
>>> does that. It mostly happens by the virtual of context already being
>>> marked as banned somewhere else. This comment should just explain the
>>> decision to rewind the ring->head for more determinism. It can still
>>> mention canceling of user payload and -EIO. Just needs to be clear of
>>> the single extra thing achieved here by the head rewind and context edit.
>>
>> I thought I was clear: "upon resubmission". So use a more active voice to
>> reduce ambiguity, gotcha.
>
> /*
> * The executing context has been cancelled. We want to prevent
> * further execution along this context and propagate the error on
> * to anything depending on its results.
> *
> * In __i915_request_submit(), we apply the -EIO and remove the
> * requests payload for any banned requests. But first, we must
> * rewind the context back to the start of the incomplete request so
> * that we don't jump back into the middle of the batch.
> *
> * We preserve the breadcrumbs and semaphores of the incomplete
> * requests so that inter-timeline dependencies (i.e other timelines)
> * remain correctly ordered.
> */
>
Sounds good.
Btw.. does this work? :) If context was preempted in the middle of a
batch buffer there must be some other state saved (other than RING_HEAD)
which on context restore enables it to continue from the right place
*within* the batch. Is this code zapping that state as well so GPU will
fully forget it was inside the batch?
Regards,
Tvrtko
More information about the Intel-gfx
mailing list