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 48E9EC27C41 for ; Wed, 16 Aug 2023 20:58:08 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E4B8010E3BF; Wed, 16 Aug 2023 20:58:07 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTPS id A626010E3BF for ; Wed, 16 Aug 2023 20:58:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1692219486; x=1723755486; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=eWLI4HB9HrIQkhSQ08Qenb98WEDS3r3jtxqZcPzS8oA=; b=dXaSB1v2jgIgbzQDtvTtnnED4RswciaPJrZ0aI3xEmkNlSuYSh5yHpxf uUnlu6BP/ttG6KnYMERLpNST2dcRPWBO4AtXZi1QtBc+KLc1zPTCd5VRd ir0UA+hV1uBppBk65h2mC0csVU3bL1IMB3CCknI5vLWet7tvsWINzKMgp Yu81xqNEuWWENo6G2h/oS6xQzo8OHN2szjRUAHBzbi/RxZ7H5nMs0giXx 9Yyv8iYYKw50T83aqOhbo9d6KHmSToLWFV5ciueOt/MTN3W7Suw+SJgJ+ rI3CmKG6aAdkn4AQrZSQXaOVwagKliEvjFfqtpF1ITxC1+IL70oex6pn6 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10803"; a="371538005" X-IronPort-AV: E=Sophos;i="6.01,178,1684825200"; d="scan'208";a="371538005" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Aug 2023 13:58:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10803"; a="727882068" X-IronPort-AV: E=Sophos;i="6.01,178,1684825200"; d="scan'208";a="727882068" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.212.35.6]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Aug 2023 13:58:05 -0700 Date: Wed, 16 Aug 2023 13:58:05 -0700 Message-ID: <87sf8iso0y.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa In-Reply-To: <87ttsysoxq.wl-ashutosh.dixit@intel.com> 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> <87ttsysoxq.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 13:38:25 -0700, Dixit, Ashutosh wrote: > > 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. Sorry for that rambling mail. But I think, to be fully accurate, we only need the hw engine instance in 'drm_xe_oa_property_id'. We can get the class from exec_q->class. 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