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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 63589C433EF for ; Wed, 27 Apr 2022 18:24:43 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id EA59910F793; Wed, 27 Apr 2022 18:24:42 +0000 (UTC) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4771F10F793 for ; Wed, 27 Apr 2022 18:24:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1651083881; x=1682619881; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=3ONhC5W6YkzEr0/K1ZxWKlFt65l6vPwUcWf5MeCtUQU=; b=YLSdoBWvDbYIGzG2J52QqOdSE7TxgusFXHKLFmPeL1q6hBMow4XF3ICB FBU/BnGOPazAEu6qx9bXgQ109oDtJkugUVZ0iNaF1BLfIVxXscNX2dfQr vPAagZ6vTl72QTtYG1rtjenSyZ7EMKn7I1N/BKyZaBYnmatOvNTltBdH2 aZ8XqVl0P34LXuha1WlUvK/TiGBuT7ZAXTQ6z0d0aRolvuvMC7H2SyDim 1/rAOPqoKsOhkEwyVE/jTBgzZQ0jQmjxxp6VoN6bbFFfszZOJEw5HYVBa O1qSNUiTGvetryEJXJlamE7cy2kTQ+FzqmOw4Kkufzz0/UOHpvN9jblI4 A==; X-IronPort-AV: E=McAfee;i="6400,9594,10330"; a="266190380" X-IronPort-AV: E=Sophos;i="5.90,293,1643702400"; d="scan'208";a="266190380" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2022 11:24:40 -0700 X-IronPort-AV: E=Sophos;i="5.90,293,1643702400"; d="scan'208";a="533360394" Received: from adixit-mobl1.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.212.232.118]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2022 11:24:40 -0700 Date: Wed, 27 Apr 2022 11:24:40 -0700 Message-ID: <87h76e5qqf.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Tvrtko Ursulin In-Reply-To: References: <20220413225732.34943-1-ashutosh.dixit@intel.com> <22e84175-eef3-5ef3-14f0-8a19bbdab70e@linux.intel.com> <87levq5y6d.wl-ashutosh.dixit@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: Re: [Intel-gfx] [PATCH v3] drm/i915: Don't show engine information in fdinfo 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: , Cc: intel-gfx@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Wed, 27 Apr 2022 10:16:03 -0700, Tvrtko Ursulin wrote: > > > On 27/04/2022 16:43, Dixit, Ashutosh wrote: > > On Wed, 27 Apr 2022 02:15:35 -0700, Tvrtko Ursulin wrote: > >> > >> On 15/04/2022 01:25, Ashutosh Dixit wrote: > >>> At present i915 does not fetch busyness information from GuC, resulting in > >>> incorrect busyness values in fdinfo. Because engine information is coupled > >>> with busyness in fdinfo, skip showing client engine information in fdinfo > >>> with GuC submission till fetching busyness is supported in the i915 GuC > >>> submission backend. > >>> > >>> v2 (Daniele): > >>> Make commit title and description more precise > >>> Add FIXME with brief description at code change > >>> s/intel_guc_submission_is_used/intel_uc_uses_guc_submission/ > >>> > >>> v3 (Daniele): > >>> Drop FIXME in comment > >>> > >>> Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/5564 > >>> Fixes: 055634e4b62f ("drm/i915: Expose client engine utilisation via fdinfo") > >>> Cc: Daniele Ceraolo Spurio >>> Cc: Umesh Nerlige Ramappa > >>> Signed-off-by: Ashutosh Dixit > >>> Reviewed-by: Daniele Ceraolo Spurio > >>> --- > >>> drivers/gpu/drm/i915/i915_drm_client.c | 6 +++++- > >>> 1 file changed, 5 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c b/drivers/gpu/drm/i915/i915_drm_client.c > >>> index e539f6b23060..475a6f824cad 100644 > >>> --- a/drivers/gpu/drm/i915/i915_drm_client.c > >>> +++ b/drivers/gpu/drm/i915/i915_drm_client.c > >>> @@ -145,7 +145,11 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct file *f) > >>> PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn)); > >>> seq_printf(m, "drm-client-id:\t%u\n", client->id); > >>> - if (GRAPHICS_VER(i915) < 8) > >>> + /* > >>> + * Temporarily skip showing client engine information with GuC submission till > >>> + * fetching engine busyness is implemented in the GuC submission backend > >>> + */ > >>> + if (GRAPHICS_VER(i915) < 8 || intel_uc_uses_guc_submission(&i915->gt0.uc)) > >>> return; > >>> for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++) > >> > >> Thanks for fixing this while I was away. It was a simple miss, nothing > >> sinister. In terms of mention of "garbage" numbers being reported - were > >> they actually garbage or simply always zero? > > > > Ah, you are referring to what I wrote in the bug. Actually I didn't check > > the values myself but was told we were displaying "garbage" values (or at > > least I interpreted it that way, and garbage meaning not just zero). But > > looking now at IGT outputs from that time appears the values were just zero > > :/ > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11503/re-adlp-pub1/igt@drm_fdinfo@all-busy-idle-check-all.html > > > > I think we could even have left zero values as is except that we'd have to > > fix the IGT failure. > > > > Sorry for the confusion. > > Np. One could even say that there is little difference between skip and > fail, given both need manual handling in cibuglog to be marked as known > until GuC support gets added. At least if I still remember how it works > and that unexplained skips still count as fails. True, I just updated https://gitlab.freedesktop.org/drm/intel/-/issues/5563. I think in retrospect we should have just changed the IGT check to ignore 0 busyness values :/