Quoting Tvrtko Ursulin (2019-04-18 11:32:31) > > On 17/04/2019 08:56, Chris Wilson wrote: > > Currently there is an underlying assumption that i915_request_unsubmit() > > is synchronous wrt the GPU -- that is the request is no longer in flight > > as we remove it. In the near future that may change, and this may upset > > our signaling as we can process an interrupt for that request while it > > is no longer in flight. > > Is this the preempt-to-busy future? Async unsubmit is preempt-to-busy, but one shouldn't rule out the guc either :) > > > > > CPU0 CPU1 > > intel_engine_breadcrumbs_irq > > (queue request completion) > > i915_request_cancel_signaling > > ... ... > > i915_request_enable_signaling > > dma_fence_signal > > In this case completed request is unsubmitted? The request completed after it was unsubmitted, yes. > There will be some inherent problem preventing avoiding preempting > completed requests? Window between MI_ARB_ENABLE in emit_fini_breadcrumb > and context complete? For preempt-to-busy, we stick a semaphore into the fini_breadcrumb to prevent context completion while we perform the preemption. Please note the second aspect wrt to dereferencing the intel_context after we skip the cancel_breadcrumbs during retire is why I think this fixes a present bug. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
