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 C9321C04FFE for ; Sat, 18 May 2024 01:57:18 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5451210E165; Sat, 18 May 2024 01:57:18 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="n97WRGEp"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by gabe.freedesktop.org (Postfix) with ESMTPS id 712D610E165 for ; Sat, 18 May 2024 01:57:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1715997436; x=1747533436; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=372EL5i1vv3OYhzLLeciKH2AdxD8R+j9rq0Q6SB70vo=; b=n97WRGEps1g32et3r4gKIuSUGYdLcW88zUuy5wNY5xtth8tbK7RAPALh Xi3h9oIQR8wBaotzkXEMVPRLdgdGPgXssJYjhgSbwm5sLYaYBNbxPaKHm Od9g/XQZ/8svNBwjhCPB1PeUSAo8KZ7OB25L19v9miA0YqClmu2LzIzrr osrS52rZsd+0RgAVv++fzfUnkkdLWlQlfaH2lsHGHitXQucx0bhtcQtuW a4Z9up5kSKmdcoL3DGzDXDXtZNRjp7q8YiYv6ImdMUZa+bKFkZYvMoLHd zQwsAro9Bgx9H1vKxh3UnuL40NcVwrTSx82o2DjuMM5gP8747NEPxEf/j g==; X-CSE-ConnectionGUID: Pwk4Hw63RI6Ev5EW+F4L/A== X-CSE-MsgGUID: 639cJzrVTZ6Cr6oxUwZAxQ== X-IronPort-AV: E=McAfee;i="6600,9927,11075"; a="22871587" X-IronPort-AV: E=Sophos;i="6.08,169,1712646000"; d="scan'208";a="22871587" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 May 2024 18:57:15 -0700 X-CSE-ConnectionGUID: JmvxllnbS3OLiiVEWdRuHA== X-CSE-MsgGUID: H2Zj5/F0T0aickqyKUpoRw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,169,1712646000"; d="scan'208";a="31985898" Received: from esurjono-mobl1.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.92.233.72]) by fmviesa009-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 May 2024 18:57:15 -0700 Date: Fri, 17 May 2024 18:42:13 -0700 Message-ID: <87frufuc96.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: "Souza, Jose" Cc: "intel-xe@lists.freedesktop.org" , "Landwerlin, Lionel G" , Umesh Nerlige Ramappa , Robert Krzemien Subject: Re: [PATCH 00/17] Add OA functionality to Xe In-Reply-To: <438b276a653bf56fe1e0e131709d615dec86ae3e.camel@intel.com> References: <20240315013518.2848986-1-ashutosh.dixit@intel.com> <438b276a653bf56fe1e0e131709d615dec86ae3e.camel@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.3 (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 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: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Fri, 17 May 2024 11:42:39 -0700, Souza, Jose wrote: > Hi Jose, > Hi > > I hope I'm replying to the latest version... > > Just a few comments I have in the uAPI: > > - Rename DRM_XE_OA_PROPERTY_OA_EXPONENT to DRM_XE_OA_PROPERTY_OA_PERIOD_EXPONENT, for better clarity. Sure, will do. > - Some Perf uAPIs added here don't have usage in Mesa, see those below. Not sure if MDAPI or gviz will make use of it, if not the approach is to > remove uAPIs until there is UMD using it: > - DRM_XE_PERF_IOCTL_INFO + drm_xe_oa_stream_info MDAPI uses this to implement mmap + mmio trigger. > - DRM_XE_DEVICE_QUERY_OA_UNITS + drm_xe_query_oa_units + drm_xe_oa_unit Yes Gpuvis as well as I believe MDAPI use this. Actually I am surprised Mesa is not using this. Basically the query provides the following information: * Which engines are attached to which OA units. This maybe Mesa can skip since render engine is almost certainly attached to OA unit 0 (DRM_XE_OA_PROPERTY_OA_UNIT_ID to be provided when opening OA stream). * But the query also provides oa_timestamp_freq which needs to be used in interpreting OA timestamps. oa_timestamp_freq can differ from reference_clock included in 'struct drm_xe_gt' for certain platforms (currently DG2/PVC/MTL). So if Mesa needs to work for these platforms, you need to use drm_xe_query_oa_units. > - DRM_XE_OASTATUS_* values are based on HW definition, I think it should > not follow HW at least for DRM_XE_OASTATUS_MMIO_TRG_Q_FULL and avoid have > a blank space of bits not used in the uAPI Sure, will change this too. Umesh also mentioned this. > - Perf stream read() should give us a hint that drm_xe_oa_stream_status > - needs to be read, that discussion is already in progress thank you for > - that Yes, we are going ahead with that, read() will return EIO errno when KMD encounters errors (or oastatus) signalled by HW, and when UMD sees that, UMD can call the stream status ioctl to get the status. > > Other than that the uAPI LGTM. > > There is the hold_preemption feature that is missing but I think that can > be added later... Yes, the plan is to implement it soon. Also another feature to synchronize OA unit programming with workload submission is missing, and the plan is to implement that soon too. Hopefully, we can get what we currently have merged first, based on Mesa and GpuVis pull requests and do these missing pieces as follow on's. > > thank you Thanks for the review and feedback :) -- Ashutosh