Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices

2022-10-26 Thread Oded Gabbay
On Mon, Oct 24, 2022 at 6:10 PM Alex Deucher wrote: > > On Mon, Oct 24, 2022 at 10:41 AM Oded Gabbay wrote: > > > > On Mon, Oct 24, 2022 at 4:55 PM Alex Deucher wrote: > > > > > > On Sat, Oct 22, 2022 at 5:46 PM Oded Gabbay wrote: > > > > > > > > In the last couple of months we had a

Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices

2022-10-25 Thread Alex Deucher
On Tue, Oct 25, 2022 at 10:34 AM Jason Gunthorpe wrote: > > On Tue, Oct 25, 2022 at 10:21:34AM -0400, Alex Deucher wrote: > > > E.g., the kfd node provides platform level compute > > topology information; e.g., the NUMA details for connected GPUs and > > CPUs, non-GPU compute node information,

Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices

2022-10-25 Thread Jason Gunthorpe
On Tue, Oct 25, 2022 at 10:21:34AM -0400, Alex Deucher wrote: > E.g., the kfd node provides platform level compute > topology information; e.g., the NUMA details for connected GPUs and > CPUs, non-GPU compute node information, cache level topologies, etc. See, this is exactly what I'm talking

Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices

2022-10-25 Thread Alex Deucher
On Tue, Oct 25, 2022 at 7:15 AM Jason Gunthorpe wrote: > > On Tue, Oct 25, 2022 at 12:27:11PM +1000, Dave Airlie wrote: > > > The userspace for those is normally bespoke like ROCm, which uses > > amdkfd, and amdkfd doesn't operate like most device files from what I > > know, so I'm not sure we'd

Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices

2022-10-25 Thread Jason Gunthorpe
On Tue, Oct 25, 2022 at 12:27:11PM +1000, Dave Airlie wrote: > The userspace for those is normally bespoke like ROCm, which uses > amdkfd, and amdkfd doesn't operate like most device files from what I > know, so I'm not sure we'd want it to operate as an accel device. I intensely dislike this

Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices

2022-10-24 Thread Dave Airlie
On Tue, 25 Oct 2022 at 12:21, John Hubbard wrote: > > On 10/24/22 05:43, Oded Gabbay wrote: > > Hi Oded, > > The patches make sense to me. I'm still just reading through and looking > for minor issues, but at a high level it seems to match what the LPC > discussions pointed to. > > >> What's your

Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices

2022-10-24 Thread John Hubbard
On 10/24/22 05:43, Oded Gabbay wrote: Hi Oded, The patches make sense to me. I'm still just reading through and looking for minor issues, but at a high level it seems to match what the LPC discussions pointed to. What's your opinion on the long-term prospect of DRM vs accel? I assume that

Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices

2022-10-24 Thread Alex Deucher
On Mon, Oct 24, 2022 at 10:41 AM Oded Gabbay wrote: > > On Mon, Oct 24, 2022 at 4:55 PM Alex Deucher wrote: > > > > On Sat, Oct 22, 2022 at 5:46 PM Oded Gabbay wrote: > > > > > > In the last couple of months we had a discussion [1] about creating a new > > > subsystem for compute accelerator

Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices

2022-10-24 Thread Oded Gabbay
On Mon, Oct 24, 2022 at 4:55 PM Alex Deucher wrote: > > On Sat, Oct 22, 2022 at 5:46 PM Oded Gabbay wrote: > > > > In the last couple of months we had a discussion [1] about creating a new > > subsystem for compute accelerator devices in the kernel. > > > > After an analysis that was done by DRM

Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices

2022-10-24 Thread Alex Deucher
On Sat, Oct 22, 2022 at 5:46 PM Oded Gabbay wrote: > > In the last couple of months we had a discussion [1] about creating a new > subsystem for compute accelerator devices in the kernel. > > After an analysis that was done by DRM maintainers and myself, and following > a BOF session at the Linux

Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices

2022-10-24 Thread Greg Kroah-Hartman
On Mon, Oct 24, 2022 at 01:55:56PM +0200, Thomas Zimmermann wrote: > Hi > > Am 22.10.22 um 23:46 schrieb Oded Gabbay: > > In the last couple of months we had a discussion [1] about creating a new > > subsystem for compute accelerator devices in the kernel. > > > > After an analysis that was done

Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices

2022-10-24 Thread Oded Gabbay
On Mon, Oct 24, 2022 at 2:56 PM Thomas Zimmermann wrote: > > Hi > > Am 22.10.22 um 23:46 schrieb Oded Gabbay: > > In the last couple of months we had a discussion [1] about creating a new > > subsystem for compute accelerator devices in the kernel. > > > > After an analysis that was done by DRM

Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices

2022-10-24 Thread Thomas Zimmermann
Hi Am 22.10.22 um 23:46 schrieb Oded Gabbay: In the last couple of months we had a discussion [1] about creating a new subsystem for compute accelerator devices in the kernel. After an analysis that was done by DRM maintainers and myself, and following a BOF session at the Linux Plumbers

Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices

2022-10-23 Thread Greg Kroah-Hartman
On Sun, Oct 23, 2022 at 09:02:49PM +0700, Bagas Sanjaya wrote: > On Sun, Oct 23, 2022 at 12:46:19AM +0300, Oded Gabbay wrote: > > In the last couple of months we had a discussion [1] about creating a new > > subsystem for compute accelerator devices in the kernel. > > > > After an analysis that

Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices

2022-10-23 Thread Bagas Sanjaya
On Sun, Oct 23, 2022 at 12:46:19AM +0300, Oded Gabbay wrote: > In the last couple of months we had a discussion [1] about creating a new > subsystem for compute accelerator devices in the kernel. > > After an analysis that was done by DRM maintainers and myself, and following > a BOF session at

[RFC PATCH 0/3] new subsystem for compute accelerator devices

2022-10-22 Thread Oded Gabbay
In the last couple of months we had a discussion [1] about creating a new subsystem for compute accelerator devices in the kernel. After an analysis that was done by DRM maintainers and myself, and following a BOF session at the Linux Plumbers conference a few weeks ago [2], we decided to create