[Intel-gfx] [PATCH v8 4/6] drm/i915: Interrupt driven fences

[Chris Wilson]

On Fri, May 13, 2016 at 10:19:11AM +0100, John Harrison wrote:
> On 13/05/2016 08:27, Chris Wilson wrote:
> >On Thu, May 12, 2016 at 10:06:34PM +0100, John.C.Harrison at Intel.com wrote:
> >>+void i915_gem_request_notify(struct intel_engine_cs *engine, bool fence_locked)
> >>+{
> >>+	struct drm_i915_gem_request *req, *req_next;
> >>+	unsigned long flags;
> >>  	u32 seqno;
> >>-	seqno = req->engine->get_seqno(req->engine);
> >>+	if (list_empty(&engine->fence_signal_list))
> >>+		return;
> >>+
> >>+	if (!fence_locked)
> >>+		spin_lock_irqsave(&engine->fence_lock, flags);
> >>+
> >>+	if (engine->irq_seqno_barrier)
> >>+		engine->irq_seqno_barrier(engine);
> >>+	seqno = engine->get_seqno(engine);
> >>+
> >>+	list_for_each_entry_safe(req, req_next, &engine->fence_signal_list, signal_link) {
> >NO, NO, NO. As we said the very first time, you cannot do this from an
> >irq handler.
> >
> >The current code is already bad enough, this is making it large constant
> >+ N times worse. Please do look at how to do signal driven fences in O(1)
> >that I posted many months ago and several times since.
> 
> If you have a better solution available then please post it in a
> form that can be merged and get it reviewed and accepted.

Recently reposted as
https://lists.freedesktop.org/archives/intel-gfx/2016-May/095040.html

It is currently blocking getting request + vma tracking overhauled to
fix our leaks, as well as the regression fixes that depend upon them.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre