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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
