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=-7.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, HK_RANDOM_FROM,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 E7EB1C38A24 for ; Thu, 7 May 2020 15:24:04 +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 C902120838 for ; Thu, 7 May 2020 15:24:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C902120838 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com 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 40EDC6E128; Thu, 7 May 2020 15:24:04 +0000 (UTC) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by gabe.freedesktop.org (Postfix) with ESMTPS id 79A846E128 for ; Thu, 7 May 2020 15:24:03 +0000 (UTC) IronPort-SDR: ODgf01YqkaoK6wyxaUgxOUSLOTRgj53WrX60LMT7RdQyn+LWKpPGopaZXY+9c/UtAMG4sXZR1J 0iVIZ21jLUtQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 May 2020 08:24:02 -0700 IronPort-SDR: B1cfkzwMs+Q6fWgsLVxLg0tBTn9mIVW8O0a0O5wehlfIQEH4Kyb317XSBD45c1GZL0YJ1yVCPL UpXVTuetq2DA== X-IronPort-AV: E=Sophos;i="5.73,364,1583222400"; d="scan'208";a="435325951" Received: from nstgemme-mobl1.ger.corp.intel.com (HELO [10.252.42.100]) ([10.252.42.100]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 May 2020 08:24:01 -0700 To: Chris Wilson , intel-gfx@lists.freedesktop.org References: <20200507082124.1673-1-chris@chris-wilson.co.uk> <158886364344.20858.57212288691515302@build.alporthouse.com> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc Message-ID: <2ea266b4-64a7-e494-65e9-6435d4455a71@linux.intel.com> Date: Thu, 7 May 2020 16:23:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <158886364344.20858.57212288691515302@build.alporthouse.com> Content-Language: en-US Subject: Re: [Intel-gfx] [PATCH 1/3] drm/i915: Mark concurrent submissions with a weak-dependency 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: , Cc: stable@vger.kernel.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On 07/05/2020 16:00, Chris Wilson wrote: > Quoting Tvrtko Ursulin (2020-05-07 15:53:08) >> On 07/05/2020 09:21, Chris Wilson wrote: >>> We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could >>> correctly perform priority inheritance from the parallel branches to the >>> common trunk. However, for the purpose of timeslicing and reset >>> handling, the dependency is weak -- as we the pair of requests are >>> allowed to run in parallel and not in strict succession. So for example >>> we do need to suspend one if the other hangs. >>> >>> The real significance though is that this allows us to rearrange >>> groups of WAIT_FOR_SUBMIT linked requests along the single engine, and >>> so can resolve user level inter-batch scheduling dependencies from user >>> semaphores. >>> >>> Fixes: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags across submit fences") >>> Testcase: igt/gem_exec_fence/submit >>> Signed-off-by: Chris Wilson >>> Cc: Tvrtko Ursulin >>> Cc: # v5.6+ >>> --- >>> drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +++++++++ >>> drivers/gpu/drm/i915/i915_request.c | 8 ++++++-- >>> drivers/gpu/drm/i915/i915_scheduler.c | 6 +++--- >>> drivers/gpu/drm/i915/i915_scheduler.h | 3 ++- >>> drivers/gpu/drm/i915/i915_scheduler_types.h | 1 + >>> 5 files changed, 21 insertions(+), 6 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c >>> index dc3f2ee7136d..10109f661bcb 100644 >>> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c >>> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c >>> @@ -1880,6 +1880,9 @@ static void defer_request(struct i915_request *rq, struct list_head * const pl) >>> struct i915_request *w = >>> container_of(p->waiter, typeof(*w), sched); >>> >>> + if (p->flags & I915_DEPENDENCY_WEAK) >>> + continue; >>> + >> >> I did not quite get it - submit fence dependency would mean different >> engines, so the below check (w->engine != rq->engine) would effectively >> have the same effect. What am I missing? > > That submit fences can be between different contexts on the same engine. > The example (from mesa) is where we have two interdependent clients > which are using their own userlevel scheduling inside each batch, i.e. > waiting on semaphores. But if submit fence was used that means the waiter should never be submitted ahead of the signaler. And with this change it could get ahead in the priolist, no? Regards, Tvrtko _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx 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=-7.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, HK_RANDOM_FROM,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 D5841C38A2A for ; Thu, 7 May 2020 15:24:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B9124207DD for ; Thu, 7 May 2020 15:24:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726069AbgEGPYE (ORCPT ); Thu, 7 May 2020 11:24:04 -0400 Received: from mga14.intel.com ([192.55.52.115]:16765 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725914AbgEGPYE (ORCPT ); Thu, 7 May 2020 11:24:04 -0400 IronPort-SDR: h4tid4VpFKGXm4disc7NK4Z4mgIRd5yhZbxZpu++6/yvILR8T7nH33XrGh7UuR5SJ/hCLsCnwD T50yZ0czP5aA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 May 2020 08:24:02 -0700 IronPort-SDR: B1cfkzwMs+Q6fWgsLVxLg0tBTn9mIVW8O0a0O5wehlfIQEH4Kyb317XSBD45c1GZL0YJ1yVCPL UpXVTuetq2DA== X-IronPort-AV: E=Sophos;i="5.73,364,1583222400"; d="scan'208";a="435325951" Received: from nstgemme-mobl1.ger.corp.intel.com (HELO [10.252.42.100]) ([10.252.42.100]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 May 2020 08:24:01 -0700 Subject: Re: [Intel-gfx] [PATCH 1/3] drm/i915: Mark concurrent submissions with a weak-dependency To: Chris Wilson , intel-gfx@lists.freedesktop.org Cc: stable@vger.kernel.org References: <20200507082124.1673-1-chris@chris-wilson.co.uk> <158886364344.20858.57212288691515302@build.alporthouse.com> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc Message-ID: <2ea266b4-64a7-e494-65e9-6435d4455a71@linux.intel.com> Date: Thu, 7 May 2020 16:23:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <158886364344.20858.57212288691515302@build.alporthouse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On 07/05/2020 16:00, Chris Wilson wrote: > Quoting Tvrtko Ursulin (2020-05-07 15:53:08) >> On 07/05/2020 09:21, Chris Wilson wrote: >>> We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could >>> correctly perform priority inheritance from the parallel branches to the >>> common trunk. However, for the purpose of timeslicing and reset >>> handling, the dependency is weak -- as we the pair of requests are >>> allowed to run in parallel and not in strict succession. So for example >>> we do need to suspend one if the other hangs. >>> >>> The real significance though is that this allows us to rearrange >>> groups of WAIT_FOR_SUBMIT linked requests along the single engine, and >>> so can resolve user level inter-batch scheduling dependencies from user >>> semaphores. >>> >>> Fixes: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags across submit fences") >>> Testcase: igt/gem_exec_fence/submit >>> Signed-off-by: Chris Wilson >>> Cc: Tvrtko Ursulin >>> Cc: # v5.6+ >>> --- >>> drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +++++++++ >>> drivers/gpu/drm/i915/i915_request.c | 8 ++++++-- >>> drivers/gpu/drm/i915/i915_scheduler.c | 6 +++--- >>> drivers/gpu/drm/i915/i915_scheduler.h | 3 ++- >>> drivers/gpu/drm/i915/i915_scheduler_types.h | 1 + >>> 5 files changed, 21 insertions(+), 6 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c >>> index dc3f2ee7136d..10109f661bcb 100644 >>> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c >>> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c >>> @@ -1880,6 +1880,9 @@ static void defer_request(struct i915_request *rq, struct list_head * const pl) >>> struct i915_request *w = >>> container_of(p->waiter, typeof(*w), sched); >>> >>> + if (p->flags & I915_DEPENDENCY_WEAK) >>> + continue; >>> + >> >> I did not quite get it - submit fence dependency would mean different >> engines, so the below check (w->engine != rq->engine) would effectively >> have the same effect. What am I missing? > > That submit fences can be between different contexts on the same engine. > The example (from mesa) is where we have two interdependent clients > which are using their own userlevel scheduling inside each batch, i.e. > waiting on semaphores. But if submit fence was used that means the waiter should never be submitted ahead of the signaler. And with this change it could get ahead in the priolist, no? Regards, Tvrtko