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