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 C2AA2C02182 for ; Wed, 22 Jan 2025 03:00:32 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7293A10E2E0; Wed, 22 Jan 2025 03:00:32 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="hYrzm6Me"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7E06310E2E0 for ; Wed, 22 Jan 2025 03:00:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1737514831; x=1769050831; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=R63AtUPEEYEsL5yHlGH3xqLfgKY0ZsPq8xy1N+BADR4=; b=hYrzm6MeU/Ds0KOARdx1kXr7prSNxHavgHepHayoW8XB2ybfexWk2wBY QOkm00H9U5kQMxzmSlgmLyppeKtaf4hHS6FXauZFnXAMyvQOkIl4MHCD1 2/BVNbKc8k2B7A2+MgA6tN9npf7d2FiUcXm+YUz/mtoB5rgqnQCRdbXTE PEwNw7DqloiBRNY/XcfittmxNy6wTxk3C+Un127QmirNzEC8hgPESXcEg DJj36+Xxm4BkWGo+vEUIJQ/Q1c6kyspwER5YNzkUBrD9zritqkQ8k7v+z 4R38E6HzmHkzoMg11h+3aY6Tp3UHuxkpBJVQWBDURrfR9MEolQh1LylpW w==; X-CSE-ConnectionGUID: DFlq1Nf2QvCe2wH9ObPN7g== X-CSE-MsgGUID: hysglA0zTR6/fkE2QMssHA== X-IronPort-AV: E=McAfee;i="6700,10204,11322"; a="63312414" X-IronPort-AV: E=Sophos;i="6.13,223,1732608000"; d="scan'208";a="63312414" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jan 2025 19:00:31 -0800 X-CSE-ConnectionGUID: +YdkKZirRZ2BMykCjT9uvw== X-CSE-MsgGUID: AK6w5EUtQlKm5Fqo/9R3WQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,223,1732608000"; d="scan'208";a="106820558" Received: from orsosgc001.jf.intel.com (HELO orsosgc001.intel.com) ([10.165.21.142]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jan 2025 19:00:28 -0800 Date: Tue, 21 Jan 2025 19:00:23 -0800 Message-ID: <85cygflfi0.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Harish Chegondi Cc: , , , , , , , , Subject: Re: [PATCH v8 6/7] drm/xe/uapi: Add a device query to get EU stall sampling information In-Reply-To: References: <9452fc2774136a6a977655487db7616316483823.1736970203.git.harish.chegondi@intel.com> <85plkme6b0.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-redhat-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 Tue, 21 Jan 2025 18:48:55 -0800, Harish Chegondi wrote: > Hi Harish, > On Thu, Jan 16, 2025 at 02:34:59PM -0800, Dixit, Ashutosh wrote: > > On Wed, 15 Jan 2025 12:02:12 -0800, Harish Chegondi wrote: > > > diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h > > > index d9b20afc57c1..7d518f97ba34 100644 > > > --- a/include/uapi/drm/xe_drm.h > > > +++ b/include/uapi/drm/xe_drm.h > > > @@ -700,6 +700,7 @@ struct drm_xe_device_query { > > > #define DRM_XE_DEVICE_QUERY_ENGINE_CYCLES 6 > > > #define DRM_XE_DEVICE_QUERY_UC_FW_VERSION 7 > > > #define DRM_XE_DEVICE_QUERY_OA_UNITS 8 > > > +#define DRM_XE_DEVICE_QUERY_EU_STALL 9 > > > /** @query: The type of data to query */ > > > __u32 query; > > > > > > @@ -1754,8 +1755,8 @@ enum drm_xe_eu_stall_property_id { > > > DRM_XE_EU_STALL_PROP_GT_ID = 1, > > > > > > /** > > > - * @DRM_XE_EU_STALL_PROP_SAMPLE_RATE: Sampling rate > > > - * in GPU cycles. > > > + * @DRM_XE_EU_STALL_PROP_SAMPLE_RATE: Sampling rate in > > > + * GPU cycles from @sampling_rates in struct @drm_xe_query_eu_stall > > > */ > > > DRM_XE_EU_STALL_PROP_SAMPLE_RATE, > > > > > > @@ -1767,6 +1768,41 @@ enum drm_xe_eu_stall_property_id { > > > DRM_XE_EU_STALL_PROP_WAIT_NUM_REPORTS, > > > }; > > > > > > +/** > > > + * struct drm_xe_query_eu_stall - Information about EU stall sampling. > > > + * > > > + * If a query is made with a struct @drm_xe_device_query where .query > > > + * is equal to @DRM_XE_DEVICE_QUERY_EU_STALL, then the reply uses > > > + * struct @drm_xe_query_eu_stall in .data. > > > + */ > > > +struct drm_xe_query_eu_stall { > > > + /** @extensions: Pointer to the first extension struct, if any */ > > > + __u64 extensions; > > > + > > > + /** @capabilities: EU stall capabilities bit-mask */ > > > + __u64 capabilities; > > > +#define DRM_XE_EU_STALL_CAPS_BASE (1 << 0) > > > + > > > + /** @record_size: size of each EU stall data record */ > > > + __u64 record_size; > > > + > > > + /** @per_xecore_buf_size: Per XeCore buffer size */ > > > + __u64 per_xecore_buf_size; > > > > Someone else should still probably check if the term "xecore" in > > "per_xecore_buf_size" is appropriate. I don't know if it is, or if it is > > future proof, as I had remarked earlier. > Had a chat with Matt Roper offline regarding this. He said XeCore is a > formal name in the hardware for a GPU core. So I think this is > appropriate. OK, in that case I am fine with this. Let's put this to rest :) > > > > > + > > > + /** @num_sampling_rates: Number of sampling rates supported */ > > > + __u64 num_sampling_rates; > > > + > > > + /** @reserved: Reserved */ > > > + __u64 reserved[5]; > > > > I think we should move this reserved array before num_sampling_rates. If > > later we take up a reserved u64 (replace it by a different struct member) > > we'd want num_sampling_rates and sampling_rates[] together. > I noticed that in structures with reserved fields, the reserved > fields are at the bottom of the structure. Although flexible array > sampling_rates is at the bottom, no storage is allocated for > sampling_rates. I can move the reserved array, but is it okay for > reserved array to not be at the end of the structure? Even if I move, > the num_sampling_rates and sampling_rates[] will be next to each other, > but no storage will be allocated to sampling_rates. Yes let's move it before num_sampling_rates. Look at 'struct drm_xe_oa_unit'. > > > > > + > > > + /** > > > + * @sampling_rates: Flexible array of sampling rates > > > + * sorted in the fastest to slowest order. > > > + * Sampling rates are specified in GPU clock cycles. > > > + */ > > > + __u64 sampling_rates[]; > > > +}; > > > > The Mesa PR still seems to have some data structs from an older version, > > but after addressing the above comments, the uapi introduced in this series > > is LGTM, so for the uapi: > > > > Acked-by: Ashutosh Dixit