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 4C144C25B4F for ; Wed, 16 Aug 2023 20:38:29 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0584110E3B4; Wed, 16 Aug 2023 20:38:29 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id B577610E3B4 for ; Wed, 16 Aug 2023 20:38:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1692218306; x=1723754306; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=dNSs+kzuJAFWhPS8/WsYV5+55SFbrKoMQ3UB4Qqp8uk=; b=BxnnxkCVWmhLBCrz6pFGGSwSQ91J/OAZ9MjrfNei9Asbo04X795BvXw+ 8BhJceMLZt1QGwrZpiNsk6aopkQAfg/QrbpsutShcOf19rjZjbQYQzJ1n Q19PtTsqS+/DVxPDa8lBEVQ/H8ijQ3dGN0mg3PfLRii0HhxjIQroJ/+7d SX5/zIiW4Q08Ev5ZDV0JhdXqiI11YPcAuAXHcRBmEoy7MnL4b5JdBO4bu 4YKum/3IRLDOR7Fp+ct9o9WjzQQ9yTzvgUOG/kDE5nsAjNdl2veQeS6Xr gjEMUM5XuCeadJq8WEM4THTAXh3p4O4wa7ksvD3rwRaGD7G0yX4qAZg4M A==; X-IronPort-AV: E=McAfee;i="6600,9927,10803"; a="376368973" X-IronPort-AV: E=Sophos;i="6.01,178,1684825200"; d="scan'208";a="376368973" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Aug 2023 13:38:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10803"; a="737420241" X-IronPort-AV: E=Sophos;i="6.01,178,1684825200"; d="scan'208";a="737420241" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.212.35.6]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Aug 2023 13:38:25 -0700 Date: Wed, 16 Aug 2023 13:38:25 -0700 Message-ID: <87ttsysoxq.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa In-Reply-To: References: <20230808013159.38811-1-ashutosh.dixit@intel.com> <20230808013159.38811-2-ashutosh.dixit@intel.com> <871qg4t132.wl-ashutosh.dixit@intel.com> <87y1ibsriz.wl-ashutosh.dixit@intel.com> <87wmxvslc4.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/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 01/10] drm/xe/oa: Introduce OA uapi 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 Wed, 16 Aug 2023 12:58:52 -0700, Umesh Nerlige Ramappa wrote: > Hi Umesh, > On Tue, Aug 15, 2023 at 08:43:55PM -0700, Dixit, Ashutosh wrote: > > On Tue, 15 Aug 2023 19:21:23 -0700, Umesh Nerlige Ramappa wrote: > >> > >> On Tue, Aug 15, 2023 at 06:30:12PM -0700, Dixit, Ashutosh wrote: > >> > On Tue, 15 Aug 2023 18:11:55 -0700, Umesh Nerlige Ramappa wrote: > >> >> > >> >> >> + /** > >> >> >> + * Multiple engines may be mapped to the same OA unit. The OA unit is > >> >> >> + * identified by class:instance of any engine mapped to it. > >> >> >> + * > >> >> >> + * This parameter specifies the engine class and must be passed along > >> >> >> + * with DRM_XE_OA_PROP_OA_ENGINE_INSTANCE. > >> >> >> + */ > >> >> >> + DRM_XE_OA_PROP_OA_ENGINE_CLASS, > >> >> >> + > >> >> >> + /** > >> >> >> + * This parameter specifies the engine instance and must be passed along > >> >> >> + * with DRM_XE_OA_PROP_OA_ENGINE_CLASS. > >> >> >> + */ > >> >> >> + DRM_XE_OA_PROP_OA_ENGINE_INSTANCE, > >> >> > > >> >> > Because oa_unit_id has been introduced above in > >> >> > drm_xe_engine_class_instance, should we remove these engine class/instance > >> >> > properties? Since it seems OA streams can be opened directly against the oa > >> >> > unit identified by oa_unit_id. And the driver can itself figure out the > >> >> > engine class/instance from the oa_unit_id? > >> >> > >> >> Agree for the OA buffer use case. > >> >> > >> >> For query, we have used the class:instance to enable query support for > >> >> specific engine instance. If we can work around that somehow, then we can > >> >> do away with these 2 params. More like enable query for all engines that > >> >> belong to the OAG unit. For render, it is straight forward since we have > >> >> one render per OAG unit. For compute, multiple compute instances can map to > >> >> one OAG unit and only one instance can support the query. So user may want > >> >> to choose which instance that is. Although, I would just simplify it and > >> >> support only instance 0 of compute. If UMD is okay with it, then we should > >> >> be good. > >> > > >> > Can we enable the query (I guess "query" is MI_RPC) on all attached compute > >> > engines and have the UMD execute the query on any of the attached engines? > >> > Or is this mode of operation never been tried out before so risky? > >> > >> We cannot, since that is gated by a global configuration in HW that selects > >> a specific instance to enable the query for compute (ccs_select to be > >> specific). I think the limitation is that HW has only one OAC unit and only > >> one ccs can use it. > > > > OK. But iiuc there is also a context (or, in Xe, an exec_queue). So we > > should be able to turn on the query on the context/exec_queue hw_engine, no? > > Assuming more than one hw_engine in the context/exec_queue is an error? > > The global config (ccs_select) needs to be applied at the context switch > granularity which the KMD is unaware of. If the ccs_select configuration > were a part of the context image, it would have been simpler. If we were to > do this, it would have to be in the WA batch buffer in the context. The WA > batch would run every context switch and would do an LRI on the global > register. Possible, but hacky and architecturally incorrect since we would > be modifying a global state from the context. I think you misunderstood. I was only saying (e.g. with the current uapi) that 'drm_xe_oa_property_id' has a 'DRM_XE_OA_PROP_EXEC_QUEUE_ID' field in it. So we know which exec_queue (XE exec_queue is equivalent to i915 gem_context) the query needs to run on. And we know the exec_queue engine class as well as which hardware engines are backing that exec_queue. So now say instead of having engine ci in 'drm_xe_oa_property_id' we can say get the engine ci from exec_queue. This is just exec_q->hwe[0]. So if we have multiple hwe's backing backing the exec_q (say a compute virtual engine) we can restrict that the query runs only on the 0'th hwe. If we include engine ci in 'drm_xe_oa_property_id', the query can run on any hwe backing the exec_queue. In this case we need engine ci in 'drm_xe_oa_property_id', if we can impose the restriction that the query only run on exec_q->hwe[0], then we don't. (The correction I have from my previous mail that having only a single hwe in an exec_queue will probably be unacceptable). Though I am now thinking just leaving engine ci in 'drm_xe_oa_property_id' since there is a valid use case for it. Thanks. -- Ashutosh > >> >> > >> >> Media engines do not support query, so we should be good for OAM. > >> >> > >> >> > > >> >> > Separately, there is also the question of whether we want to share the Xe > >> >> > OA IGT code with i915 as was done for this series. Since duplicating the > >> >> > IGT code as well as all the perf tools seems a bit much. > >> >> > > >> >> > Thanks. > >> >> > -- > >> >> > Ashutosh