On Mon, 21 Aug 2023 18:56:21 +0100 Robin Murphy <robin.mur...@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.
