From: Jiho Chu <email@example.com>
To: Oded Gabbay <firstname.lastname@example.org>
Cc: Daniel Stone <email@example.com>,
Dave Airlie <firstname.lastname@example.org>,
Greg Kroah-Hartman <email@example.com>,
Yuji Ishikawa <firstname.lastname@example.org>,
Arnd Bergmann <email@example.com>,
"Linux-Kernel@Vger. Kernel. Org" <firstname.lastname@example.org>
Subject: Re: New subsystem for acceleration devices
Date: Thu, 4 Aug 2022 18:27:40 +0900 [thread overview]
Message-ID: <email@example.com> (raw)
On Thu, 4 Aug 2022 09:46:49 +0300
Oded Gabbay <firstname.lastname@example.org> wrote:
> On Thu, Aug 4, 2022 at 2:32 AM Daniel Stone <email@example.com> wrote:
> > Hi Oded,
> > On Wed, 3 Aug 2022 at 21:21, Oded Gabbay <firstname.lastname@example.org> wrote:
> > > The reason it happened now is because I saw two drivers, which are
> > > doing h/w acceleration for AI, trying to be accepted to the misc
> > > subsystem.
> > Why misc?
> You will need to ask them ;)
> Seriously, I guess they thought they were not gpu drivers and didn't
> find anything else to go to.
> And at least for one of them, I remember Greg and Arnd pointing them to misc.
Samsung NPU driver is one of the trier to be a misc device. There is some
reasons that it chooses misc, but it can be simply said that GPU was not a
perfect suit for NPU.
AI workload is not limited in graphical job, it can be NLP, data analysis or
training job. The GPU/DRM can work for them, but its description is not for
e.g. AI workloads needs to manage ai model data as well as input data. I guess
it can be working with GEM object, and needs to be expaned for model information.
But I have a question that DRM accept this specialized GEM, thus it's not
related to Graphics.
Other subsystem was simliar, so I only could choose misc device.
IMHO, at the same reason, I'm positive on Oded's working, expecting that the
new subsystem could be more specialized for AI workload.
> > > Regarding the open source userspace rules in drm - yes, I think your
> > > rules are too limiting for the relatively young AI scene, and I saw at
> > > the 2021 kernel summit that other people from the kernel community
> > > think that as well.
> > > But that's not the main reason, or even a reason at all for doing
> > > this. After all, at least for habana, we open-sourced our compiler and
> > > a runtime library. And Greg also asked those two drivers if they have
> > > matching open-sourced user-space code.
> > >
> > > And a final reason is that I thought this can also help in somewhat
> > > reducing the workload on Greg. I saw in the last kernel summit there
> > > was a concern about bringing more people to be kernel maintainers so I
> > > thought this is a step in the right direction.
> > Can you please explain what the reason is here?
> > Everything you have described - uniform device enumeration, common job
> > description, memory management helpers, unique job submission format,
> > etc - applies exactly to DRM. If open userspace is not a requirement,
> > and bypassing Greg's manual merging is a requirement, then I don't see
> > what the difference is between DRM and this new bespoke subsystem. It
> > would be great to have these differences enumerated in email as well
> > as in kerneldoc.
> I don't think preparing such a list at this point is relevant, because
> I don't have a full-featured subsystem ready, which I can take and
> list all its features and compare it with drm.
> I have a beginning of a subsystem, with very minimal common code, and
> I planned for it to grow with time and with the relevant participants.
> And regarding the serspace issue, I believe it will be less stringent
> than in drm.
> For example, afaik in drm you must upstream your LLVM fork to the
> mainline LLVM tree. This is something that is really a heavy-lifting
> task for most, if not all, companies.
> So this is a requirement I think we can forgo.
> > Cheers,
> > Daniel
next prev parent reply other threads:[~2022-08-04 9:27 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20220731114605epcas1p1afff6b948f542e2062b60d49a8023f6f@epcas1p1.samsung.com>
2022-07-31 11:45 ` New subsystem for acceleration devices Oded Gabbay
2022-07-31 15:37 ` Greg Kroah-Hartman
2022-08-01 2:29 ` yuji2.ishikawa
2022-08-01 8:21 ` Oded Gabbay
2022-08-03 4:39 ` yuji2.ishikawa
2022-08-03 5:34 ` Greg KH
2022-08-03 20:28 ` Oded Gabbay
2022-08-02 17:25 ` Jiho Chu
2022-08-02 19:07 ` Oded Gabbay
2022-08-03 19:04 ` Dave Airlie
2022-08-03 20:20 ` Oded Gabbay
2022-08-03 23:31 ` Daniel Stone
2022-08-04 6:46 ` Oded Gabbay
2022-08-04 9:27 ` Jiho Chu [this message]
2022-08-03 23:54 ` Dave Airlie
2022-08-04 7:43 ` Oded Gabbay
2022-08-04 14:50 ` Jason Gunthorpe
2022-08-04 17:48 ` Oded Gabbay
2022-08-05 0:22 ` Jason Gunthorpe
2022-08-07 6:43 ` Oded Gabbay
2022-08-07 11:25 ` Oded Gabbay
2022-08-08 6:10 ` Greg Kroah-Hartman
2022-08-08 17:55 ` Jason Gunthorpe
2022-08-09 6:23 ` Greg Kroah-Hartman
2022-08-09 8:04 ` Christoph Hellwig
2022-08-09 8:32 ` Arnd Bergmann
2022-08-09 12:18 ` Jason Gunthorpe
2022-08-09 12:46 ` Arnd Bergmann
2022-08-09 14:22 ` Jason Gunthorpe
2022-08-09 8:45 ` Greg Kroah-Hartman
2022-08-08 17:46 ` Jason Gunthorpe
2022-08-08 20:26 ` Oded Gabbay
2022-08-09 12:43 ` Jason Gunthorpe
2022-08-05 3:02 ` Dave Airlie
2022-08-07 6:50 ` Oded Gabbay
2022-08-09 21:42 ` Oded Gabbay
2022-08-10 9:00 ` Jiho Chu
2022-08-10 14:05 ` yuji2.ishikawa
2022-08-10 14:37 ` Oded Gabbay
2022-08-23 18:23 ` Kevin Hilman
2022-08-23 20:45 ` Oded Gabbay
2022-08-29 20:54 ` Kevin Hilman
2022-09-23 16:21 ` Oded Gabbay
2022-09-26 8:16 ` Christoph Hellwig
2022-09-29 6:50 ` Oded Gabbay
2022-08-04 12:00 ` Tvrtko Ursulin
2022-08-04 15:03 ` Jeffrey Hugo
2022-08-04 17:53 ` Oded Gabbay
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).