[Intel-gfx] [PATCH 38/40] drm/i915/execlists: Flush the CS events before unpinning

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-10-01 14:15:49)
> 
> On 01/10/2018 12:06, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-10-01 11:51:23)
> >>
> >> Hm hm hm... my initial thought was that interrupts could be more delayed
> >> than breadcrumb writes (more than one context ahead), in which case the
> >> process_csb below could be premature and the assert would trigger. But I
> >> must be forgetting something since that would also mean we would
> >> prematurely unpin the context. So I must be forgetting something..
> > 
> > There will have been at least one CS event written because we have
> > switched contexts due to the unpin being one seqno behind. I have not
> > (yet) observed CS events being out of order with breadcrumb writes (and
> > we have very strict checking) so confident that a single process_csb()
> > is required rather than a loop.
> 
> I did not mean out of order but just delayed.
> 
> Say port 0 & 1 are both submitted, we observe seqno 1 & 2 as complete, 
> but the ctx complete irq/handler has been delayed. We go to unpin ctx0 
> (port0) but ce->active hasn't been cleared due no ctx complete yet so 
> the assert triggers. Impossible in your experience?

I have not seen anything to doubt that the CS interrupts, and more
importantly here, the CS events are delayed. It's the CS event itself
that we care about, and I think we are very safe in our assertion that
it is written on the context switch prior to the breadcrumb in the
second context.
-Chris