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=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham 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 2DBB3C433E0 for ; Thu, 21 May 2020 09:42:34 +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 00BE820721 for ; Thu, 21 May 2020 09:42:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 00BE820721 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 9E6E06E920; Thu, 21 May 2020 09:42:32 +0000 (UTC) Received: from fireflyinternet.com (mail.fireflyinternet.com [109.228.58.192]) by gabe.freedesktop.org (Postfix) with ESMTPS id 17A446E920 for ; Thu, 21 May 2020 09:42:29 +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 21245311-1500050 for multiple; Thu, 21 May 2020 10:42:26 +0100 MIME-Version: 1.0 In-Reply-To: <5afb5457-733b-b057-dd6b-5040f5f9b5e8@linux.intel.com> References: <20200521085320.906-1-chris@chris-wilson.co.uk> <5afb5457-733b-b057-dd6b-5040f5f9b5e8@linux.intel.com> To: Tvrtko Ursulin , intel-gfx@lists.freedesktop.org From: Chris Wilson Message-ID: <159005414614.32320.874522293139874706@build.alporthouse.com> User-Agent: alot/0.8.1 Date: Thu, 21 May 2020 10:42:26 +0100 Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing 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 Tvrtko Ursulin (2020-05-21 10:10:10) > > On 21/05/2020 09:53, Chris Wilson wrote: > > Since the remove of the no-semaphore boosting, we rely on timeslicing to > > reorder past inter-dependency hogs across the engines. However, we > > require preemption to support timeslicing into user payloads, and not all > > machine support preemption so we do not universally enable timeslicing > > even when it would preempt our own inter-engine semaphores. > > > > Testcase: igt/gem_exec_schedule/semaphore-codependency # bdw/bsw > > Fixes: 18e4af04d218 ("drm/i915: Drop no-semaphore boosting") > > Signed-off-by: Chris Wilson > > Cc: Tvrtko Ursulin > > Cc: Mika Kuoppala > > --- > > drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c > > index 900ea8b7fc8f..f5d59d18cd5b 100644 > > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c > > @@ -230,7 +230,7 @@ static void intel_context_set_gem(struct intel_context *ce, > > ce->timeline = intel_timeline_get(ctx->timeline); > > > > if (ctx->sched.priority >= I915_PRIORITY_NORMAL && > > - intel_engine_has_semaphores(ce->engine)) > > + intel_engine_has_timeslices(ce->engine)) > > __set_bit(CONTEXT_USE_SEMAPHORES, &ce->flags); > > } > > > > @@ -1969,7 +1969,7 @@ static int __apply_priority(struct intel_context *ce, void *arg) > > { > > struct i915_gem_context *ctx = arg; > > > > - if (!intel_engine_has_semaphores(ce->engine)) > > + if (!intel_engine_has_timeslices(ce->engine)) > > return 0; > > > > if (ctx->sched.priority >= I915_PRIORITY_NORMAL) > > > > __i915_request_await_execution is okay to keep using semaphores? I think so. Using semaphores there still benefits from synchronising with a master in ELSP[1]. The danger is that it does increase the hangcheck possibility for the bond request, such that a slow request before the master would result in us declaring the bond hung. The question is whether that is worse than executing the bond before the master. I should be able to write a test to demonstrate the hang in the bond. For example, if we do something like: on master engine: submit spin submit master -> submit fence -> submit bond for(;;) submit high priority spin terminate previous spin Hmm. But without preemption... master will execute before we get a chance to submit the high priority spinners. So this will not actually hang. Ok, so this is safer than it seems :) Just need to write that test and execute it on broadwell to verify my claim. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx