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 BEA78C4332F for ; Tue, 31 Oct 2023 06:51:31 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7394310E406; Tue, 31 Oct 2023 06:51:31 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.136]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0F82E10E406 for ; Tue, 31 Oct 2023 06:51:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1698735089; x=1730271089; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=5O+5rI/1xXyzm93r/s53fZVWgTEzYRgVTcZVN3PdJcc=; b=GXhBvCy/t9HfMpysj51Nq7OeRdEcgt4SWMxl8qJRYczd/lXsUq9o7s0o EXo6yqrGrKziLiQYV+d0g4fuqt3/j5RK7YqpnjKSJJ2A2yYn5hIicKcK+ e/AGie44/K20fYlw+918g+aU8gLGRJA3BRsKlWSt10GZz0BJWVeI40yDn /GGKTQklV23jqL8KQZIZktEg0vdcm8xVYxY1D0GoL0u8HpY5u8DB7ijUZ ypgY+/yib8kzbzG0FBZiBKfKroEksV3vI+4ABl43GLprSHdAUQabMiWS5 8lZpGP5St9Ih2Tr1Qo8vQi5Fqi9XoNkCc40JEnNgSFDyBxrSnM95nuSNI Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10879"; a="367571023" X-IronPort-AV: E=Sophos;i="6.03,265,1694761200"; d="scan'208";a="367571023" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Oct 2023 23:51:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10879"; a="736982168" X-IronPort-AV: E=Sophos;i="6.03,265,1694761200"; d="scan'208";a="736982168" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.212.202.129]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Oct 2023 23:51:28 -0700 Date: Mon, 30 Oct 2023 23:51:27 -0700 Message-ID: <87r0lb9te8.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Lionel Landwerlin In-Reply-To: References: <20230919161049.2307855-1-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/29.1 (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-xe] [PATCH 00/21] Add OA functionality to Xe X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-xe@lists.freedesktop.org Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Fri, 20 Oct 2023 00:52:17 -0700, Lionel Landwerlin wrote: Hi Lionel, > > On 20/10/2023 10:44, Lionel Landwerlin wrote: > > On 19/09/2023 19:10, Ashutosh Dixit wrote: > >> This patchset is the initial port of i915 perf/OA functionality to the > >> XE > >> driver. The following features in i915 have not been ported and will be > >> added (as new patches) if/as they are needed: > >> > >> * Inline batch submission on stream exec_queue/hw_engine > > > > If you give us a syncobj to wait on for the NOA reconfiguration this > > won't be necessary > > > >> * NOA wait > > > > This is kind of required, otherwise we start reading reports from the OA > > buffer and the values are garbage > > Actually thinking about it, we could use the syncobj you give us and do > the wait in a userspace batch. Hmm. Why do we need to do this in userspace? What I was thinking was (a) KMD submits a few batch buffers to program various things and returns from the open/reconfigure IOCTL (b) KMD can detect (using fences) when the submitted batches complete (c) After the batches complete, KMD adds an addtional 500 us (NOA wait) delay (using the CPU) before signalling the fence in the uapi. Wouldn't this work? > > > >> * GuC ctx id (guc_sw_ctx_id) > > > > This is probably fine. On Gfx8 we always consider using OA a privileged > > operation, if we keep it like that then it's okay. > > > >> * CTX_R_PWR_CLK_STATE/GEN8_R_PWR_CLK_STATE > > I think if we never care about Gfx11 that's fine. Great, yes no plan to support Gfx11. I was really scared that we don't have this so it is great to get some confirmation it's not needed for Gfx12+. > >> * hold_preemption (DRM_XE_OA_PROP_HOLD_PREEMPTION) > > > > Without this, we can't implement perf queries in userspace. > > > > Maybe that's okay? Is it ok? You tell me. You mean OAR/OAC MI_RPC like queries? They are not needed? We were thinking we'll need to support this eventually. > > > >> * sseu_config (DRM_XE_OA_PROP_GLOBAL_SSEU) > > Without Gfx11 probably fine. Yup no plan to support Gfx11. Thanks for the confirmation on this too. > >> * MTL bios_c6_setup > >> * ratelimits > >> * compat ioctl Thanks. -- Ashutosh