All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alyssa Rosenzweig <alyssa@collabora.com>
To: Steven Price <steven.price@arm.com>
Cc: Daniel Stone <daniels@collabora.com>,
	dri-devel@lists.freedesktop.org,
	Boris Brezillon <boris.brezillon@collabora.com>,
	Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Jason Ekstrand <jason@jlekstrand.net>
Subject: Re: [RFC PATCH] drm/pancsf: Add a new driver for Mali CSF-based GPUs
Date: Fri, 3 Feb 2023 11:29:16 -0500	[thread overview]
Message-ID: <Y902XDkZB6PvT47s@maud> (raw)
In-Reply-To: <bf9a7562-796b-d39e-ef4b-deb8217484b4@arm.com>

> > 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.

  reply	other threads:[~2023-02-03 16:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-01  8:48 [RFC PATCH] drm/pancsf: Add a new driver for Mali CSF-based GPUs Boris Brezillon
2023-02-01 14:57 ` kernel test robot
2023-02-01 18:23 ` kernel test robot
2023-02-03 15:41 ` Steven Price
2023-02-03 16:29   ` Alyssa Rosenzweig [this message]
2023-02-03 16:43     ` Steven Price
2023-02-03 17:29   ` Boris Brezillon
2023-02-03 17:58     ` Alyssa Rosenzweig
2023-02-06  9:37       ` Steven Price
2023-02-05 19:51 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y902XDkZB6PvT47s@maud \
    --to=alyssa@collabora.com \
    --cc=alyssa.rosenzweig@collabora.com \
    --cc=boris.brezillon@collabora.com \
    --cc=daniels@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jason@jlekstrand.net \
    --cc=robin.murphy@arm.com \
    --cc=steven.price@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.