From: Jeffrey Hugo <email@example.com>
To: Tvrtko Ursulin <firstname.lastname@example.org>,
Dave Airlie <email@example.com>,
Oded Gabbay <firstname.lastname@example.org>,
Cc: Greg Kroah-Hartman <email@example.com>,
Yuji Ishikawa <firstname.lastname@example.org>,
"Linux-Kernel@Vger. Kernel. Org" <email@example.com>,
Arnd Bergmann <firstname.lastname@example.org>, Jiho Chu <email@example.com>
Subject: Re: New subsystem for acceleration devices
Date: Thu, 4 Aug 2022 09:03:57 -0600 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 8/4/2022 6:00 AM, Tvrtko Ursulin wrote:
> On 04/08/2022 00:54, Dave Airlie wrote:
>> On Thu, 4 Aug 2022 at 06:21, Oded Gabbay <email@example.com> wrote:
>>> On Wed, Aug 3, 2022 at 10:04 PM Dave Airlie <firstname.lastname@example.org> wrote:
>>>> On Sun, 31 Jul 2022 at 22:04, Oded Gabbay <email@example.com>
>>>>> Greg and I talked a couple of months ago about preparing a new accel
>>>>> subsystem for compute/acceleration devices that are not GPUs and I
>>>>> think your drivers that you are now trying to upstream fit it as well.
>>>> We've had some submissions for not-GPUs to the drm subsystem recently.
>>>> Intel GNA, Intel VPU, NVDLA, rpmsg AI processor unit.
>>>> why is creating a new subsystem at this time necessary?
>>>> Are we just creating a subsystem to avoid the open source userspace
>>>> consumer rules? Or do we have some concrete reasoning behind it?
>>> Hi Dave.
>>> 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
>>> Add to that the fact I talked with Greg a couple of months ago about
>>> doing a subsystem for any compute accelerators, which he was positive
>>> about, I thought it is a good opportunity to finally do it.
>>> I also honestly think that I can contribute much to these drivers from
>>> my experience with the habana driver (which is now deployed in mass at
>>> AWS) and contribute code from the habana driver to a common framework
>>> for AI drivers.
>> Why not port the habana driver to drm now instead? I don't get why it
>> wouldn't make sense?
>> Stepping up to create a new subsystem is great, but we need rules
>> around what belongs where, we can't just spawn new subsystems when we
>> have no clear guidelines on where drivers should land.
>> What are the rules for a new accel subsystem? Do we have to now
>> retarget the 3 drivers that are queued up to use drm for accelerators,
>> because 2 drivers don't?
> Isn't there three on the "don't prefer drm" side as well? Habana,
> Toshiba and Samsung? Just so the numbers argument is not misrepresented.
> Perhaps a poll like a) prefer DRM, b) prefer a new subsystem, c) don't
> care in principle; is in order?
I'll chime in with my opinions. Take them for what you will.
I would say I fall into the C category, but I'm targeting DRM and will
be the 5th(?) accel device to do so.
I'll say that the ksummit (from what I see in the LWN article) made me
very happy. Finally, the community had clear rules for accel drivers.
When I targeted misc in the past, it seemed like Greg moved the goal
post just for me, which stalled our attempt. It was even more
frustrating to see that the high bar Greg set for us was not applied to
other devices of the same "class" in following submissions.
However, the past is the past, and based on ksummit, we've spent a
number of months retargeting DRM. In a week (or two), I plan to post
something to start up the discussions again.
As far as the DRM userspace requirements, unless we've misunderstood
something, they've been easier to satisfy (pending review I suppose)
than what misc has set.
I would say that Dave Airlie's feedback on this discussion resonates
with me. From the perspective of a vendor wanting to be a part of the
community, clear rules are important and ksummit seemed to set that.
Oded's announcement has thrown all of that into the wind. Without a
proposal to evaluate (eg show me the code with clear guidelines), I
cannot seriously consider Oded's idea, and I'm not sure I want to sit by
another few years to see it settle out.
I expect to move forward with what we were planning prior to seeing this
thread which is targeting DRM. We'll see what the DRM folks say when
they have something to look at. If our device doesn't fit in DRM per an
assessment of the DRM folks, then I sure hope they can suggest where we
do fit because then we'll have tried misc and DRM, and not found a home.
Since "drivers/accel" doesn't exist, and realistically won't for a
long time if ever, I don't see why we should consider it.
Why DRM? We consume dma_buf and might look to p2pdma in the future.
ksummit appears clear - we are a DRM device. Also, someone could
probably run openCL on our device if they were so inclined to wire it
up. Over time, I've come to the thinking that we are a GPU, just
without display. Yes, it would have helped if DRM and/or drivers/gpu
were renamed, but I think I'm past that point. Once you have everything
written, it doesn't seem like it matters if the uAPI device is called
/dev/drmX, /dev/miscX, or /dev/magic.
I will not opine on other devices as I am no expert on them. Today, my
opinion is that DRM is the best place for me. We'll see where that goes.
> More to the point, code sharing is a very compelling argument if it can
> be demonstrated to be significant, aka not needing to reinvent the same
> Perhaps one route forward could be a) to consider is to rename DRM to
> something more appropriate, removing rendering from the name and
> replacing with accelerators, co-processors, I don't know... Although I
> am not sure renaming the codebase, character device node names and
> userspace headers is all that feasible. Thought to mention it
> nevertheless, maybe it gives an idea to someone how it could be done.
> And b) allow the userspace rules to be considered per driver, or per
> class (is it a gpu or not should be a question that can be answered).
> Shouldn't be a blocker if it still matches the rules present elsewhere
> in the kernel.
> Those two would remove the two most contentions points as far as I
> understood the thread.
next prev parent reply other threads:[~2022-08-04 15:04 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
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 [this message]
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).