From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6ABD9C38A2A for ; Fri, 8 May 2020 15:56:53 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 140C120CC7 for ; Fri, 8 May 2020 15:56:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 140C120CC7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=chris-wilson.co.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BA0236EB27; Fri, 8 May 2020 15:56:52 +0000 (UTC) Received: from fireflyinternet.com (mail.fireflyinternet.com [109.228.58.192]) by gabe.freedesktop.org (Postfix) with ESMTPS id DC86B6EB27 for ; Fri, 8 May 2020 15:56:50 +0000 (UTC) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from localhost (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP (TLS) id 21153368-1500050 for multiple; Fri, 08 May 2020 16:56:50 +0100 MIME-Version: 1.0 In-Reply-To: <87eeru4ej3.fsf@gaia.fi.intel.com> References: <20200508092933.738-1-chris@chris-wilson.co.uk> <20200508092933.738-3-chris@chris-wilson.co.uk> <87a72ixwt0.fsf@gaia.fi.intel.com> <158895262946.30605.1038065551850826772@build.alporthouse.com> <87eeru4ej3.fsf@gaia.fi.intel.com> To: Mika Kuoppala , intel-gfx@lists.freedesktop.org From: Chris Wilson Message-ID: <158895340689.30605.2560182810543435021@build.alporthouse.com> User-Agent: alot/0.8.1 Date: Fri, 08 May 2020 16:56:46 +0100 Subject: Re: [Intel-gfx] [PATCH 3/9] drm/i915: Prevent using semaphores to chain up to external fences X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Quoting Mika Kuoppala (2020-05-08 16:44:48) > Chris Wilson writes: > > > Quoting Mika Kuoppala (2020-05-08 16:37:15) > >> Chris Wilson 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 It's an unfortunate necessity, unless we can work in a conditional jump after the semaphore. But it also requires sampling all the possible error signals :( -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx