From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B843C382 for ; Tue, 12 Mar 2024 20:50:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.14 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710276602; cv=none; b=Vn1wbuVfalP4ODUngfffzDMz/F6ZOjx8oyTjDi1wZH7LPsW4N0D6Y83aU4/7DON1oURGacccXKBdJvhSjV6YfeyNwgvP1uzNwwPauPTVCdzJnQAT0wNSXXxTxdrfSq8k+ymsIjkGIpugwIxoLZYmvlRS0r2kerpivtdk9oFJxLg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710276602; c=relaxed/simple; bh=VFMRSQKdUMwPfeCwMiU1+0F+7PNO1K6kfl4Elf7RG9I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bmQJVKUyLuIKbbpewhVrVQXp6CgkX+vW6pJcRp/vy0Z8A2Ujvy7YUEFdKGHBifY+R0JmJ674jQiyH2JqeUfLRvQU0IDHvwCpvQC8PaIs46QL/CT8l+u/XrRZzyoZcU9tqAFLi1ytwRuRxpDb09VoXX2QRBi6mYC/Kb7ksu1Gq9I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Q3KpBxgN; arc=none smtp.client-ip=198.175.65.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Q3KpBxgN" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1710276601; x=1741812601; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=VFMRSQKdUMwPfeCwMiU1+0F+7PNO1K6kfl4Elf7RG9I=; b=Q3KpBxgNWtuyuH2g80kV5rrgaFlPlNCKmqdZgoWxQQngCxaVVUOh6cWH 7kZZkcFT85zqALN32ErxVpuvtwk4HGsX4POL1vLQcUxPb+sV/CTBRO6qG F/UU9/Xat8lspKKSBnXTHm+xeqf3YiT7fY7hV7m068yJTYn7MpcMST40s l01eBMhj/cc89QYyrXNbpC6PJFDlekm8g8WXayfDd3uihUZCvFLhRhOxA /Hs2ZRsJYkd9fR4C+ZT+c+ZzKBS2LNVQfd1CRZEgXspqaLNOrwOeasGP1 z6Hpnvkc+XKtOFtTaUMxXzzMEqRXrTslaCsksog4M9mvB/jCF3ZfdqY/P g==; X-IronPort-AV: E=McAfee;i="6600,9927,11011"; a="8832989" X-IronPort-AV: E=Sophos;i="6.07,119,1708416000"; d="scan'208";a="8832989" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Mar 2024 13:49:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,119,1708416000"; d="scan'208";a="12267870" Received: from unknown (HELO intel.com) ([10.247.118.142]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Mar 2024 13:49:46 -0700 Date: Tue, 12 Mar 2024 21:49:39 +0100 From: Andi Shyti To: Matt Roper Cc: Andi Shyti , intel-gfx , dri-devel , Chris Wilson , Joonas Lahtinen , John Harrison , stable@vger.kernel.org, Andi Shyti , Tvrtko Ursulin Subject: Re: [PATCH v5 2/4] drm/i915/gt: Refactor uabi engine class/instance list creation Message-ID: References: <20240308202223.406384-1-andi.shyti@linux.intel.com> <20240308202223.406384-3-andi.shyti@linux.intel.com> <20240312170833.GL718896@mdroper-desk1.amr.corp.intel.com> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240312170833.GL718896@mdroper-desk1.amr.corp.intel.com> On Tue, Mar 12, 2024 at 10:08:33AM -0700, Matt Roper wrote: > On Fri, Mar 08, 2024 at 09:22:17PM +0100, Andi Shyti wrote: > > For the upcoming changes we need a cleaner way to build the list > > of uabi engines. > > > > Suggested-by: Tvrtko Ursulin > > Signed-off-by: Andi Shyti > > Cc: # v6.2+ > > I don't really see why we need patches 2 & 3 in this series. For patch number '2' We had a round of review with Tvrtko and we wanted to avoid the change I pasted at the bottom[*], which would decrease something that was increased earlier. > If we want > to restrict the platform to a single CCS engine for now (and give that > single engine access to all of the cslices), it would be much simpler to > only create a single intel_engine_cs which which would then cause both > i915 and userspace to only consider a single engine, even if more than > one is physically present. That could be done with a simple adjustment > to engine_mask_apply_compute_fuses() to mask off extra bits from the > engine mask such that only a single CCS can get returned rather than the > mask of all CCSs that are present. > > Managing all of the engines in the KMD but only exposing one (some) of > them to userspace might be something we need if you want to add extra > functionality down to road to "hotplug" extra engines, or to allow > userspace to explicitly request multi-CCS mode. But none of that seems > necessary for this series, especially for something you're backporting > to stable kernels. It's true, it would even be easier to mask out all the CCS engines after the first. I thought of this. On one hand hand, adding a for_each_available_engine() throught the stable path its a bit of abusing, but it's functional to the single CCS mode. I was aiming for a longer term solution. If I add a patch to mask off CCS engines, then I will need to revert it quite soon for the stable release. I'm not sure which one is better, though. Thanks, Andi [*] diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c b/drivers/gpu/drm/i915/gt/intel_engine_user.c index 833987015b8b..7041acc77810 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c @@ -243,6 +243,15 @@ void intel_engines_driver_register(struct drm_i915_private *i915) if (engine->uabi_class == I915_NO_UABI_CLASS) continue; + /* + * Do not list and do not count CCS engines other than the first + */ + if (engine->uabi_class == I915_ENGINE_CLASS_COMPUTE && + engine->uabi_instance > 0) { + i915->engine_uabi_class_count[engine->uabi_class]--; + continue; + } + rb_link_node(&engine->uabi_node, prev, p); rb_insert_color(&engine->uabi_node, &i915->uabi_engines);