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 8FBB2C61DA4 for ; Fri, 10 Mar 2023 00:24:11 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3E00110E8DE; Fri, 10 Mar 2023 00:24:10 +0000 (UTC) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id C571210E8DE for ; Fri, 10 Mar 2023 00:24:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678407847; x=1709943847; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=cFpqDhQnFpOjClumRdcoZ9s8x3X6XgwlxWyEDSO8lRo=; b=ZkOEEo/Z2jVAht+xmo8sOclgovlYkp7URXJ+R1A8zcz9PZq4FhCmqv76 imQy0N74wUXZisp7cJis1V5X4h0DVK7VinAk8+Tc4VKSgMUIYGSrs5T/k BocazmrvZz6ZOfGjx8lOGgb1VckK/dda0PLb81kpU5lV+vJYyVTDLRx21 QLUf9R+euQ0zsVKeEPiGDt0r+tSrohgFpdYxkVdIdMv2LCxWKSWtj/nH3 alwyMXBP7aiNLIW6sZ7U4Rbbls8f+XSnkYSbgWvL4sL9Ne08RfCGcBwKr HYgoxdZfnNbiPgAjcOJiBwUuyve2GJtuJiAXCU3CNIkHXzh7n0VjceDFc g==; X-IronPort-AV: E=McAfee;i="6500,9779,10644"; a="334084581" X-IronPort-AV: E=Sophos;i="5.98,248,1673942400"; d="scan'208";a="334084581" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Mar 2023 16:24:07 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10644"; a="766632145" X-IronPort-AV: E=Sophos;i="5.98,248,1673942400"; d="scan'208";a="766632145" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.212.215.176]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Mar 2023 16:24:06 -0800 Date: Thu, 09 Mar 2023 16:24:06 -0800 Message-ID: <878rg5mp21.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa In-Reply-To: References: <20230307201611.773103-1-umesh.nerlige.ramappa@intel.com> <20230307201611.773103-9-umesh.nerlige.ramappa@intel.com> <87h6uvm7zm.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/28.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 v4 8/9] drm/i915/perf: Add engine class instance parameters to perf 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 Thu, 09 Mar 2023 14:34:04 -0800, Umesh Nerlige Ramappa wrote: > Hi Umesh, > On Wed, Mar 08, 2023 at 10:08:13AM -0800, Dixit, Ashutosh wrote: > > On Tue, 07 Mar 2023 12:16:10 -0800, Umesh Nerlige Ramappa wrote: > >> > > > >> One or more engines map to a specific OA unit. All reports from these > >> engines are captured in the OA buffer managed by this OA unit. > >> > >> Current i915 OA implementation supports only the OAG unit. OAG primarily > >> caters to render engine, so i915 OA uses render as the default engine > >> in the OA implementation. Since there are more OA units on newer > >> hardware that map to other engines, allow user to pass engine class and > >> instance to select and program specific OA units. > > > > I believe there is another uapi issue to be resolved here: how the engines > > are associated with OA units, since from the point of view of the uapi > > there are multiple engines and multiple OA units (even if in the actual > > implementation at present there is only one OA unit per gt). In the > > internal tree we had added oa_unit_id to engine_info for this. So if > > multiple engines had the same oa_unit_id, user could pass class:instance of > > any of those engines to get oa data from that OA unit (and generally know > > how engines are hooked up to OA units (the OA unit topology)). > > > > So the question is even if we don't implement it as part of this series (or > > do we have to?) do we at least need to agree to that uapi which will be > > used to associate OA units with engines? > > It did make more sense for xehpsdv and other platforms where we had > multiple OA units per GT and each GT had render and/or compute engines. In > those cases, media and compute/render UMDs may have needed to know that > topology. > > For MTL, I don't think that an end user will benefit from the > engine<->oa_unit mapping because > > (1) media and render are separate GTs > (2) there is just one OA unit per GT and > (3) assuming media and render/compute are separate UMDs, Well our uapi does not expose any of this so we are relying on outside information here. So I think it is needed even for MTL, but that's a problem for the person reviewing the uapi. Afaiac we can do it later if/when there is a specific ask for it, it's ok with me as is. I will R-b the patch after we fix the engine class/instance pairing. Thanks. -- Ashutosh > > That's also the reason why the corresponding IGT series just uses a static > mapping for MTL. > > If we come across a case where the UMD needs this info OR we are supporting > a platform with multiple OA units per tile, we should add the topology.