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 3F2EDEB64DA for ; Fri, 30 Jun 2023 23:46:27 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C8D3910E500; Fri, 30 Jun 2023 23:46:26 +0000 (UTC) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2311210E500 for ; Fri, 30 Jun 2023 23:46:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688168785; x=1719704785; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version:content-transfer-encoding; bh=COwdzNi9W6OFFx6En9/CJyvrx5VCC3HZq/jQgStDlKw=; b=eh9wwz85XWbnPG6JhJsiuGaneGDXBNETqGFr7X0KNdkdH3di3pFYkcOl OHI/JmaieiONYzhAvhppZsp5IfT/lF9MZ3h4LKsHCrX+1NzBzej+nNdu/ kkh22TvC4v+PDvpK2Hhwqi/izekvWB9+wvMD1ri6Vw3HiDgm54/iVIGI8 LhvdQraLJaB6050ZxYTBwSjXRd97VBAaP19gsdAvIvjAzc3cHF9HqA7bo X6ximm+4lV1WWCiSvL5wqfiB7g4utYzEIWXu7peF6lSjhh69yF7VnQnyy dL2/XNnmTryHVQ7gMxwdmHgnUhae2zo6uqhAf6GxA69WaE9qaCo9tcez0 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10757"; a="361372814" X-IronPort-AV: E=Sophos;i="6.01,172,1684825200"; d="scan'208";a="361372814" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jun 2023 16:46:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10757"; a="891917971" X-IronPort-AV: E=Sophos;i="6.01,172,1684825200"; d="scan'208";a="891917971" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.212.173.53]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jun 2023 16:46:23 -0700 Date: Fri, 30 Jun 2023 16:40:54 -0700 Message-ID: <87bkgw5xix.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: intel-xe@lists.freedesktop.org In-Reply-To: <20230630100059.122881-1-thomas.hellstrom@linux.intel.com> References: <20230630100059.122881-1-thomas.hellstrom@linux.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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Intel-xe] [PATCH DONTMERGE] drm/xe: uapi review submission 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: Matt Roper , Lionel Landwerlin Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Fri, 30 Jun 2023 03:00:59 -0700, Thomas Hellstr=F6m wrote: > I have a question about the toplogy query below. I am not hugely familiar with why/how this particular struct was chosen nor the history here, but anyway. > +/** > + * struct drm_xe_query_topology_mask - describe the topology mask of a GT > + * > + * This is the hardware topology which reflects the internal physical > + * structure of the GPU. > + * > + * If a query is made with a struct drm_xe_device_query where .query > + * is equal to DRM_XE_DEVICE_QUERY_GT_TOPOLOGY, then the reply uses > + * struct drm_xe_query_topology_mask in .data. > + */ > +struct drm_xe_query_topology_mask { > + /** @gt_id: GT ID the mask is associated with */ > + __u16 gt_id; > + > + /* > + * To query the mask of Dual Sub Slices (DSS) available for geometry > + * operations. For example a query response containing the following > + * in mask: > + * DSS_GEOMETRY ff ff ff ff 00 00 00 00 > + * means 32 DSS are available for geometry. > + */ > +#define XE_TOPO_DSS_GEOMETRY (1 << 0) > + /* > + * To query the mask of Dual Sub Slices (DSS) available for compute > + * operations. For example a query response containing the following > + * in mask: > + * DSS_COMPUTE ff ff ff ff 00 00 00 00 > + * means 32 DSS are available for compute. > + */ > +#define XE_TOPO_DSS_COMPUTE (1 << 1) > + /* > + * To query the mask of Execution Units (EU) available per Dual Sub > + * Slices (DSS). For example a query response containing the following > + * in mask: > + * EU_PER_DSS ff ff 00 00 00 00 00 00 > + * means each DSS has 16 EU. > + */ > +#define XE_TOPO_EU_PER_DSS (1 << 2) > + /** @type: type of mask */ > + __u16 type; > + > + /** @num_bytes: number of bytes in requested mask */ > + __u32 num_bytes; > + > + /** @mask: little-endian mask of @num_bytes */ > + __u8 mask[]; > +}; So typically to consume the above struct, userspace needs additional information, specifically 'max_subslices' and 'max_eus_per_subslice' which was included in i915 'struct drm_i915_query_topology_info'. For example to consume 'struct drm_xe_query_topology_mask' I had recently to write the following code in IGT because this information was not available through 'struct drm_xe_query_topology_mask': /* Fixed fields, see fill_topology_info() and intel_sseu_set_info() in i91= 5 */ i915_topinfo.max_slices =3D 1; /* always 1 */ if (IS_PONTEVECCHIO(xe_dev_id(drm_fd))) { i915_topinfo.max_subslices =3D 64; i915_topinfo.max_eus_per_subslice =3D 8; } else if (intel_graphics_ver(xe_dev_id(drm_fd)) >=3D IP_VER(12, 50)) { i915_topinfo.max_subslices =3D 32; i915_topinfo.max_eus_per_subslice =3D 16; } else if (intel_graphics_ver(xe_dev_id(drm_fd)) >=3D IP_VER(12, 0)) { i915_topinfo.max_subslices =3D 6; i915_topinfo.max_eus_per_subslice =3D 16; } else { igt_assert(0); } So, if we are going to expose 'struct drm_xe_query_topology_mask' as it is above through xe uapi, are we assuming that userspace has out of band knowledge of 'max_subslices' and 'max_eus_per_subslice'? Or should this information be (somehow) added to the above struct? Another option (which sort of works but only approximately) would be to set 'num_bytes' field in 'struct drm_xe_query_topology_mask' to actual number of bytes in the mask. At present it is set unconditionally to 8 in query_gt_topology(), irrespective of the actual num bytes in the masks which is basically (again in i915 parlance): i915_topinfo.subslice_stride =3D DIV_ROUND_UP(i915_topinfo.max_subslices, = 8); i915_topinfo.eu_stride =3D DIV_ROUND_UP(i915_topinfo.max_eus_per_subslice,= 8); If we go the 'num_bytes' route, that would be just an implementation change not a uapi change. Thanks. -- Ashutosh