From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: Christoph Hellwig <hch@lst.de>, Oded Gabbay <ogabbay@kernel.org>,
linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org,
sumit.semwal@linaro.org, christian.koenig@amd.com,
galpress@amazon.com, sleybo@amazon.com,
dri-devel@lists.freedesktop.org, jgg@ziepe.ca,
linux-rdma@vger.kernel.org, linux-media@vger.kernel.org,
dledford@redhat.com, airlied@gmail.com,
alexander.deucher@amd.com, leonro@nvidia.com,
amd-gfx@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org
Subject: Re: [Linaro-mm-sig] [PATCH v4 0/2] Add p2p via dmabuf to habanalabs
Date: Wed, 7 Jul 2021 14:17:11 +0200 [thread overview]
Message-ID: <9af554b1-e4d8-4dd4-5a6a-830f3112941d@gmail.com> (raw)
In-Reply-To: <YORLTmyoXDtoM9Ta@phenom.ffwll.local>
Am 06.07.21 um 14:23 schrieb Daniel Vetter:
> On Tue, Jul 06, 2021 at 02:21:10PM +0200, Christoph Hellwig wrote:
>> On Tue, Jul 06, 2021 at 10:40:37AM +0200, Daniel Vetter wrote:
>>>> Greg, I hope this will be good enough for you to merge this code.
>>> So we're officially going to use dri-devel for technical details review
>>> and then Greg for merging so we don't have to deal with other merge
>>> criteria dri-devel folks have?
>>>
>>> I don't expect anything less by now, but it does make the original claim
>>> that drivers/misc will not step all over accelerators folks a complete
>>> farce under the totally-not-a-gpu banner.
>>>
>>> This essentially means that for any other accelerator stack that doesn't
>>> fit the dri-devel merge criteria, even if it's acting like a gpu and uses
>>> other gpu driver stuff, you can just send it to Greg and it's good to go.
>>>
>>> There's quite a lot of these floating around actually (and many do have
>>> semi-open runtimes, like habanalabs have now too, just not open enough to
>>> be actually useful). It's going to be absolutely lovely having to explain
>>> to these companies in background chats why habanalabs gets away with their
>>> stack and they don't.
>> FYI, I fully agree with Daniel here. Habanlabs needs to open up their
>> runtime if they want to push any additional feature in the kernel.
>> The current situation is not sustainable.
> Before anyone replies: The runtime is open, the compiler is still closed.
> This has become the new default for accel driver submissions, I think
> mostly because all the interesting bits for non-3d accelerators are in the
> accel ISA, and no longer in the runtime. So vendors are fairly happy to
> throw in the runtime as a freebie.
Well a compiler and runtime makes things easier, but the real question
is if they are really required for upstreaming a kernel driver?
I mean what we need is to be able to exercise the functionality. So
wouldn't (for example) an assembler be sufficient?
> It's still incomplete, and it's still useless if you want to actually hack
> on the driver stack.
Yeah, when you want to hack on it in the sense of extending it then this
requirement is certainly true.
But as far as I can see userspace don't need to be extendable to justify
a kernel driver. It just needs to have enough glue to thoughtfully
exercise the relevant kernel interfaces.
Applying that to GPUs I think what you need to be able to is to write
shaders, but that doesn't need to be in a higher language requiring a
compiler and runtime. Released opcodes and a low level assembler should
be sufficient.
Regards,
Christian.
> -Daniel
next prev parent reply other threads:[~2021-07-07 12:17 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-05 13:03 [PATCH v4 0/2] Add p2p via dmabuf to habanalabs Oded Gabbay
2021-07-05 13:03 ` [PATCH v4 1/2] habanalabs: define uAPI to export FD for DMA-BUF Oded Gabbay
2021-07-05 13:03 ` [PATCH v4 2/2] habanalabs: add support for dma-buf exporter Oded Gabbay
2021-07-05 16:52 ` Jason Gunthorpe
2021-07-06 9:44 ` Oded Gabbay
2021-07-06 13:54 ` Jason Gunthorpe
2021-07-06 14:00 ` Oded Gabbay
2021-07-06 8:40 ` [PATCH v4 0/2] Add p2p via dmabuf to habanalabs Daniel Vetter
2021-07-06 10:03 ` Oded Gabbay
2021-07-06 10:36 ` Daniel Vetter
2021-07-06 10:47 ` Daniel Vetter
2021-07-06 12:07 ` Daniel Vetter
2021-07-06 13:44 ` Jason Gunthorpe
2021-07-06 14:09 ` Daniel Vetter
2021-07-06 14:56 ` Jason Gunthorpe
2021-07-06 15:52 ` Daniel Vetter
2021-07-06 14:23 ` Jason Gunthorpe
2021-07-06 14:39 ` Daniel Vetter
2021-07-06 15:25 ` Jason Gunthorpe
2021-07-06 15:49 ` Daniel Vetter
2021-07-06 16:07 ` Daniel Vetter
2021-07-06 17:28 ` Jason Gunthorpe
[not found] ` <20210706173137.GA7840@lst.de>
2021-07-06 17:59 ` Jason Gunthorpe
2021-07-09 14:47 ` Dennis Dalessandro
2021-07-06 16:29 ` Jason Gunthorpe
2021-07-06 17:35 ` Daniel Vetter
2021-07-06 18:03 ` Daniel Vetter
2021-07-06 18:31 ` Jason Gunthorpe
2021-07-06 19:06 ` Daniel Vetter
2021-07-06 19:09 ` Alex Deucher
[not found] ` <20210706122110.GA18273@lst.de>
2021-07-06 12:23 ` [Linaro-mm-sig] " Daniel Vetter
2021-07-06 12:45 ` Oded Gabbay
2021-07-06 13:17 ` Daniel Vetter
2021-07-06 13:45 ` Oded Gabbay
2021-07-07 12:17 ` Christian König [this message]
2021-07-07 12:54 ` Daniel Vetter
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=9af554b1-e4d8-4dd4-5a6a-830f3112941d@gmail.com \
--to=ckoenig.leichtzumerken@gmail.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dledford@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=galpress@amazon.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=jgg@ziepe.ca \
--cc=leonro@nvidia.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=ogabbay@kernel.org \
--cc=sleybo@amazon.com \
--cc=sumit.semwal@linaro.org \
/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;
as well as URLs for NNTP newsgroup(s).