[Intel-gfx] [PATCH 4/5] drm/i915/gt: Drop intel_engine_transfer_stale_breadcrumbs

[Chris Wilson]

Quoting Tvrtko Ursulin (2020-07-16 16:29:37)
> 
> On 16/07/2020 12:33, Chris Wilson wrote:
> > Now that we have serialised the request retirement's decoupling of the
> > breadcrumb from the engine with the request signaling, we know that
> > there should never be a stale breadcrumb attached to an unbound virtual
> > engine. We can now remove the fixup code that had to migrate the
> > breadcrumbs along with the virtual engine, from one sibling to the next.
> 
> What do you mean by "unbound virtual engine"?

I think of ve->context.inflight == NULL as being unbound.

> Previous siblings[0]? We 
> do know that has been completed, at the point the next one is getting 
> dequeued, and by the virtue of breadcrumbs doing the signaling it will 
> have been removed from the list. But that was true before. Which leaves 
> me confused as to why the transfer was needed.. Was it just because 
> explicit wait used to be a potential signaler and that's no longer the case?

Evidently we did get requests finding their way onto
ve->engine[0].breadcumbs after the unsubmit. I thought I had a good
explanation with a window between ACTIVE and SIGNALED, but going back to
tip, those transitions are all underneath the rq->lock.

However, if we submit a completed request, that is put onto the
rq->engine->breadcrumb, but we do not schedule-in the context. That
would cause us to have breadcrumbs on ve->engine[0] while
ve->context.flight was NULL and on the next virtual request submission
could switch to a new engine with stale requests.

Ok, the issue of stale breadcrumbs is not completely solved yet.
But this time, this time for sure!, I think I know the cause of the
stale breadcrumbs!
-Chris