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 7BA51C369B2 for ; Mon, 14 Apr 2025 13:04:19 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id DADAD10E5A4; Mon, 14 Apr 2025 13:04:18 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=rosenzweig.io header.i=@rosenzweig.io header.b="RwkEBhad"; dkim-atps=neutral Received: from out-173.mta1.migadu.com (out-173.mta1.migadu.com [95.215.58.173]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4DF2710E5A4 for ; Mon, 14 Apr 2025 13:04:15 +0000 (UTC) Date: Mon, 14 Apr 2025 09:03:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rosenzweig.io; s=key1; t=1744635841; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=013VCEGBseMYx1I6gUwg2OHJ3SM8uQ36oc0kd7nu8zA=; b=RwkEBhadVRwvTMYA+H3LacAqX20Xj+RKODE+y5zgB12gS6WIYeHcgKkE85UXK9+IrXB7PQ yRjeHv0/XqE+QOrju8dTO1Q5Sc8wJnC3xJii+vkQ/YG1oMYNb+nyORF3sKq5vIF4lbI4eT LxBR6lRO/p4WpGaKC3GzroVzjLIiSx/5V5PnhmlF0mkD+xS/drEa6rivPdmk/86xzQbmsI U5g3sCHKuVr0CkaCUAh0VQAdtCCr1zqkVvVKGqXYShhUt5y6M9USB6QC9NPfRiUGLF5xQb xA0f4PQ1L+g0cY0ZfQDf+Flctpo9FRAQnh90nciIE8LT+3Vt4pcvJdBodT55MQ== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Alyssa Rosenzweig To: Boris Brezillon Cc: Simona Vetter , Christian =?iso-8859-1?Q?K=F6nig?= , Steven Price , Liviu Dudau , =?iso-8859-1?Q?Adri=E1n?= Larumbe , lima@lists.freedesktop.org, Qiang Yu , David Airlie , Simona Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , dri-devel@lists.freedesktop.org, Dmitry Osipenko , kernel@collabora.com, Faith Ekstrand Subject: Re: [PATCH v3 0/8] drm: Introduce sparse GEM shmem Message-ID: References: <20250404092634.2968115-1-boris.brezillon@collabora.com> <20250410164809.21109cbc@collabora.com> <20250410175349.6bf6a4ea@collabora.com> <20250410192054.24a592a5@collabora.com> <20250410204155.55d5cfc7@collabora.com> <20250414132206.728eacb3@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250414132206.728eacb3@collabora.com> X-Migadu-Flow: FLOW_OUT X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" > Actually, CSF stands in the way of re-allocating memory to other > contexts, because once we've allocated memory to a tiler heap, the FW > manages this pool of chunks, and recycles them. Mesa can intercept > the "returned chunks" and collect those chunks instead of re-assiging > then to the tiler heap through a CS instruction (which goes thought > the FW internallu), but that involves extra collaboration between the > UMD, KMD and FW which we don't have at the moment. Not saying never, > but I'd rather fix things gradually (first the blocking alloc in the > fence-signalling path, then the optimization to share the extra mem > reservation cost among contexts by returning the chunks to the global > kernel pool rather than directly to the heap). > > This approach should work fine with JM GPUs where the tiler heap is > entirely managed by the KMD though. I really think CSF should be relying on the simple heuristics with incremental-rendering, unless you can prove that's actually a performance issue in practice. (On Imagination/Apple parts, it almost never is and we rely entirely on this approach. It's ok - it really is. For simple 2D workloads, the initial heap allocation is fine. For 3D scenes, we need very few frames to get the right size. this doesn't cause stutters in practice.) For JM .. yes, this discussion remains relevant of course.