[PATCH] drm/etnaviv: Create an accel device node if compute-only

[Dmitry Baryshkov]

On Wed, Jun 26, 2024 at 09:26:40AM GMT, Daniel Vetter wrote:
> On Thu, May 09, 2024 at 05:41:18PM +0300, Oded Gabbay wrote:
> > On Thu, May 09, 2024 at 03:53:01PM +0200, Tomeu Vizoso wrote:
> > > Oded, Dave,
> > > 
> > > Do you have an opinion on this?
> > > 
> > > Thanks,
> > > 
> > > Tomeu
> > Hi Tomeu,
> > 
> > Sorry for not replying earlier, I was down with Covid (again...).
> > 
> > To your question, I don't have an objection to what you are
> > suggesting. My personal view of accel is that it is an integral part of 
> > DRM and therefore, if there is an *existing* drm driver that wants to 
> > create an accel node, I'm not against it. 
> 
> Yeah, there's a continum from "clearly 3d gpu" to "compute AI
> accelerator", with everything possible in-between shipping somewhere.
> Collaboration is the important part, hair-splitting on where exactly the
> driver should be is kinda secondary. I mean beyond "don't put a pure 3d
> driver into accel or vice versa" of course :-)
> 
> > There is the question of why you want to expose an accel node, and
> > here I would like to hear Dave's and Sima's opinion on your suggested
> > solution as it may affect the direction of other drm drivers.
> 
> So existing userspace that blindly assumes that any render node will give
> it useful 3d acceleration, then that's broken already.
> 
> - kernel with new driver support but old mesa without that driver already
>   gives you that, even for a pure 3d chip.
> 
> - intel (and I think also amd) have pure compute chips without 3d, so this
>   issue already exists
> 
> Same for the other directions, 3d gpus have variable amounts of compute
> chips nowadays.
> 
> That leaves imo just the pragmatic choice, and if we need to complicate
> the init flow of the kernel driver just for a different charnode major,
> then I don't really see the point.
> 
> And if we do see the point in this, I think the right approach would be if
> we split the init flow further into allocating the drm_device, and then in
> a 2nd step either allocate the accel or render uapi stuff as needed. The
> DRIVER_FOO flags just aren't super flexible for this kinda of stuff and
> have a bit a midlayer taste to them.

Being able to defer render allocation would be extremely useful for MSM
too as it's not currently possible to mask the driver_features during
drm_dev_init()

-- 
With best wishes
Dmitry