Re: [PATCH v2 13/15] drm/panthor: Allow driver compilation

[Boris Brezillon <boris.brezillon@collabora.com>]

On Mon, 21 Aug 2023 18:56:21 +0100
Robin Murphy <robin.murphy@arm.com> wrote:

> > And, to be honest, for a fair bit of the common code in
> > panfrost/panthorm it's common to a few other drivers too. So the correct
> > answer might well be to try to add more generic helpers (devfreq,
> > clocks, power domains all spring to mind - there's a lot of boiler plate
> > and nothing very special about Mali).  
> 
> That much is true, however I guess there's also stuff like perf counter 
> support which is less likely to be DRM-level generic but perhaps still 
> sufficiently similar between JM and CSF. The main thing I don't know, 
> and thus feel compelled to poke at, is whether there's any possibility 
> that once the new UAPI is mature, it might eventually become preferable 
> to move Job Manager support over to some subset of that rather than 
> maintain two whole UAPIs in parallel (particularly at the Mesa end). My 
> (limited) understanding is that all the BO-wrangling and MMU code is 
> primarily different here for the sake of supporting new shiny UAPI 
> features, not because of anything inherent to CSF itself (other than CSF 
> being the thing which makes supporting said features feasible).

You nailed it. The fact we went for a new driver is not so much about
supporting CSF HW (though, supporting CSF with the panfrost model is
challenging to be honest, even more if we want a zero-regression
guarantee for pre-existing users), but more about starting from a green
field so we don't have to think about supporting both GL and Vulkan
models (explicit vs implicit VM maintenance, explicit vs implicit
synchronization everywhere, and probably other things I forgot about).
Those are things that are hard to reconcile, which makes the code even
more complicated to apprehend, and more likely to break in subtle ways.

Intel went for this 'new driver' approach with Xe, Nouveau didn't. I
can't guarantee we took the right decision, but it definitely makes the
bringup phase less painful/risky, since we don't have to make sure we
don't regress existing users, and we don't have to implement
wrappers/bridges for the old uAPI.

As for supporting JM with the new driver, that's something we are
considering, especially if we want proper Vulkan support on
bifrost/valhall-non-csf at some point, but that's clearly not the
priority right now.