From: Daniel Vetter <daniel@ffwll.ch>
To: Daniel Stone <daniel@fooishbar.org>
Cc: Lucas Stach <l.stach@pengutronix.de>,
Daniel Vetter <daniel@ffwll.ch>,
Tomeu Vizoso <tomeu@tomeuvizoso.net>,
linux-kernel@vger.kernel.org, Oded Gabbay <ogabbay@kernel.org>,
Russell King <linux+etnaviv@armlinux.org.uk>,
Christian Gmeiner <christian.gmeiner@gmail.com>,
David Airlie <airlied@gmail.com>,
etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Daniel Stone <daniels@collabora.com>
Subject: Re: [PATCH] drm/etnaviv: Create an accel device node if compute-only
Date: Wed, 26 Jun 2024 19:52:26 +0200 [thread overview]
Message-ID: <ZnxVWrFJKbVO8PZ0@phenom.ffwll.local> (raw)
In-Reply-To: <CAPj87rPB=N2vJ-5C7xXORYstK3=TpX+jZ7mCr7oxY2wpXeaTTQ@mail.gmail.com>
On Wed, Jun 26, 2024 at 11:39:01AM +0100, Daniel Stone wrote:
> Hi,
>
> On Wed, 26 Jun 2024 at 09:28, Lucas Stach <l.stach@pengutronix.de> wrote:
> > Mesa doesn't cope right now. Mostly because of the renderonly thing
> > where we magically need to match render devices to otherwise render
> > incapable KMS devices. The way this matching works is that the
> > renderonly code tries to open a screen on a rendernode and if that
> > succeeds we treat it as the matching render device.
> >
> > The core of the issue is that we have no way of specifying which kind
> > of screen we need at that point, i.e. if the screen should have 3D
> > render capabilities or if compute-only or even NN-accel-only would be
> > okay. So we can't fail screen creation if there is no 3D engine, as
> > this would break the teflon case, which needs a screen for the NN
> > accel, but once we successfully create a screen reanderonly might treat
> > the thing as a rendering device.
> > 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.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2024-06-26 17:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-24 6:37 Tomeu Vizoso
2024-04-25 11:32 ` Christian Gmeiner
2024-04-26 5:36 ` Tomeu Vizoso
2024-04-25 18:59 ` Jeffrey Hugo
2024-04-26 6:10 ` Tomeu Vizoso
2024-05-09 13:53 ` Tomeu Vizoso
2024-05-09 14:41 ` Oded Gabbay
2024-06-26 7:26 ` Daniel Vetter
2024-06-26 8:42 ` Dmitry Baryshkov
2024-06-26 17:49 ` Daniel Vetter
2024-05-10 8:34 ` Lucas Stach
2024-05-20 7:39 ` Tomeu Vizoso
2024-05-20 11:19 ` Daniel Stone
2024-06-12 14:26 ` Tomeu Vizoso
2024-06-17 17:01 ` Tomeu Vizoso
2024-06-26 7:28 ` Daniel Vetter
2024-06-26 8:28 ` Lucas Stach
2024-06-26 10:39 ` Daniel Stone
2024-06-26 17:52 ` Daniel Vetter [this message]
2024-06-26 19:26 ` Daniel Stone
2024-06-28 9:43 ` Tomeu Vizoso
2024-06-28 9:54 ` Daniel Stone
2024-06-28 17:47 ` Daniel Vetter
2024-05-20 9:24 ` Tomeu Vizoso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZnxVWrFJKbVO8PZ0@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@gmail.com \
--cc=christian.gmeiner@gmail.com \
--cc=daniel@fooishbar.org \
--cc=daniels@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=etnaviv@lists.freedesktop.org \
--cc=l.stach@pengutronix.de \
--cc=linux+etnaviv@armlinux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=ogabbay@kernel.org \
--cc=tomeu@tomeuvizoso.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®