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=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,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 A102AC4338F for ; Wed, 11 Aug 2021 17:47:15 +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 4CB7B60462 for ; Wed, 11 Aug 2021 17:47:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4CB7B60462 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 406C26E190; Wed, 11 Aug 2021 17:47:14 +0000 (UTC) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by gabe.freedesktop.org (Postfix) with ESMTPS id AAF136E190; Wed, 11 Aug 2021 17:47:07 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10073"; a="194771489" X-IronPort-AV: E=Sophos;i="5.84,313,1620716400"; d="scan'208";a="194771489" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Aug 2021 10:47:06 -0700 X-IronPort-AV: E=Sophos;i="5.84,313,1620716400"; d="scan'208";a="676213708" Received: from dut151-iclu.fm.intel.com ([10.105.23.69]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Aug 2021 10:47:06 -0700 Date: Wed, 11 Aug 2021 17:47:05 +0000 From: Matthew Brost To: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Message-ID: <20210811174705.GA297117@DUT151-ICLU.fm.intel.com> References: <20210803222943.27686-1-matthew.brost@intel.com> <20210803222943.27686-12-matthew.brost@intel.com> <20210809182051.GA123521@DUT151-ICLU.fm.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Intel-gfx] [PATCH 11/46] drm/i915/guc: Don't call switch_to_kernel_context with GuC submission 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: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Tue, Aug 10, 2021 at 08:47:10AM +0200, Daniel Vetter wrote: > On Mon, Aug 09, 2021 at 06:20:51PM +0000, Matthew Brost wrote: > > On Mon, Aug 09, 2021 at 04:27:01PM +0200, Daniel Vetter wrote: > > > On Tue, Aug 03, 2021 at 03:29:08PM -0700, Matthew Brost wrote: > > > > Calling switch_to_kernel_context isn't needed if the engine PM reference > > > > is taken while all contexts are pinned. By not calling > > > > switch_to_kernel_context we save on issuing a request to the engine. > > > > > > > > Signed-off-by: Matthew Brost > > > > --- > > > > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 ++++ > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c > > > > index 1f07ac4e0672..58099de6bf07 100644 > > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c > > > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c > > > > @@ -162,6 +162,10 @@ static bool switch_to_kernel_context(struct intel_engine_cs *engine) > > > > unsigned long flags; > > > > bool result = true; > > > > > > > > + /* No need to switch_to_kernel_context if GuC submission */ > > > > > > Maybe whack a big FIXME on here that we should unravel this properly. > > > > Sure, can add a FIXME here. > > > > > Currently the execlist backend assumptions are leaked all over the place, > > > leading to stuff like this. Which means extremely fragile code. > > > > > > > Yes, this something required for execlists implemented in what should be > > generic code. > > > > > I currently don't have a great idea on how exactly we should do that, but > > > oh well. > > > > Me either, it will be a process. > > > > > > > > btw just in case we ever want to make guc lrc properly evictable (which as > > > the og use-case for this function, way, way back), would we need to fully > > > > Can you explain what you mean by fully evictable? Not getting what you > > mean in this context. > > > > > unregister them from guc? At least I'm assuming there's no other trick > > > > If scheduling is disabled on the context (currently done on unpin) you are > > free move anything around as the GuC is guaranteed not to touch the > > context state. If on re-pin something has moved (e.g. the LRC vaddr is > > different), you need to unregister and re-register the context with the > > GuC. > > So at that point GuC also guarantees that it's not left in the hw engine? > Execlist has this barrier request to fully unload the ctx from the hw, and > that's also why I cam on the topic of OA. > > > > like the below one. > > > > > > Another aside: How does the perf/OA patching work on GuC? > > > > > > > Not my area of expertise but perf somewhat a WIP. The plan is for the > > GuC to write out some stats to HWSP I think? John Harrison is working to > > get this fully implemented. > > > > OA is working afaik, with Umesh Nerlige Ramappa being the expert here. > > I think it's OA that I'm thinking of here: We have code in i915_perf.c to > patch all the ctx currently in the system, so that they have a consistent > OA config. That's also relying on this barrier stuff, and I was wondering > how that will work with GuC. > -Daniel > Not an OA expert at all but glanced at the code I don't see anything in there that prevents it working with GuC submission. We certainly have this working internally. If you have questions about this I'd reach out to Umesh Nerlige Ramappa as he likely has the answers. Matt > > > > Matt > > > > > Anyway, patch looks legit: > > > > > > Reviewed-by: Daniel Vetter > > > > > > > > > > + if (intel_engine_uses_guc(engine)) > > > > + return true; > > > > + > > > > /* GPU is pointing to the void, as good as in the kernel context. */ > > > > if (intel_gt_is_wedged(engine->gt)) > > > > return true; > > > > -- > > > > 2.28.0 > > > > > > > > > > -- > > > Daniel Vetter > > > Software Engineer, Intel Corporation > > > http://blog.ffwll.ch > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch