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 5B7C4C61DA4 for ; Fri, 3 Feb 2023 16:29:30 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 45ECA10E0D3; Fri, 3 Feb 2023 16:29:29 +0000 (UTC) Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by gabe.freedesktop.org (Postfix) with ESMTPS id E68A010E12F for ; Fri, 3 Feb 2023 16:29:26 +0000 (UTC) Received: from maud (138-51-85-230-lsn-2.nat.utoronto.ca [138.51.85.230]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: alyssa) by madras.collabora.co.uk (Postfix) with ESMTPSA id 5CFBA6602F11; Fri, 3 Feb 2023 16:29:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1675441765; bh=Xc7eybUvaWT1XYp5qxoixYCppZzDo091FOnr1TEYUvc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AEWy+VGC2CHUnZvw4CWdXluWbCIfXo4kUGST1DlEUw77YYZQD9Xck4YX/AUeavOtU lo/O4NzlsuCcuix0/Q7JW/EGRDpZpA9+K0cWTaATeegpBF/Lujp/5qqq4Dom5gbNGV Uo/WiM+ngaqkYxUSugu5oyaJyF/8ih1kD0Fp3hBjuHbfvGJagLHIYxRGkaedbtaV41 Z/IO/zDxdTFw38B1hDnggPKKjvhCgw3xEoectmhI9TsBDvLoF31zKkhEAcd7YwKTSL yrAk4JreO+OqYhNMMrc8d2qIJJQ6yi+bKIRSxHpEE/3lmiclLHqOCHQR+A5x/werBO cik3oa31+rrSA== Date: Fri, 3 Feb 2023 11:29:16 -0500 From: Alyssa Rosenzweig To: Steven Price Subject: Re: [RFC PATCH] drm/pancsf: Add a new driver for Mali CSF-based GPUs Message-ID: References: <20230201084832.1708866-1-boris.brezillon@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: , Cc: Daniel Stone , dri-devel@lists.freedesktop.org, Boris Brezillon , Alyssa Rosenzweig , Robin Murphy , Jason Ekstrand Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" > > Mali v10 (second Valhal iteration) and later GPUs replaced the Job > > Manager block by a command stream based interface called CSF (for > > Command Stream Frontend). This interface is not only turning the job > > chain based submission model into a command stream based one, but also > > introducing FW-assisted scheduling of command stream queues. This is a > > fundamental shift in both how userspace is supposed to submit jobs, but > > also how the driver is architectured. We initially tried to retrofit the > > CSF model into panfrost, but this ended up introducing unneeded > > complexity to the existing driver, which we all know is a potential > > source of regression. > > While I agree there's some big differences which effectively mandate > splitting the driver I do think there are some parts which make a lot of > sense to share. > > For example pancsf_regs.h and panfrost_regs.h are really quite similar > and I think could easily be combined. The clock/regulator code is pretty > much a direct copy/paste (just adding support for more clocks), etc. > > What would be ideal is factoring out 'generic' parts from panfrost and > then being able to use them from pancsf. > > I had a go at starting that: > > https://gitlab.arm.com/linux-arm/linux-sp/-/tree/pancsf-refactor > > (lightly tested for Panfrost, only build tested for pancsf). > > That saves around 200 lines overall and avoids needing to maintain two > lots of clock/regulator code. There's definite scope for sharing (most) > register definitions between the drivers and quite possibly some of the > MMU/memory code (although there's diminishing returns there). 200 lines saved in a 5kloc+ driver doesn't seem worth much, especially against the added testing combinatorics, TBH. The main reason I can see to unify is if we want VM_BIND (and related goodies) on JM hardware too. That's only really for Vulkan and I really don't see the case for Vulkan on anything older than Valhall at this point. So it comes down to whether we want to start Vulkan at v9 or skip to v10. The separate panfrost/pancsf drivers approach strongly favours the latter.