Re: [Intel-gfx] [PATCH 3/9] drm/i915: Prevent using semaphores to chain up to external fences

From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 3/9] drm/i915: Prevent using semaphores to chain up to external fences
Date: Fri, 08 May 2020 18:44:48 +0300	[thread overview]
Message-ID: <87eeru4ej3.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <158895262946.30605.1038065551850826772@build.alporthouse.com>

Chris Wilson <chris@chris-wilson.co.uk> writes:

> Quoting Mika Kuoppala (2020-05-08 16:37:15)
>> Chris Wilson <chris@chris-wilson.co.uk> writes:
>> 
>> > The downside of using semaphores is that we lose metadata passing
>> > along the signaling chain. This is particularly nasty when we
>> > need to pass along a fatal error such as EFAULT or EDEADLK. For
>> > fatal errors we want to scrub the request before it is executed,
>> > which means that we cannot preload the request onto HW and have
>> > it wait upon a semaphore.
>> 
>> b is waiting on a, a fails and we want to release b with error?
>
> Yes. B is submitted before A, and if B is relying on A to setup GPU page

I guess this has to be A is before B.

> tables or other interesting things, we can't let B run if A dies. For
> the EDEADLK if B is waiting on A, but then A is submitted with a wait on
> B -- we have to untangle that mess.

Avoiding the hw semaphore makes sense

Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>

> -Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx