[Intel-gfx] [PATCH 088/190] drm/i915: Move execlists interrupt based submission to a bottom-half

[Chris Wilson]

On Fri, Feb 19, 2016 at 02:52:18PM +0000, Tvrtko Ursulin wrote:
> 
> On 19/02/16 14:34, Chris Wilson wrote:
> >On Fri, Feb 19, 2016 at 02:10:44PM +0000, Tvrtko Ursulin wrote:
> >>On 19/02/16 12:29, Chris Wilson wrote:
> >>>Exactly, we want the iomap/vmap caching thingy first :) But the
> >>>retired work queue disappears as a fallout of your previous-context idea
> >>>anyway plus the fix to avoid the struct_mutex when freeing requests.
> >>
> >>I did not get that working yet. I think it need N previous contexts
> >>pinned in a request, where N is equal to CSB size. Since most
> >>pessimistic thinking is we could get that many context complete
> >>events in a single interrupt.
> >
> >The completion order is still the same as our execution order (it has to
> >be otherwise it violates our serialisation rules), so worst case is you
> >only need to keep the engine->last_context pinned along with active
> >references on the outstanding contexts (and those active references are
> >held by the following request).
> 
> Yes completion order is the same but seqno in HWS could
> theoretically be ahead of the context completes by the size of CSB I
> thought.
> 
> Theory is that GPU could have completed N contexts, stuffed the
> notifications in the CSB and then maybe the actual interrupt got
> coalesced, delayed, or something. At least I thought this was what I
> was observing. Not 100% sure.

Aiui, the issue is where we unpin (because of breadcrumb completion)
before the HW completes (finishes writing out the context). For legacy,
we rely on that the MI_SET_CONTEXT is a serialising instruction (i.e.
all writes are completed to the old context before execution continues)
and only then need to keep the old context alive until the request
containing the MI_SET_CONTEXT away is complete. For the same techinque
to be applicable to execlists, just needs the same guarantee that the
hardware will not execute from the next context until it has finished
saving state from the previous context.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre