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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZnxUn312E5c79jKh@phenom.ffwll.local>
Date: Wed, 26 Jun 2024 19:49:19 +0200
From: Daniel Vetter <daniel@...ll.ch>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Oded Gabbay <ogabbay@...nel.org>, Tomeu Vizoso <tomeu@...euvizoso.net>,
	Jeffrey Hugo <quic_jhugo@...cinc.com>, linux-kernel@...r.kernel.org,
	Lucas Stach <l.stach@...gutronix.de>,
	Russell King <linux+etnaviv@...linux.org.uk>,
	Christian Gmeiner <christian.gmeiner@...il.com>,
	David Airlie <airlied@...il.com>, etnaviv@...ts.freedesktop.org,
	dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH] drm/etnaviv: Create an accel device node if compute-only

On Wed, Jun 26, 2024 at 11:42:24AM +0300, Dmitry Baryshkov wrote:
> 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()

Eh I think less driver_features and more explicit (like
drm_mode_config_init() instead of also having to set DRIVER_MODESET) stuff
would be better in general. But they keep popping up, because it's an easy
hack to get things going. Over the years I've managed to remove a lot of
them tough.
-Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch