On Tue, May 19, 2020 at 07:41:20PM +0200, Greg Kroah-Hartman wrote:
On Tue, May 19, 2020 at 08:57:38AM -0600, Jeffrey Hugo wrote:
On 5/18/2020 11:08 PM, Dave Airlie wrote:
On Fri, 15 May 2020 at 00:12, Jeffrey Hugo jhugo@codeaurora.org wrote:
Introduction: Qualcomm Cloud AI 100 is a PCIe adapter card which contains a dedicated SoC ASIC for the purpose of efficently running Deep Learning inference workloads in a data center environment.
The offical press release can be found at - https://www.qualcomm.com/news/releases/2019/04/09/qualcomm-brings-power-effi...
The offical product website is - https://www.qualcomm.com/products/datacenter-artificial-intelligence
At the time of the offical press release, numerious technology news sites also covered the product. Doing a search of your favorite site is likely to find their coverage of it.
It is our goal to have the kernel driver for the product fully upstream. The purpose of this RFC is to start that process. We are still doing development (see below), and thus not quite looking to gain acceptance quite yet, but now that we have a working driver we beleive we are at the stage where meaningful conversation with the community can occur.
Hi Jeffery,
Just wondering what the userspace/testing plans for this driver.
This introduces a new user facing API for a device without pointers to users or tests for that API.
We have daily internal testing, although I don't expect you to take my word for that.
I would like to get one of these devices into the hands of Linaro, so that it can be put into KernelCI. Similar to other Qualcomm products. I'm trying to convince the powers that be to make this happen.
Regarding what the community could do on its own, everything but the Linux driver is considered proprietary - that includes the on device firmware and the entire userspace stack. This is a decision above my pay grade.
Ok, that's a decision you are going to have to push upward on, as we really can't take this without a working, open, userspace.
Uh wut.
So the merge criteria for drivers/accel (atm still drivers/misc but I thought that was interim until more drivers showed up) isn't actually "totally-not-a-gpu accel driver without open source userspace".
Instead it's "totally-not-a-gpu accel driver without open source userspace" _and_ you have to be best buddies with Greg. Or at least not be on the naughty company list. Since for habanalabs all you wanted is a few test cases to exercise the ioctls. Not the entire userspace.
The most bonkers part here is that drivers/gpu actually does have a bunch of active contributors from codeaurora ...
Especially given the copyright owner of this code, that would be just crazy and foolish to not have open userspace code as well. Firmware would also be wonderful as well, go poke your lawyers about derivative work issues and the like for fun conversations :)
So without that changed, I'm not going to take this, and push to object that anyone else take this.
I'm not going to be able to review any of this code anymore until that changes, sorry.
So you couldn't review the habanalabs driver either?
Get some consistency into your decision making as maintainer. And don't tell me or anyone else that this is complicated, gpu and rdma driver folks very much told you and Olof last year that this is what you're getting yourself into.
Cheers, Daniel
PS: I guess congrats for figuring out you can't write a totally-not-a-gpu accel driver without making kernel and userspace parts derivatives works of each another. We told you that last year. -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
Get some consistency into your decision making as maintainer. And don't tell me or anyone else that this is complicated, gpu and rdma driver folks very much told you and Olof last year that this is what you're getting yourself into.
It is complicated!
One of the big mistakes we learned from in RDMA is that we must have a cannonical open userspace, that is at least the user side of the uABI from the kernel. It doesn't have to do a lot but it does have to be there and everyone must use it.
Some time ago it was all a fragmented mess where every HW had its own library project with no community and that spilled into the kernel where it became impossible to be sure everyone was playing nicely and keeping their parts up to date. We are still digging out where I find stuff in the kernel that just never seemed to make it into any userspace..
I feel this is an essential ingredient, and I think I gave this advice at LPC as well - it is important to start as a proper subsystem with a proper standard user space. IMHO a random collection of opaque misc drivers for incredibly complex HW is not going to magically gel into a subsystem.
Given the state of the industry the userspace doesn't have to do alot, and maybe that library exposes unique APIs for each HW, but it is at least a rallying point to handle all these questions like: 'is the proposed userspace enough?', give some consistency, and be ready to add in those things that are common (like, say IOMMU PASID setup)
The uacce stuff is sort of interesting here as it does seem to take some of that approach, it is really simplistic, but the basic idea of creating a generic DMA work ring is in there, and probably applies just as well to several of these 'totally-not-a-GPU' drivers.
The other key is that the uABI from the kernel does need to be very flexible as really any new HW can appear with any new strange need all the time, and there will not be detailed commonality between HWs. RDMA has made this mistake a lot in the past too.
The newer RDMA netlink like API is actually turning out not bad for this purpose.. (again something a subsystem could provide)
Also the approach in this driver to directly connect the device to userspace for control commands has worked for RDMA in the past few years.
Jason
On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
Ok, that's a decision you are going to have to push upward on, as we really can't take this without a working, open, userspace.
Uh wut.
So the merge criteria for drivers/accel (atm still drivers/misc but I thought that was interim until more drivers showed up) isn't actually "totally-not-a-gpu accel driver without open source userspace".
Instead it's "totally-not-a-gpu accel driver without open source userspace" _and_ you have to be best buddies with Greg. Or at least not be on the naughty company list. Since for habanalabs all you wanted is a few test cases to exercise the ioctls. Not the entire userspace.
Habanalabs now has their full library opensourced that their tools use directly, so that's not an argument anymore.
My primary point here is the copyright owner of this code, because of that, I'm not going to objet to allowing this to be merged without open userspace code.
thanks,
greg k-h
On Tue 19 May 21:59 PDT 2020, Greg Kroah-Hartman wrote:
On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
Ok, that's a decision you are going to have to push upward on, as we really can't take this without a working, open, userspace.
Uh wut.
So the merge criteria for drivers/accel (atm still drivers/misc but I thought that was interim until more drivers showed up) isn't actually "totally-not-a-gpu accel driver without open source userspace".
Instead it's "totally-not-a-gpu accel driver without open source userspace" _and_ you have to be best buddies with Greg. Or at least not be on the naughty company list. Since for habanalabs all you wanted is a few test cases to exercise the ioctls. Not the entire userspace.
Habanalabs now has their full library opensourced that their tools use directly, so that's not an argument anymore.
My primary point here is the copyright owner of this code, because of that, I'm not going to objet to allowing this to be merged without open userspace code.
So because it's copyright Linux Foundation you are going to accept it without user space, after all?
Regards, Bjorn
On Tue, May 19, 2020 at 10:11:35PM -0700, Bjorn Andersson wrote:
On Tue 19 May 21:59 PDT 2020, Greg Kroah-Hartman wrote:
On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
Ok, that's a decision you are going to have to push upward on, as we really can't take this without a working, open, userspace.
Uh wut.
So the merge criteria for drivers/accel (atm still drivers/misc but I thought that was interim until more drivers showed up) isn't actually "totally-not-a-gpu accel driver without open source userspace".
Instead it's "totally-not-a-gpu accel driver without open source userspace" _and_ you have to be best buddies with Greg. Or at least not be on the naughty company list. Since for habanalabs all you wanted is a few test cases to exercise the ioctls. Not the entire userspace.
Habanalabs now has their full library opensourced that their tools use directly, so that's not an argument anymore.
My primary point here is the copyright owner of this code, because of that, I'm not going to objet to allowing this to be merged without open userspace code.
So because it's copyright Linux Foundation you are going to accept it without user space, after all?
Huh, no, the exact opposite, sorry, drop the "not" in that above sentence. My bad.
greg k-h
On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
On Tue, May 19, 2020 at 07:41:20PM +0200, Greg Kroah-Hartman wrote:
On Tue, May 19, 2020 at 08:57:38AM -0600, Jeffrey Hugo wrote:
On 5/18/2020 11:08 PM, Dave Airlie wrote:
On Fri, 15 May 2020 at 00:12, Jeffrey Hugo jhugo@codeaurora.org wrote:
Introduction: Qualcomm Cloud AI 100 is a PCIe adapter card which contains a dedicated SoC ASIC for the purpose of efficently running Deep Learning inference workloads in a data center environment.
The offical press release can be found at - https://www.qualcomm.com/news/releases/2019/04/09/qualcomm-brings-power-effi...
The offical product website is - https://www.qualcomm.com/products/datacenter-artificial-intelligence
At the time of the offical press release, numerious technology news sites also covered the product. Doing a search of your favorite site is likely to find their coverage of it.
It is our goal to have the kernel driver for the product fully upstream. The purpose of this RFC is to start that process. We are still doing development (see below), and thus not quite looking to gain acceptance quite yet, but now that we have a working driver we beleive we are at the stage where meaningful conversation with the community can occur.
Hi Jeffery,
Just wondering what the userspace/testing plans for this driver.
This introduces a new user facing API for a device without pointers to users or tests for that API.
We have daily internal testing, although I don't expect you to take my word for that.
I would like to get one of these devices into the hands of Linaro, so that it can be put into KernelCI. Similar to other Qualcomm products. I'm trying to convince the powers that be to make this happen.
Regarding what the community could do on its own, everything but the Linux driver is considered proprietary - that includes the on device firmware and the entire userspace stack. This is a decision above my pay grade.
Ok, that's a decision you are going to have to push upward on, as we really can't take this without a working, open, userspace.
Uh wut.
So the merge criteria for drivers/accel (atm still drivers/misc but I thought that was interim until more drivers showed up) isn't actually "totally-not-a-gpu accel driver without open source userspace".
Instead it's "totally-not-a-gpu accel driver without open source userspace" _and_ you have to be best buddies with Greg. Or at least not be on the naughty company list. Since for habanalabs all you wanted is a few test cases to exercise the ioctls. Not the entire userspace.
Also, to be fair, I have changed my mind after seeing the mess of complexity that these "ioctls for everyone!" type of pass-through these kinds of drivers are creating. You were right, we need open userspace code in order to be able to properly evaluate and figure out what they are doing is right or not and be able to maintain things over time correctly.
So I was wrong, and you were right, my apologies for my previous stubbornness.
thanks,
greg k-h
On Wed, May 20, 2020 at 7:15 AM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
On Tue, May 19, 2020 at 07:41:20PM +0200, Greg Kroah-Hartman wrote:
On Tue, May 19, 2020 at 08:57:38AM -0600, Jeffrey Hugo wrote:
On 5/18/2020 11:08 PM, Dave Airlie wrote:
On Fri, 15 May 2020 at 00:12, Jeffrey Hugo jhugo@codeaurora.org wrote:
Introduction: Qualcomm Cloud AI 100 is a PCIe adapter card which contains a dedicated SoC ASIC for the purpose of efficently running Deep Learning inference workloads in a data center environment.
The offical press release can be found at - https://www.qualcomm.com/news/releases/2019/04/09/qualcomm-brings-power-effi...
The offical product website is - https://www.qualcomm.com/products/datacenter-artificial-intelligence
At the time of the offical press release, numerious technology news sites also covered the product. Doing a search of your favorite site is likely to find their coverage of it.
It is our goal to have the kernel driver for the product fully upstream. The purpose of this RFC is to start that process. We are still doing development (see below), and thus not quite looking to gain acceptance quite yet, but now that we have a working driver we beleive we are at the stage where meaningful conversation with the community can occur.
Hi Jeffery,
Just wondering what the userspace/testing plans for this driver.
This introduces a new user facing API for a device without pointers to users or tests for that API.
We have daily internal testing, although I don't expect you to take my word for that.
I would like to get one of these devices into the hands of Linaro, so that it can be put into KernelCI. Similar to other Qualcomm products. I'm trying to convince the powers that be to make this happen.
Regarding what the community could do on its own, everything but the Linux driver is considered proprietary - that includes the on device firmware and the entire userspace stack. This is a decision above my pay grade.
Ok, that's a decision you are going to have to push upward on, as we really can't take this without a working, open, userspace.
Uh wut.
So the merge criteria for drivers/accel (atm still drivers/misc but I thought that was interim until more drivers showed up) isn't actually "totally-not-a-gpu accel driver without open source userspace".
Instead it's "totally-not-a-gpu accel driver without open source userspace" _and_ you have to be best buddies with Greg. Or at least not be on the naughty company list. Since for habanalabs all you wanted is a few test cases to exercise the ioctls. Not the entire userspace.
Also, to be fair, I have changed my mind after seeing the mess of complexity that these "ioctls for everyone!" type of pass-through these kinds of drivers are creating. You were right, we need open userspace code in order to be able to properly evaluate and figure out what they are doing is right or not and be able to maintain things over time correctly.
So I was wrong, and you were right, my apologies for my previous stubbornness.
Awesome and don't worry, I'm pretty sure we've all been stubborn occasionally :-)
From a drivers/gpu pov I think still not quite there since we also
want to see the compiler for these programmable accelerator thingies. But just having a fairly good consensus that "userspace library with all the runtime stuff excluding compiler must be open" is a huge step forward. Next step may be that we (kernel overall, drivers/gpu will still ask for the full thing) have ISA docs for these programmable things, so that we can also evaluate that aspect and gauge how many security issues there might be. Plus have a fighting chance to fix up the security leaks when (post smeltdown I don't really want to consider this an if) someone finds a hole in the hw security wall. At least in drivers/gpu we historically have a ton of drivers with command checkers to validate what userspace wants to run on the accelerator thingie. Both in cases where the hw was accidentally too strict, and not strict enough.
Cheers, Daniel
On 5/20/2020 2:34 AM, Daniel Vetter wrote:
On Wed, May 20, 2020 at 7:15 AM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
On Tue, May 19, 2020 at 07:41:20PM +0200, Greg Kroah-Hartman wrote:
On Tue, May 19, 2020 at 08:57:38AM -0600, Jeffrey Hugo wrote:
On 5/18/2020 11:08 PM, Dave Airlie wrote:
On Fri, 15 May 2020 at 00:12, Jeffrey Hugo jhugo@codeaurora.org wrote: > > Introduction: > Qualcomm Cloud AI 100 is a PCIe adapter card which contains a dedicated > SoC ASIC for the purpose of efficently running Deep Learning inference > workloads in a data center environment. > > The offical press release can be found at - > https://www.qualcomm.com/news/releases/2019/04/09/qualcomm-brings-power-effi... > > The offical product website is - > https://www.qualcomm.com/products/datacenter-artificial-intelligence > > At the time of the offical press release, numerious technology news sites > also covered the product. Doing a search of your favorite site is likely > to find their coverage of it. > > It is our goal to have the kernel driver for the product fully upstream. > The purpose of this RFC is to start that process. We are still doing > development (see below), and thus not quite looking to gain acceptance quite > yet, but now that we have a working driver we beleive we are at the stage > where meaningful conversation with the community can occur.
Hi Jeffery,
Just wondering what the userspace/testing plans for this driver.
This introduces a new user facing API for a device without pointers to users or tests for that API.
We have daily internal testing, although I don't expect you to take my word for that.
I would like to get one of these devices into the hands of Linaro, so that it can be put into KernelCI. Similar to other Qualcomm products. I'm trying to convince the powers that be to make this happen.
Regarding what the community could do on its own, everything but the Linux driver is considered proprietary - that includes the on device firmware and the entire userspace stack. This is a decision above my pay grade.
Ok, that's a decision you are going to have to push upward on, as we really can't take this without a working, open, userspace.
Uh wut.
So the merge criteria for drivers/accel (atm still drivers/misc but I thought that was interim until more drivers showed up) isn't actually "totally-not-a-gpu accel driver without open source userspace".
Instead it's "totally-not-a-gpu accel driver without open source userspace" _and_ you have to be best buddies with Greg. Or at least not be on the naughty company list. Since for habanalabs all you wanted is a few test cases to exercise the ioctls. Not the entire userspace.
Also, to be fair, I have changed my mind after seeing the mess of complexity that these "ioctls for everyone!" type of pass-through these kinds of drivers are creating. You were right, we need open userspace code in order to be able to properly evaluate and figure out what they are doing is right or not and be able to maintain things over time correctly.
So I was wrong, and you were right, my apologies for my previous stubbornness.
Awesome and don't worry, I'm pretty sure we've all been stubborn occasionally :-)
From a drivers/gpu pov I think still not quite there since we also want to see the compiler for these programmable accelerator thingies. But just having a fairly good consensus that "userspace library with all the runtime stuff excluding compiler must be open" is a huge step forward. Next step may be that we (kernel overall, drivers/gpu will still ask for the full thing) have ISA docs for these programmable things, so that we can also evaluate that aspect and gauge how many security issues there might be. Plus have a fighting chance to fix up the security leaks when (post smeltdown I don't really want to consider this an if) someone finds a hole in the hw security wall. At least in drivers/gpu we historically have a ton of drivers with command checkers to validate what userspace wants to run on the accelerator thingie. Both in cases where the hw was accidentally too strict, and not strict enough.
I think this provides a pretty clear guidance on what you/the community are looking for, both now and possibly in the future.
Thank you.
From my perspective, it would be really nice if there was something like Mesa that was a/the standard for these sorts of accelerators. Its somewhat the wild west, and we've struggled with it.
I don't work on the compiler end of things, but based on what I've seen in my project, I think the vendors are going to be highly resistant to opening that up. There is more than just the raw instruction set that goes on in the device, and its viewed as "secret sauce" even though I agree with your previous statements on that viewpoint.
On Wed, May 20, 2020 at 08:48:13AM -0600, Jeffrey Hugo wrote:
On 5/20/2020 2:34 AM, Daniel Vetter wrote:
On Wed, May 20, 2020 at 7:15 AM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
On Tue, May 19, 2020 at 07:41:20PM +0200, Greg Kroah-Hartman wrote:
On Tue, May 19, 2020 at 08:57:38AM -0600, Jeffrey Hugo wrote:
On 5/18/2020 11:08 PM, Dave Airlie wrote: > On Fri, 15 May 2020 at 00:12, Jeffrey Hugo jhugo@codeaurora.org wrote: > > > > Introduction: > > Qualcomm Cloud AI 100 is a PCIe adapter card which contains a dedicated > > SoC ASIC for the purpose of efficently running Deep Learning inference > > workloads in a data center environment. > > > > The offical press release can be found at - > > https://www.qualcomm.com/news/releases/2019/04/09/qualcomm-brings-power-effi... > > > > The offical product website is - > > https://www.qualcomm.com/products/datacenter-artificial-intelligence > > > > At the time of the offical press release, numerious technology news sites > > also covered the product. Doing a search of your favorite site is likely > > to find their coverage of it. > > > > It is our goal to have the kernel driver for the product fully upstream. > > The purpose of this RFC is to start that process. We are still doing > > development (see below), and thus not quite looking to gain acceptance quite > > yet, but now that we have a working driver we beleive we are at the stage > > where meaningful conversation with the community can occur. > > > Hi Jeffery, > > Just wondering what the userspace/testing plans for this driver. > > This introduces a new user facing API for a device without pointers to > users or tests for that API.
We have daily internal testing, although I don't expect you to take my word for that.
I would like to get one of these devices into the hands of Linaro, so that it can be put into KernelCI. Similar to other Qualcomm products. I'm trying to convince the powers that be to make this happen.
Regarding what the community could do on its own, everything but the Linux driver is considered proprietary - that includes the on device firmware and the entire userspace stack. This is a decision above my pay grade.
Ok, that's a decision you are going to have to push upward on, as we really can't take this without a working, open, userspace.
Uh wut.
So the merge criteria for drivers/accel (atm still drivers/misc but I thought that was interim until more drivers showed up) isn't actually "totally-not-a-gpu accel driver without open source userspace".
Instead it's "totally-not-a-gpu accel driver without open source userspace" _and_ you have to be best buddies with Greg. Or at least not be on the naughty company list. Since for habanalabs all you wanted is a few test cases to exercise the ioctls. Not the entire userspace.
Also, to be fair, I have changed my mind after seeing the mess of complexity that these "ioctls for everyone!" type of pass-through these kinds of drivers are creating. You were right, we need open userspace code in order to be able to properly evaluate and figure out what they are doing is right or not and be able to maintain things over time correctly.
So I was wrong, and you were right, my apologies for my previous stubbornness.
Awesome and don't worry, I'm pretty sure we've all been stubborn occasionally :-)
From a drivers/gpu pov I think still not quite there since we also want to see the compiler for these programmable accelerator thingies. But just having a fairly good consensus that "userspace library with all the runtime stuff excluding compiler must be open" is a huge step forward. Next step may be that we (kernel overall, drivers/gpu will still ask for the full thing) have ISA docs for these programmable things, so that we can also evaluate that aspect and gauge how many security issues there might be. Plus have a fighting chance to fix up the security leaks when (post smeltdown I don't really want to consider this an if) someone finds a hole in the hw security wall. At least in drivers/gpu we historically have a ton of drivers with command checkers to validate what userspace wants to run on the accelerator thingie. Both in cases where the hw was accidentally too strict, and not strict enough.
I think this provides a pretty clear guidance on what you/the community are looking for, both now and possibly in the future.
Thank you.
From my perspective, it would be really nice if there was something like Mesa that was a/the standard for these sorts of accelerators. Its somewhat the wild west, and we've struggled with it.
Yeah there's currently 0 standard api for ML accelerators that aren't gpus. So not only don't we have mesa, we don't even have an api.
I do personally think that for anything that's somewhat programmable and not just fixed-function matrix multiply accelerator for neural networks, a slimmed down mesa vk or compute driver might be the most reasonable starting point for an open source ecosystem for these things. Still a ton of work, and if you're unlucky you might have bet on the wrong standard to adapt for ML needs, atm no one can predict whether it's going to be vk, or opencl or maybe something else entirely that will serve as the low-level driver fabric underneath stuff like tenserflow and other ML libraries.
I don't work on the compiler end of things, but based on what I've seen in my project, I think the vendors are going to be highly resistant to opening that up. There is more than just the raw instruction set that goes on in the device, and its viewed as "secret sauce" even though I agree with your previous statements on that viewpoint.
Well it's the same with gpus. Sometimes you can get companies to open up their runtimes. Almost never their compiler. A big problem seems to be licensing troubles that prevent them from opening up the compiler - it's often much cheaper and easier to just write a new open compiler than trying to get the legal review for the existing one done. I don't think there's a single case where a company succeeded in opening a gpu/accel compiler that didn't start out with at least open source as an eventual goal. -Daniel
On Wed, May 20, 2020 at 08:48:13AM -0600, Jeffrey Hugo wrote:
On 5/20/2020 2:34 AM, Daniel Vetter wrote:
On Wed, May 20, 2020 at 7:15 AM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
On Tue, May 19, 2020 at 07:41:20PM +0200, Greg Kroah-Hartman wrote:
On Tue, May 19, 2020 at 08:57:38AM -0600, Jeffrey Hugo wrote:
On 5/18/2020 11:08 PM, Dave Airlie wrote: > On Fri, 15 May 2020 at 00:12, Jeffrey Hugo jhugo@codeaurora.org wrote: > > > > Introduction: > > Qualcomm Cloud AI 100 is a PCIe adapter card which contains a dedicated > > SoC ASIC for the purpose of efficently running Deep Learning inference > > workloads in a data center environment. > > > > The offical press release can be found at - > > https://www.qualcomm.com/news/releases/2019/04/09/qualcomm-brings-power-effi... > > > > The offical product website is - > > https://www.qualcomm.com/products/datacenter-artificial-intelligence > > > > At the time of the offical press release, numerious technology news sites > > also covered the product. Doing a search of your favorite site is likely > > to find their coverage of it. > > > > It is our goal to have the kernel driver for the product fully upstream. > > The purpose of this RFC is to start that process. We are still doing > > development (see below), and thus not quite looking to gain acceptance quite > > yet, but now that we have a working driver we beleive we are at the stage > > where meaningful conversation with the community can occur. > > > Hi Jeffery, > > Just wondering what the userspace/testing plans for this driver. > > This introduces a new user facing API for a device without pointers to > users or tests for that API.
We have daily internal testing, although I don't expect you to take my word for that.
I would like to get one of these devices into the hands of Linaro, so that it can be put into KernelCI. Similar to other Qualcomm products. I'm trying to convince the powers that be to make this happen.
Regarding what the community could do on its own, everything but the Linux driver is considered proprietary - that includes the on device firmware and the entire userspace stack. This is a decision above my pay grade.
Ok, that's a decision you are going to have to push upward on, as we really can't take this without a working, open, userspace.
Uh wut.
So the merge criteria for drivers/accel (atm still drivers/misc but I thought that was interim until more drivers showed up) isn't actually "totally-not-a-gpu accel driver without open source userspace".
Instead it's "totally-not-a-gpu accel driver without open source userspace" _and_ you have to be best buddies with Greg. Or at least not be on the naughty company list. Since for habanalabs all you wanted is a few test cases to exercise the ioctls. Not the entire userspace.
Also, to be fair, I have changed my mind after seeing the mess of complexity that these "ioctls for everyone!" type of pass-through these kinds of drivers are creating. You were right, we need open userspace code in order to be able to properly evaluate and figure out what they are doing is right or not and be able to maintain things over time correctly.
So I was wrong, and you were right, my apologies for my previous stubbornness.
Awesome and don't worry, I'm pretty sure we've all been stubborn occasionally :-)
From a drivers/gpu pov I think still not quite there since we also want to see the compiler for these programmable accelerator thingies. But just having a fairly good consensus that "userspace library with all the runtime stuff excluding compiler must be open" is a huge step forward. Next step may be that we (kernel overall, drivers/gpu will still ask for the full thing) have ISA docs for these programmable things, so that we can also evaluate that aspect and gauge how many security issues there might be. Plus have a fighting chance to fix up the security leaks when (post smeltdown I don't really want to consider this an if) someone finds a hole in the hw security wall. At least in drivers/gpu we historically have a ton of drivers with command checkers to validate what userspace wants to run on the accelerator thingie. Both in cases where the hw was accidentally too strict, and not strict enough.
I think this provides a pretty clear guidance on what you/the community are looking for, both now and possibly in the future.
Thank you.
From my perspective, it would be really nice if there was something like Mesa that was a/the standard for these sorts of accelerators. Its somewhat the wild west, and we've struggled with it.
Put a first cut at such a thing out there and see how it goes! Nothing is preventing you from starting such a project, and it would be most welcome as you have seen.
good luck,
greg k-h
On 5/20/2020 9:59 AM, Greg Kroah-Hartman wrote:
On Wed, May 20, 2020 at 08:48:13AM -0600, Jeffrey Hugo wrote:
On 5/20/2020 2:34 AM, Daniel Vetter wrote:
On Wed, May 20, 2020 at 7:15 AM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
On Tue, May 19, 2020 at 07:41:20PM +0200, Greg Kroah-Hartman wrote:
On Tue, May 19, 2020 at 08:57:38AM -0600, Jeffrey Hugo wrote: > On 5/18/2020 11:08 PM, Dave Airlie wrote: >> On Fri, 15 May 2020 at 00:12, Jeffrey Hugo jhugo@codeaurora.org wrote: >>> >>> Introduction: >>> Qualcomm Cloud AI 100 is a PCIe adapter card which contains a dedicated >>> SoC ASIC for the purpose of efficently running Deep Learning inference >>> workloads in a data center environment. >>> >>> The offical press release can be found at - >>> https://www.qualcomm.com/news/releases/2019/04/09/qualcomm-brings-power-effi... >>> >>> The offical product website is - >>> https://www.qualcomm.com/products/datacenter-artificial-intelligence >>> >>> At the time of the offical press release, numerious technology news sites >>> also covered the product. Doing a search of your favorite site is likely >>> to find their coverage of it. >>> >>> It is our goal to have the kernel driver for the product fully upstream. >>> The purpose of this RFC is to start that process. We are still doing >>> development (see below), and thus not quite looking to gain acceptance quite >>> yet, but now that we have a working driver we beleive we are at the stage >>> where meaningful conversation with the community can occur. >> >> >> Hi Jeffery, >> >> Just wondering what the userspace/testing plans for this driver. >> >> This introduces a new user facing API for a device without pointers to >> users or tests for that API. > > We have daily internal testing, although I don't expect you to take my word > for that. > > I would like to get one of these devices into the hands of Linaro, so that > it can be put into KernelCI. Similar to other Qualcomm products. I'm trying > to convince the powers that be to make this happen. > > Regarding what the community could do on its own, everything but the Linux > driver is considered proprietary - that includes the on device firmware and > the entire userspace stack. This is a decision above my pay grade.
Ok, that's a decision you are going to have to push upward on, as we really can't take this without a working, open, userspace.
Uh wut.
So the merge criteria for drivers/accel (atm still drivers/misc but I thought that was interim until more drivers showed up) isn't actually "totally-not-a-gpu accel driver without open source userspace".
Instead it's "totally-not-a-gpu accel driver without open source userspace" _and_ you have to be best buddies with Greg. Or at least not be on the naughty company list. Since for habanalabs all you wanted is a few test cases to exercise the ioctls. Not the entire userspace.
Also, to be fair, I have changed my mind after seeing the mess of complexity that these "ioctls for everyone!" type of pass-through these kinds of drivers are creating. You were right, we need open userspace code in order to be able to properly evaluate and figure out what they are doing is right or not and be able to maintain things over time correctly.
So I was wrong, and you were right, my apologies for my previous stubbornness.
Awesome and don't worry, I'm pretty sure we've all been stubborn occasionally :-)
From a drivers/gpu pov I think still not quite there since we also want to see the compiler for these programmable accelerator thingies. But just having a fairly good consensus that "userspace library with all the runtime stuff excluding compiler must be open" is a huge step forward. Next step may be that we (kernel overall, drivers/gpu will still ask for the full thing) have ISA docs for these programmable things, so that we can also evaluate that aspect and gauge how many security issues there might be. Plus have a fighting chance to fix up the security leaks when (post smeltdown I don't really want to consider this an if) someone finds a hole in the hw security wall. At least in drivers/gpu we historically have a ton of drivers with command checkers to validate what userspace wants to run on the accelerator thingie. Both in cases where the hw was accidentally too strict, and not strict enough.
I think this provides a pretty clear guidance on what you/the community are looking for, both now and possibly in the future.
Thank you.
From my perspective, it would be really nice if there was something like Mesa that was a/the standard for these sorts of accelerators. Its somewhat the wild west, and we've struggled with it.
Put a first cut at such a thing out there and see how it goes! Nothing is preventing you from starting such a project, and it would be most welcome as you have seen.
I wish. I'll float the idea, but don't hold your breath.
dri-devel@lists.freedesktop.org
-
Bjorn Andersson -
Daniel Vetter -
Greg Kroah-Hartman -
Jason Gunthorpe -
Jeffrey Hugo