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]

Date: Fri, 28 Jun 2024 11:43:23 +0200
From: Tomeu Vizoso <tomeu@...euvizoso.net>
To: Daniel Stone <daniel@...ishbar.org>
Cc: Lucas Stach <l.stach@...gutronix.de>, linux-kernel@...r.kernel.org, 
	Oded Gabbay <ogabbay@...nel.org>, 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, 
	Daniel Stone <daniels@...labora.com>, Daniel Vetter <daniel@...ll.ch>
Subject: Re: [PATCH] drm/etnaviv: Create an accel device node if compute-only

On Wed, Jun 26, 2024 at 9:26 PM Daniel Stone <daniel@...ishbar.org> wrote:
>
> On Wed, 26 Jun 2024 at 18:52, Daniel Vetter <daniel@...ll.ch> wrote:
> > On Wed, Jun 26, 2024 at 11:39:01AM +0100, Daniel Stone wrote:
> > > On Wed, 26 Jun 2024 at 09:28, Lucas Stach <l.stach@...gutronix.de> wrote:
> > > > So we are kind of stuck here between breaking one or the other use-
> > > > case. I'm leaning heavily into the direction of just fixing Mesa, so we
> > > > can specify the type of screen we need at creation time to avoid the
> > > > renderonly issue, porting this change as far back as reasonably
> > > > possible and file old userspace into shit-happens.
> > >
> > > Yeah, honestly this sounds like the best solution to me too.
> >
> > Yeah mesa sounds kinda broken here ...
> >
> > What might work in the kernel is if you publish a fake 3d engine that's
> > too new for broken mesa, if that's enough to make it fail to bind? And if
> > mesa still happily binds against that, then yeah it's probably too broken
> > and we need etnaviv-v2 (as a drm driver uapi name, I think that's what
> > mesa filters?) for anything new (including the NN-only ones).
> >
> > I would still try to avoid that, but just in case someone screams about
> > regressions.

Thanks everybody for chiming in.

> It's not just etnaviv, it's literally every Mesa driver which works
> with decoupled render/display. So that would be etnaviv-v2,
> panfrost-v2, panthor-v2, v3d-v2, powervr-v2, ... albeit those don't
> tend to have multiple instances.

TBH, I think VeriSilicon is the only IP vendor that has recycled a
render-only IP into a compute-only IP.

That is why I liked the approach of conditionally creating an accel
node, as it neatly reflects that reality.

> Anyway, I'm still leaning towards the answer being: this is not an
> etnaviv regression caused by NPU, it's a longstanding generic Mesa
> issue for which the answer is to fix the known fragility.

My understanding of the consensus so far is that Mesa should be fixed
so that Gallium drivers can fail at screen init if the device doesn't
support some new usage flags that we would be adding.

If for some reason that doesn't work, we would be looking at having
etnaviv use a different kind of driver name, such as etnaviv-npu or
etnaviv-compute.

Did I get it right?

Thanks,

Tomeu