AMDKFD kernel driver

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them are modifications to radeon driver and 18 of them include only amdkfd code. There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under drm/radeon/amdkfd. This move was done to emphasize the fact that this driver is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point is the radeon driver. Having said that, we will probably need to move it (maybe to be directly under drm) after we integrate with additional AMD gfx drivers.

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Written by Oded Gabbayh <[email protected]>

Original Cover Letter:

This patch set implements a Heterogeneous System Architecture (HSA) driver for radeon-family GPUs.
HSA allows different processor types (CPUs, DSPs, GPUs, etc..) to share system resources more effectively via HW features including shared pageable memory, userspace-accessible work queues, and platform-level atomics. In addition to the memory protection mechanisms in GPUVM and IOMMUv2, the Sea Islands family of GPUs also performs HW-level validation of commands passed in through the queues (aka rings).

The code in this patch set is intended to serve both as a sample driver for other HSA-compatible hardware devices and as a production driver for radeon-family processors. The code is architected to support multiple CPUs each with connected GPUs, although the current implementation focuses on a single Kaveri/Berlin APU, and works alongside the existing radeon kernel graphics driver (kgd).
AMD GPUs designed for use with HSA (Sea Islands and up) share some hardware functionality between HSA compute and regular gfx/compute (memory, interrupts, registers), while other functionality has been added specifically for HSA compute (hw scheduler for virtualized compute rings). All shared hardware is owned by the radeon graphics driver, and an interface between kfd and kgd allows the kfd to make use of those shared resources, while HSA-specific functionality is managed directly by kfd by submitting packets into an HSA-specific command queue (the "HIQ").

During kfd module initialization a char device node (/dev/kfd) is created (surviving until module exit), with ioctls for queue creation & management, and data structures are initialized for managing HSA device topology. The rest of the initialization is driven by calls from the radeon kgd at the following points :

- radeon_init (kfd_init)
- radeon_exit (kfd_fini)
- radeon_driver_load_kms (kfd_device_probe, kfd_device_init)
- radeon_driver_unload_kms (kfd_device_fini)

During the probe and init processing per-device data structures are established which connect to the associated graphics kernel driver. This information is exposed to userspace via sysfs, along with a version number allowing userspace to determine if a topology change has occurred while it was reading from sysfs.
The interface between kfd and kgd also allows the kfd to request buffer management services from kgd, and allows kgd to route interrupt requests to kfd code since the interrupt block is shared between regular graphics/compute and HSA compute subsystems in the GPU.

The kfd code works with an open source usermode library ("libhsakmt") which is in the final stages of IP review and should be published in a separate repo over the next few days.
The code operates in one of three modes, selectable via the sched_policy module parameter :

- sched_policy=0 uses a hardware scheduler running in the MEC block within CP, and allows oversubscription (more queues than HW slots)
- sched_policy=1 also uses HW scheduling but does not allow oversubscription, so create_queue requests fail when we run out of HW slots
- sched_policy=2 does not use HW scheduling, so the driver manually assigns queues to HW slots by programming registers

The "no HW scheduling" option is for debug & new hardware bringup only, so has less test coverage than the other options. Default in the current code is "HW scheduling without oversubscription" since that is where we have the most test coverage but we expect to change the default to "HW scheduling with oversubscription" after further testing. This effectively removes the HW limit on the number of work queues available to applications.

Programs running on the GPU are associated with an address space through the VMID field, which is translated to a unique PASID at access time via a set of 16 VMID-to-PASID mapping registers. The available VMIDs (currently 16) are partitioned (under control of the radeon kgd) between current gfx/compute and HSA compute, with each getting 8 in the current code. The VMID-to-PASID mapping registers are updated by the HW scheduler when used, and by driver code if HW scheduling is not being used.
The Sea Islands compute queues use a new "doorbell" mechanism instead of the earlier kernel-managed write pointer registers. Doorbells use a separate BAR dedicated for this purpose, and pages within the doorbell aperture are mapped to userspace (each page mapped to only one user address space). Writes to the doorbell aperture are intercepted by GPU hardware, allowing userspace code to safely manage work queues (rings) without requiring a kernel call for every ring update.
First step for an application process is to open the kfd device. Calls to open create a kfd "process" structure only for the first thread of the process. Subsequent open calls are checked to see if they are from processes using the same mm_struct and, if so, don't do anything. The kfd per-process data lives as long as the mm_struct exists. Each mm_struct is associated with a unique PASID, allowing the IOMMUv2 to make userspace process memory accessible to the GPU.
Next step is for the application to collect topology information via sysfs. This gives userspace enough information to be able to identify specific nodes (processors) in subsequent queue management calls. Application processes can create queues on multiple processors, and processors support queues from multiple processes.
At this point the application can create work queues in userspace memory and pass them through the usermode library to kfd to have them mapped onto HW queue slots so that commands written to the queues can be executed by the GPU. Queue operations specify a processor node, and so the bulk of this code is device-specific.
Written by John Bridgman <[email protected]>

Alexey Skidanov (1):
amdkfd: Implement the Get Process Aperture IOCTL

Andrew Lewycky (3):
amdkfd: Add basic modules to amdkfd
amdkfd: Add interrupt handling module
amdkfd: Implement the Set Memory Policy IOCTL

Ben Goz (8):
amdkfd: Add queue module
amdkfd: Add mqd_manager module
amdkfd: Add kernel queue module
amdkfd: Add module parameter of scheduling policy
amdkfd: Add packet manager module
amdkfd: Add process queue manager module
amdkfd: Add device queue manager module
amdkfd: Implement the create/destroy/update queue IOCTLs

Evgeny Pinchuk (3):
amdkfd: Add topology module to amdkfd
amdkfd: Implement the Get Clock Counters IOCTL
amdkfd: Implement the PMC Acquire/Release IOCTLs

Oded Gabbay (10):
mm: Add kfd_process pointer to mm_struct drm/radeon: reduce number of free VMIDs and pipes in KV drm/radeon/cik: Don't touch int of pipes 1-7 drm/radeon: Report doorbell configuration to amdkfd drm/radeon: adding synchronization for GRBM GFX drm/radeon: Add radeon <--> amdkfd interface Update MAINTAINERS and CREDITS files with amdkfd info
amdkfd: Add IOCTL set definitions of amdkfd
amdkfd: Add amdkfd skeleton driver
amdkfd: Add binding/unbinding calls to amd_iommu driver

 CREDITS                                            |    7 +
 MAINTAINERS                                        |   10 +
 drivers/gpu/drm/radeon/Kconfig                     |    2 +
 drivers/gpu/drm/radeon/Makefile                    |    3 +
 drivers/gpu/drm/radeon/amdkfd/Kconfig              |   10 +
 drivers/gpu/drm/radeon/amdkfd/Makefile             |   14 +
 drivers/gpu/drm/radeon/amdkfd/cik_mqds.h           |  185 +++
 drivers/gpu/drm/radeon/amdkfd/cik_regs.h           |  220 ++++
 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c       |  123 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c        |  518 +++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_crat.h           |  294 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_device.c         |  254 ++++
 .../drm/radeon/amdkfd/kfd_device_queue_manager.c   |  985 ++++++++++++++++
 .../drm/radeon/amdkfd/kfd_device_queue_manager.h   |  101 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c       |  264 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c      |  161 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c   |  305 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h   |   66 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_module.c         |  131 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c    |  291 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h    |   54 +
 drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c |  488 ++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c          |   97 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h    |  682 +++++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h    |  107 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h           |  466 ++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_process.c        |  405 +++++++
 .../drm/radeon/amdkfd/kfd_process_queue_manager.c  |  343 ++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_queue.c          |  109 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_topology.c       | 1207 ++++++++++++++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_topology.h       |  168 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_vidmem.c         |   96 ++
 drivers/gpu/drm/radeon/cik.c                       |  154 +--
 drivers/gpu/drm/radeon/cik_reg.h                   |   65 ++
 drivers/gpu/drm/radeon/cikd.h                      |   51 +-
 drivers/gpu/drm/radeon/radeon.h                    |    9 +
 drivers/gpu/drm/radeon/radeon_device.c             |   32 +
 drivers/gpu/drm/radeon/radeon_drv.c                |    5 +
 drivers/gpu/drm/radeon/radeon_kfd.c                |  566 +++++++++
 drivers/gpu/drm/radeon/radeon_kfd.h                |  119 ++
 drivers/gpu/drm/radeon/radeon_kms.c                |    7 +
 include/linux/mm_types.h                           |   14 +
 include/uapi/linux/kfd_ioctl.h                     |  133 +++
 43 files changed, 9226 insertions(+), 95 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/Kconfig
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/Makefile
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_mqds.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_regs.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_crat.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_module.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process_queue_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_queue.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_vidmem.c
 create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.c
 create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.h
 create mode 100644 include/uapi/linux/kfd_ioctl.h

Signature · 1 line

1.9.1

Quoted 24 lines · Oded Gabbay

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them are modifications to radeon driver and 18 of them include only amdkfd code. There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under drm/radeon/amdkfd. This move was done to emphasize the fact that this driver is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point is the radeon driver. Having said that, we will probably need to move it (maybe to be directly under drm) after we integrate with additional AMD gfx drivers.

Quoted 4 lines

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

It might be better to add a drivers/gpu/drm/amd directory and add common stuff there.

Given that this is not intended to be final HSA api AFAICT then i would say this far better to avoid the whole kfd module and add ioctl to radeon. This would avoid crazy communication btw radeon and kfd.

The whole aperture business needs some serious explanation. Especialy as you want to use userspace address there is nothing to prevent userspace program from allocating things at address you reserve for lds, scratch, ... only sane way would be to move those lds, scratch inside the virtual address reserved for kernel (see kernel memory map).

The whole business of locking performance counter for exclusive per process access is a big NO. Which leads me to the questionable usefullness of user space command ring. I only see issues with that. First and foremost i would need to see solid figures that kernel ioctl or syscall has a higher an overhead that is measurable in any meaning full way against a simple function call. I know the userspace command ring is a big marketing features that please ignorant userspace programmer. But really this only brings issues and for absolutely not upside afaict.

So i would rather see a very simple ioctl that write the doorbell and might do more than that in case of ring/queue overcommit where it would first have to wait for a free ring/queue to schedule stuff. This would also allow sane implementation of things like performance counter that could be acquire by kernel for duration of a job submitted by userspace. While still not optimal this would be better that userspace locking.

I might have more thoughts once i am done with all the patches.

Cheers,
Jérôme

Quoted 216 lines

Original Cover Letter:

This patch set implements a Heterogeneous System Architecture (HSA) driver for radeon-family GPUs.
HSA allows different processor types (CPUs, DSPs, GPUs, etc..) to share system resources more effectively via HW features including shared pageable memory, userspace-accessible work queues, and platform-level atomics. In addition to the memory protection mechanisms in GPUVM and IOMMUv2, the Sea Islands family of GPUs also performs HW-level validation of commands passed in through the queues (aka rings).

The code in this patch set is intended to serve both as a sample driver for other HSA-compatible hardware devices and as a production driver for radeon-family processors. The code is architected to support multiple CPUs each with connected GPUs, although the current implementation focuses on a single Kaveri/Berlin APU, and works alongside the existing radeon kernel graphics driver (kgd).
AMD GPUs designed for use with HSA (Sea Islands and up) share some hardware functionality between HSA compute and regular gfx/compute (memory, interrupts, registers), while other functionality has been added specifically for HSA compute (hw scheduler for virtualized compute rings). All shared hardware is owned by the radeon graphics driver, and an interface between kfd and kgd allows the kfd to make use of those shared resources, while HSA-specific functionality is managed directly by kfd by submitting packets into an HSA-specific command queue (the "HIQ").

During kfd module initialization a char device node (/dev/kfd) is created (surviving until module exit), with ioctls for queue creation & management, and data structures are initialized for managing HSA device topology. The rest of the initialization is driven by calls from the radeon kgd at the following points :

- radeon_init (kfd_init)
- radeon_exit (kfd_fini)
- radeon_driver_load_kms (kfd_device_probe, kfd_device_init)
- radeon_driver_unload_kms (kfd_device_fini)

During the probe and init processing per-device data structures are established which connect to the associated graphics kernel driver. This information is exposed to userspace via sysfs, along with a version number allowing userspace to determine if a topology change has occurred while it was reading from sysfs.
The interface between kfd and kgd also allows the kfd to request buffer management services from kgd, and allows kgd to route interrupt requests to kfd code since the interrupt block is shared between regular graphics/compute and HSA compute subsystems in the GPU.

The kfd code works with an open source usermode library ("libhsakmt") which is in the final stages of IP review and should be published in a separate repo over the next few days.
The code operates in one of three modes, selectable via the sched_policy module parameter :

- sched_policy=0 uses a hardware scheduler running in the MEC block within CP, and allows oversubscription (more queues than HW slots)
- sched_policy=1 also uses HW scheduling but does not allow oversubscription, so create_queue requests fail when we run out of HW slots
- sched_policy=2 does not use HW scheduling, so the driver manually assigns queues to HW slots by programming registers

The "no HW scheduling" option is for debug & new hardware bringup only, so has less test coverage than the other options. Default in the current code is "HW scheduling without oversubscription" since that is where we have the most test coverage but we expect to change the default to "HW scheduling with oversubscription" after further testing. This effectively removes the HW limit on the number of work queues available to applications.

Programs running on the GPU are associated with an address space through the VMID field, which is translated to a unique PASID at access time via a set of 16 VMID-to-PASID mapping registers. The available VMIDs (currently 16) are partitioned (under control of the radeon kgd) between current gfx/compute and HSA compute, with each getting 8 in the current code. The VMID-to-PASID mapping registers are updated by the HW scheduler when used, and by driver code if HW scheduling is not being used.
The Sea Islands compute queues use a new "doorbell" mechanism instead of the earlier kernel-managed write pointer registers. Doorbells use a separate BAR dedicated for this purpose, and pages within the doorbell aperture are mapped to userspace (each page mapped to only one user address space). Writes to the doorbell aperture are intercepted by GPU hardware, allowing userspace code to safely manage work queues (rings) without requiring a kernel call for every ring update.
First step for an application process is to open the kfd device. Calls to open create a kfd "process" structure only for the first thread of the process. Subsequent open calls are checked to see if they are from processes using the same mm_struct and, if so, don't do anything. The kfd per-process data lives as long as the mm_struct exists. Each mm_struct is associated with a unique PASID, allowing the IOMMUv2 to make userspace process memory accessible to the GPU.
Next step is for the application to collect topology information via sysfs. This gives userspace enough information to be able to identify specific nodes (processors) in subsequent queue management calls. Application processes can create queues on multiple processors, and processors support queues from multiple processes.
At this point the application can create work queues in userspace memory and pass them through the usermode library to kfd to have them mapped onto HW queue slots so that commands written to the queues can be executed by the GPU. Queue operations specify a processor node, and so the bulk of this code is device-specific.
Written by John Bridgman <[email protected]>

Alexey Skidanov (1):
amdkfd: Implement the Get Process Aperture IOCTL

Andrew Lewycky (3):
amdkfd: Add basic modules to amdkfd
amdkfd: Add interrupt handling module
amdkfd: Implement the Set Memory Policy IOCTL

Ben Goz (8):
amdkfd: Add queue module
amdkfd: Add mqd_manager module
amdkfd: Add kernel queue module
amdkfd: Add module parameter of scheduling policy
amdkfd: Add packet manager module
amdkfd: Add process queue manager module
amdkfd: Add device queue manager module
amdkfd: Implement the create/destroy/update queue IOCTLs

Evgeny Pinchuk (3):
amdkfd: Add topology module to amdkfd
amdkfd: Implement the Get Clock Counters IOCTL
amdkfd: Implement the PMC Acquire/Release IOCTLs

Oded Gabbay (10):
mm: Add kfd_process pointer to mm_struct drm/radeon: reduce number of free VMIDs and pipes in KV drm/radeon/cik: Don't touch int of pipes 1-7 drm/radeon: Report doorbell configuration to amdkfd drm/radeon: adding synchronization for GRBM GFX drm/radeon: Add radeon <--> amdkfd interface Update MAINTAINERS and CREDITS files with amdkfd info
amdkfd: Add IOCTL set definitions of amdkfd
amdkfd: Add amdkfd skeleton driver
amdkfd: Add binding/unbinding calls to amd_iommu driver

 CREDITS                                            |    7 +
 MAINTAINERS                                        |   10 +
 drivers/gpu/drm/radeon/Kconfig                     |    2 +
 drivers/gpu/drm/radeon/Makefile                    |    3 +
 drivers/gpu/drm/radeon/amdkfd/Kconfig              |   10 +
 drivers/gpu/drm/radeon/amdkfd/Makefile             |   14 +
 drivers/gpu/drm/radeon/amdkfd/cik_mqds.h           |  185 +++
 drivers/gpu/drm/radeon/amdkfd/cik_regs.h           |  220 ++++
 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c       |  123 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c        |  518 +++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_crat.h           |  294 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_device.c         |  254 ++++
 .../drm/radeon/amdkfd/kfd_device_queue_manager.c   |  985 ++++++++++++++++
 .../drm/radeon/amdkfd/kfd_device_queue_manager.h   |  101 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c       |  264 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c      |  161 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c   |  305 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h   |   66 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_module.c         |  131 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c    |  291 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h    |   54 +
 drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c |  488 ++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c          |   97 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h    |  682 +++++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h    |  107 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h           |  466 ++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_process.c        |  405 +++++++
 .../drm/radeon/amdkfd/kfd_process_queue_manager.c  |  343 ++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_queue.c          |  109 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_topology.c       | 1207 ++++++++++++++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_topology.h       |  168 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_vidmem.c         |   96 ++
 drivers/gpu/drm/radeon/cik.c                       |  154 +--
 drivers/gpu/drm/radeon/cik_reg.h                   |   65 ++
 drivers/gpu/drm/radeon/cikd.h                      |   51 +-
 drivers/gpu/drm/radeon/radeon.h                    |    9 +
 drivers/gpu/drm/radeon/radeon_device.c             |   32 +
 drivers/gpu/drm/radeon/radeon_drv.c                |    5 +
 drivers/gpu/drm/radeon/radeon_kfd.c                |  566 +++++++++
 drivers/gpu/drm/radeon/radeon_kfd.h                |  119 ++
 drivers/gpu/drm/radeon/radeon_kms.c                |    7 +
 include/linux/mm_types.h                           |   14 +
 include/uapi/linux/kfd_ioctl.h                     |  133 +++
 43 files changed, 9226 insertions(+), 95 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/Kconfig
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/Makefile
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_mqds.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_regs.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_crat.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_module.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process_queue_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_queue.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_vidmem.c
 create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.c
 create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.h
 create mode 100644 include/uapi/linux/kfd_ioctl.h

Signature · 1 line

1.9.1

Quoted 24 lines · Oded Gabbay

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them are modifications to radeon driver and 18 of them include only amdkfd code. There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under drm/radeon/amdkfd. This move was done to emphasize the fact that this driver is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point is the radeon driver. Having said that, we will probably need to move it (maybe to be directly under drm) after we integrate with additional AMD gfx drivers.

Quoted 4 lines

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

It might be better to add a drivers/gpu/drm/amd directory and add common stuff there.

Given that this is not intended to be final HSA api AFAICT then i would say this far better to avoid the whole kfd module and add ioctl to radeon. This would avoid crazy communication btw radeon and kfd.

The whole aperture business needs some serious explanation. Especialy as you want to use userspace address there is nothing to prevent userspace program from allocating things at address you reserve for lds, scratch, ... only sane way would be to move those lds, scratch inside the virtual address reserved for kernel (see kernel memory map).

The whole business of locking performance counter for exclusive per process access is a big NO. Which leads me to the questionable usefullness of user space command ring. I only see issues with that. First and foremost i would need to see solid figures that kernel ioctl or syscall has a higher an overhead that is measurable in any meaning full way against a simple function call. I know the userspace command ring is a big marketing features that please ignorant userspace programmer. But really this only brings issues and for absolutely not upside afaict.

So i would rather see a very simple ioctl that write the doorbell and might do more than that in case of ring/queue overcommit where it would first have to wait for a free ring/queue to schedule stuff. This would also allow sane implementation of things like performance counter that could be acquire by kernel for duration of a job submitted by userspace. While still not optimal this would be better that userspace locking.

Quoted 59 lines · Oded Gabbay

Quoted 24 lines

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them are modifications to radeon driver and 18 of them include only amdkfd code. There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under drm/radeon/amdkfd. This move was done to emphasize the fact that this driver is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point is the radeon driver. Having said that, we will probably need to move it (maybe to be directly under drm) after we integrate with additional AMD gfx drivers.

Quoted 4 lines

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

It might be better to add a drivers/gpu/drm/amd directory and add common stuff there.

Given that this is not intended to be final HSA api AFAICT then i would say this far better to avoid the whole kfd module and add ioctl to radeon. This would avoid crazy communication btw radeon and kfd.

The whole aperture business needs some serious explanation. Especialy as you want to use userspace address there is nothing to prevent userspace program from allocating things at address you reserve for lds, scratch, ... only sane way would be to move those lds, scratch inside the virtual address reserved for kernel (see kernel memory map).

The whole business of locking performance counter for exclusive per process access is a big NO. Which leads me to the questionable usefullness of user space command ring. I only see issues with that. First and foremost i would need to see solid figures that kernel ioctl or syscall has a higher an overhead that is measurable in any meaning full way against a simple function call. I know the userspace command ring is a big marketing features that please ignorant userspace programmer. But really this only brings issues and for absolutely not upside afaict.

Quoted 6 lines

So i would rather see a very simple ioctl that write the doorbell and might do more than that in case of ring/queue overcommit where it would first have to wait for a free ring/queue to schedule stuff. This would also allow sane implementation of things like performance counter that could be acquire by kernel for duration of a job submitted by userspace. While still not optimal this would be better that userspace locking.

Quick aside and mostly off the record: In i915 we plan to have the first implementation exactly as Jerome suggests here:
- New flag at context creationg for svm/seamless-gpgpu contexts.
- New ioctl in i915 for submitting stuff to the hw (through doorbell or whatever else we want to do). The ring in the ctx would be under the kernel's control.

Of course there's lots of GEM stuff we don't need at all for such contexts, but there's still lots of shared code. Imo creating a 2nd driver has too much interface surface and so is a maintainence hell.

And the ioctl submission gives us flexibility in case the hw doesn't quite live up to promise (e.g. scheduling, cmd parsing, ...). -Daniel

Quoted 24 lines · Oded Gabbay

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them are modifications to radeon driver and 18 of them include only amdkfd code. There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under drm/radeon/amdkfd. This move was done to emphasize the fact that this driver is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point is the radeon driver. Having said that, we will probably need to move it (maybe to be directly under drm) after we integrate with additional AMD gfx drivers.

Quoted 4 lines

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

It might be better to add a drivers/gpu/drm/amd directory and add common stuff there.

Given that this is not intended to be final HSA api AFAICT then i would say this far better to avoid the whole kfd module and add ioctl to radeon. This would avoid crazy communication btw radeon and kfd.

The whole aperture business needs some serious explanation. Especialy as you want to use userspace address there is nothing to prevent userspace program from allocating things at address you reserve for lds, scratch, ... only sane way would be to move those lds, scratch inside the virtual address reserved for kernel (see kernel memory map).

The whole business of locking performance counter for exclusive per process access is a big NO. Which leads me to the questionable usefullness of user space command ring.

I only see issues with that. First and foremost i would
need to see solid figures that kernel ioctl or syscall has a higher an overhead that is measurable in any meaning full way against a simple function call. I know the userspace command ring is a big marketing features that please ignorant userspace programmer. But really this only brings issues and for absolutely not upside afaict.

So i would rather see a very simple ioctl that write the doorbell and might do more than that in case of ring/queue overcommit where it would first have to wait for a free ring/queue to schedule stuff. This would also allow sane implementation of things like performance counter that could be acquire by kernel for duration of a job submitted by userspace. While still not optimal this would be better that userspace locking.

I might have more thoughts once i am done with all the patches.

Cheers,
Jérôme

Quoted 216 lines

Original Cover Letter:

This patch set implements a Heterogeneous System Architecture (HSA) driver for radeon-family GPUs.
HSA allows different processor types (CPUs, DSPs, GPUs, etc..) to share system resources more effectively via HW features including shared pageable memory, userspace-accessible work queues, and platform-level atomics. In addition to the memory protection mechanisms in GPUVM and IOMMUv2, the Sea Islands family of GPUs also performs HW-level validation of commands passed in through the queues (aka rings).

The code in this patch set is intended to serve both as a sample driver for other HSA-compatible hardware devices and as a production driver for radeon-family processors. The code is architected to support multiple CPUs each with connected GPUs, although the current implementation focuses on a single Kaveri/Berlin APU, and works alongside the existing radeon kernel graphics driver (kgd).
AMD GPUs designed for use with HSA (Sea Islands and up) share some hardware functionality between HSA compute and regular gfx/compute (memory, interrupts, registers), while other functionality has been added specifically for HSA compute (hw scheduler for virtualized compute rings). All shared hardware is owned by the radeon graphics driver, and an interface between kfd and kgd allows the kfd to make use of those shared resources, while HSA-specific functionality is managed directly by kfd by submitting packets into an HSA-specific command queue (the "HIQ").

During kfd module initialization a char device node (/dev/kfd) is created (surviving until module exit), with ioctls for queue creation & management, and data structures are initialized for managing HSA device topology. The rest of the initialization is driven by calls from the radeon kgd at the following points :

- radeon_init (kfd_init)
- radeon_exit (kfd_fini)
- radeon_driver_load_kms (kfd_device_probe, kfd_device_init)
- radeon_driver_unload_kms (kfd_device_fini)

During the probe and init processing per-device data structures are established which connect to the associated graphics kernel driver. This information is exposed to userspace via sysfs, along with a version number allowing userspace to determine if a topology change has occurred while it was reading from sysfs.
The interface between kfd and kgd also allows the kfd to request buffer management services from kgd, and allows kgd to route interrupt requests to kfd code since the interrupt block is shared between regular graphics/compute and HSA compute subsystems in the GPU.

The kfd code works with an open source usermode library ("libhsakmt") which is in the final stages of IP review and should be published in a separate repo over the next few days.
The code operates in one of three modes, selectable via the sched_policy module parameter :

- sched_policy=0 uses a hardware scheduler running in the MEC block within CP, and allows oversubscription (more queues than HW slots)
- sched_policy=1 also uses HW scheduling but does not allow oversubscription, so create_queue requests fail when we run out of HW slots
- sched_policy=2 does not use HW scheduling, so the driver manually assigns queues to HW slots by programming registers

The "no HW scheduling" option is for debug & new hardware bringup only, so has less test coverage than the other options. Default in the current code is "HW scheduling without oversubscription" since that is where we have the most test coverage but we expect to change the default to "HW scheduling with oversubscription" after further testing. This effectively removes the HW limit on the number of work queues available to applications.

Programs running on the GPU are associated with an address space through the VMID field, which is translated to a unique PASID at access time via a set of 16 VMID-to-PASID mapping registers. The available VMIDs (currently 16) are partitioned (under control of the radeon kgd) between current gfx/compute and HSA compute, with each getting 8 in the current code. The VMID-to-PASID mapping registers are updated by the HW scheduler when used, and by driver code if HW scheduling is not being used.
The Sea Islands compute queues use a new "doorbell" mechanism instead of the earlier kernel-managed write pointer registers. Doorbells use a separate BAR dedicated for this purpose, and pages within the doorbell aperture are mapped to userspace (each page mapped to only one user address space). Writes to the doorbell aperture are intercepted by GPU hardware, allowing userspace code to safely manage work queues (rings) without requiring a kernel call for every ring update.
First step for an application process is to open the kfd device. Calls to open create a kfd "process" structure only for the first thread of the process. Subsequent open calls are checked to see if they are from processes using the same mm_struct and, if so, don't do anything. The kfd per-process data lives as long as the mm_struct exists. Each mm_struct is associated with a unique PASID, allowing the IOMMUv2 to make userspace process memory accessible to the GPU.
Next step is for the application to collect topology information via sysfs. This gives userspace enough information to be able to identify specific nodes (processors) in subsequent queue management calls. Application processes can create queues on multiple processors, and processors support queues from multiple processes.
At this point the application can create work queues in userspace memory and pass them through the usermode library to kfd to have them mapped onto HW queue slots so that commands written to the queues can be executed by the GPU. Queue operations specify a processor node, and so the bulk of this code is device-specific.
Written by John Bridgman <[email protected]>

Alexey Skidanov (1):
amdkfd: Implement the Get Process Aperture IOCTL

Andrew Lewycky (3):
amdkfd: Add basic modules to amdkfd
amdkfd: Add interrupt handling module
amdkfd: Implement the Set Memory Policy IOCTL

Ben Goz (8):
amdkfd: Add queue module
amdkfd: Add mqd_manager module
amdkfd: Add kernel queue module
amdkfd: Add module parameter of scheduling policy
amdkfd: Add packet manager module
amdkfd: Add process queue manager module
amdkfd: Add device queue manager module
amdkfd: Implement the create/destroy/update queue IOCTLs

Evgeny Pinchuk (3):
amdkfd: Add topology module to amdkfd
amdkfd: Implement the Get Clock Counters IOCTL
amdkfd: Implement the PMC Acquire/Release IOCTLs

Oded Gabbay (10):
mm: Add kfd_process pointer to mm_struct drm/radeon: reduce number of free VMIDs and pipes in KV drm/radeon/cik: Don't touch int of pipes 1-7 drm/radeon: Report doorbell configuration to amdkfd drm/radeon: adding synchronization for GRBM GFX drm/radeon: Add radeon <--> amdkfd interface Update MAINTAINERS and CREDITS files with amdkfd info
amdkfd: Add IOCTL set definitions of amdkfd
amdkfd: Add amdkfd skeleton driver
amdkfd: Add binding/unbinding calls to amd_iommu driver

  CREDITS                                            |    7 +
  MAINTAINERS                                        |   10 +
  drivers/gpu/drm/radeon/Kconfig                     |    2 +
  drivers/gpu/drm/radeon/Makefile                    |    3 +
  drivers/gpu/drm/radeon/amdkfd/Kconfig              |   10 +
  drivers/gpu/drm/radeon/amdkfd/Makefile             |   14 +
  drivers/gpu/drm/radeon/amdkfd/cik_mqds.h           |  185 +++
  drivers/gpu/drm/radeon/amdkfd/cik_regs.h           |  220 ++++
  drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c       |  123 ++
  drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c        |  518 +++++++++
  drivers/gpu/drm/radeon/amdkfd/kfd_crat.h           |  294 +++++
  drivers/gpu/drm/radeon/amdkfd/kfd_device.c         |  254 ++++
  .../drm/radeon/amdkfd/kfd_device_queue_manager.c   |  985 ++++++++++++++++
  .../drm/radeon/amdkfd/kfd_device_queue_manager.h   |  101 ++
  drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c       |  264 +++++
  drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c      |  161 +++
  drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c   |  305 +++++
  drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h   |   66 ++
  drivers/gpu/drm/radeon/amdkfd/kfd_module.c         |  131 +++
  drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c    |  291 +++++
  drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h    |   54 +
  drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c |  488 ++++++++
  drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c          |   97 ++
  drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h    |  682 +++++++++++
  drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h    |  107 ++
  drivers/gpu/drm/radeon/amdkfd/kfd_priv.h           |  466 ++++++++
  drivers/gpu/drm/radeon/amdkfd/kfd_process.c        |  405 +++++++
  .../drm/radeon/amdkfd/kfd_process_queue_manager.c  |  343 ++++++
  drivers/gpu/drm/radeon/amdkfd/kfd_queue.c          |  109 ++
  drivers/gpu/drm/radeon/amdkfd/kfd_topology.c       | 1207 ++++++++++++++++++++
  drivers/gpu/drm/radeon/amdkfd/kfd_topology.h       |  168 +++
  drivers/gpu/drm/radeon/amdkfd/kfd_vidmem.c         |   96 ++
  drivers/gpu/drm/radeon/cik.c                       |  154 +--
  drivers/gpu/drm/radeon/cik_reg.h                   |   65 ++
  drivers/gpu/drm/radeon/cikd.h                      |   51 +-
  drivers/gpu/drm/radeon/radeon.h                    |    9 +
  drivers/gpu/drm/radeon/radeon_device.c             |   32 +
  drivers/gpu/drm/radeon/radeon_drv.c                |    5 +
  drivers/gpu/drm/radeon/radeon_kfd.c                |  566 +++++++++
  drivers/gpu/drm/radeon/radeon_kfd.h                |  119 ++
  drivers/gpu/drm/radeon/radeon_kms.c                |    7 +
  include/linux/mm_types.h                           |   14 +
  include/uapi/linux/kfd_ioctl.h                     |  133 +++
  43 files changed, 9226 insertions(+), 95 deletions(-)

create mode 100644 drivers/gpu/drm/radeon/amdkfd/Kconfig
create mode 100644 drivers/gpu/drm/radeon/amdkfd/Makefile create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_mqds.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_regs.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_crat.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_module.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process_queue_manager.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_queue.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_vidmem.c create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.c
create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.h
create mode 100644 include/uapi/linux/kfd_ioctl.h

--
1.9.1

Quoted 25 lines · Oded Gabbay

Quoted 24 lines

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them are modifications to radeon driver and 18 of them include only amdkfd code. There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under drm/radeon/amdkfd. This move was done to emphasize the fact that this driver is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point is the radeon driver. Having said that, we will probably need to move it (maybe to be directly under drm) after we integrate with additional AMD gfx drivers.

Quoted 8 lines

Quoted 4 lines

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

So quick comments on some of your questions but first of all, thanks for the time you dedicated to review the code.

Quoted 4 lines

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

We only do gpu memory pinning for kernel objects. There are no userspace objects that are pinned on the gpu memory in our driver. If that is the case, is it still a show stopper ?

The kernel objects are:
- pipelines (4 per device)
- mqd per hiq (only 1 per device)
- mqd per userspace queue. On KV, we support up to 1K queues per
process, for a total of 512K queues. Each mqd is 151 bytes, but the allocation is done in 256 alignment. So total *possible* memory is 128MB
- kernel queue (only 1 per device)
- fence address for kernel queue
- runlists for the CP (1 or 2 per device)

Quoted 14 lines

It might be better to add a drivers/gpu/drm/amd directory and add common stuff there.

Given that this is not intended to be final HSA api AFAICT then i would say this far better to avoid the whole kfd module and add ioctl to radeon. This would avoid crazy communication btw radeon and kfd.

The whole aperture business needs some serious explanation. Especialy as you want to use userspace address there is nothing to prevent userspace program from allocating things at address you reserve for lds, scratch, ... only sane way would be to move those lds, scratch inside the virtual address reserved for kernel (see kernel memory map).

Quoted 3 lines

The whole business of locking performance counter for exclusive per process access is a big NO. Which leads me to the questionable usefullness of user space command ring.

That's like saying: "Which leads me to the questionable usefulness of HSA". I find it analogous to a situation where a network maintainer nacking a driver for a network card, which is slower than a different network card. Doesn't seem reasonable this situation is would happen. He would still put both the drivers in the kernel because people want to use the H/W and its features. So, I don't think this is a valid reason to NACK the driver.

Quoted 6 lines

I only see issues with that. First and foremost i would
need to see solid figures that kernel ioctl or syscall has a higher an overhead that is measurable in any meaning full way against a simple function call. I know the userspace command ring is a big marketing features that please ignorant userspace programmer. But really this only brings issues and for absolutely not upside afaict.

Really ? You think that doing a context switch to kernel space, with all its overhead, is _not_ more expansive than just calling a function in userspace which only puts a buffer on a ring and writes a doorbell ?

Quoted 237 lines

So i would rather see a very simple ioctl that write the doorbell and might do more than that in case of ring/queue overcommit where it would first have to wait for a free ring/queue to schedule stuff. This would also allow sane implementation of things like performance counter that could be acquire by kernel for duration of a job submitted by userspace. While still not optimal this would be better that userspace locking.

I might have more thoughts once i am done with all the patches.

Cheers,
Jérôme

Quoted 223 lines

Original Cover Letter:

This patch set implements a Heterogeneous System Architecture (HSA) driver for radeon-family GPUs.
HSA allows different processor types (CPUs, DSPs, GPUs, etc..) to share system resources more effectively via HW features including shared pageable memory, userspace-accessible work queues, and platform-level atomics. In addition to the memory protection mechanisms in GPUVM and IOMMUv2, the Sea Islands family of GPUs also performs HW-level validation of commands passed in through the queues (aka rings).

The code in this patch set is intended to serve both as a sample driver for other HSA-compatible hardware devices and as a production driver for radeon-family processors. The code is architected to support multiple CPUs each with connected GPUs, although the current implementation focuses on a single Kaveri/Berlin APU, and works alongside the existing radeon kernel graphics driver (kgd).
AMD GPUs designed for use with HSA (Sea Islands and up) share some hardware functionality between HSA compute and regular gfx/compute (memory, interrupts, registers), while other functionality has been added specifically for HSA compute (hw scheduler for virtualized compute rings). All shared hardware is owned by the radeon graphics driver, and an interface between kfd and kgd allows the kfd to make use of those shared resources, while HSA-specific functionality is managed directly by kfd by submitting packets into an HSA-specific command queue (the "HIQ").

During kfd module initialization a char device node (/dev/kfd) is created (surviving until module exit), with ioctls for queue creation & management, and data structures are initialized for managing HSA device topology. The rest of the initialization is driven by calls from the radeon kgd at the following points :

- radeon_init (kfd_init)
- radeon_exit (kfd_fini)
- radeon_driver_load_kms (kfd_device_probe, kfd_device_init)
- radeon_driver_unload_kms (kfd_device_fini)

During the probe and init processing per-device data structures are established which connect to the associated graphics kernel driver. This information is exposed to userspace via sysfs, along with a version number allowing userspace to determine if a topology change has occurred while it was reading from sysfs.
The interface between kfd and kgd also allows the kfd to request buffer management services from kgd, and allows kgd to route interrupt requests to kfd code since the interrupt block is shared between regular graphics/compute and HSA compute subsystems in the GPU.

The kfd code works with an open source usermode library ("libhsakmt") which is in the final stages of IP review and should be published in a separate repo over the next few days.
The code operates in one of three modes, selectable via the sched_policy module parameter :

- sched_policy=0 uses a hardware scheduler running in the MEC block within
CP, and allows oversubscription (more queues than HW slots)
- sched_policy=1 also uses HW scheduling but does not allow oversubscription, so create_queue requests fail when we run out of HW slots
- sched_policy=2 does not use HW scheduling, so the driver manually assigns
queues to HW slots by programming registers

The "no HW scheduling" option is for debug & new hardware bringup only, so has less test coverage than the other options. Default in the current code is "HW scheduling without oversubscription" since that is where we have the most test coverage but we expect to change the default to "HW scheduling with oversubscription" after further testing. This effectively removes the HW limit on the number of work queues available to applications.

Programs running on the GPU are associated with an address space through the VMID field, which is translated to a unique PASID at access time via a set of 16 VMID-to-PASID mapping registers. The available VMIDs (currently 16) are partitioned (under control of the radeon kgd) between current gfx/compute and HSA compute, with each getting 8 in the current code. The VMID-to-PASID mapping registers are updated by the HW scheduler when used, and by driver code if HW scheduling is not being used.
The Sea Islands compute queues use a new "doorbell" mechanism instead of the earlier kernel-managed write pointer registers. Doorbells use a separate BAR dedicated for this purpose, and pages within the doorbell aperture are mapped to userspace (each page mapped to only one user address space). Writes to the doorbell aperture are intercepted by GPU hardware, allowing userspace code to safely manage work queues (rings) without requiring a kernel call for every ring update.
First step for an application process is to open the kfd device. Calls to open create a kfd "process" structure only for the first thread of the process. Subsequent open calls are checked to see if they are from processes using the same mm_struct and, if so, don't do anything. The kfd per-process data lives as long as the mm_struct exists. Each mm_struct is associated with a unique PASID, allowing the IOMMUv2 to make userspace process memory accessible to the GPU.
Next step is for the application to collect topology information via sysfs. This gives userspace enough information to be able to identify specific nodes (processors) in subsequent queue management calls. Application processes can create queues on multiple processors, and processors support queues from multiple processes.
At this point the application can create work queues in userspace memory and pass them through the usermode library to kfd to have them mapped onto HW queue slots so that commands written to the queues can be executed by the GPU. Queue operations specify a processor node, and so the bulk of this code is device-specific.
Written by John Bridgman <[email protected]>

Alexey Skidanov (1):
amdkfd: Implement the Get Process Aperture IOCTL

Andrew Lewycky (3):
amdkfd: Add basic modules to amdkfd
amdkfd: Add interrupt handling module
amdkfd: Implement the Set Memory Policy IOCTL

Ben Goz (8):
amdkfd: Add queue module
amdkfd: Add mqd_manager module
amdkfd: Add kernel queue module
amdkfd: Add module parameter of scheduling policy
amdkfd: Add packet manager module
amdkfd: Add process queue manager module
amdkfd: Add device queue manager module
amdkfd: Implement the create/destroy/update queue IOCTLs

Evgeny Pinchuk (3):
amdkfd: Add topology module to amdkfd
amdkfd: Implement the Get Clock Counters IOCTL
amdkfd: Implement the PMC Acquire/Release IOCTLs

Oded Gabbay (10):
mm: Add kfd_process pointer to mm_struct drm/radeon: reduce number of free VMIDs and pipes in KV drm/radeon/cik: Don't touch int of pipes 1-7 drm/radeon: Report doorbell configuration to amdkfd drm/radeon: adding synchronization for GRBM GFX drm/radeon: Add radeon <--> amdkfd interface Update MAINTAINERS and CREDITS files with amdkfd info
amdkfd: Add IOCTL set definitions of amdkfd
amdkfd: Add amdkfd skeleton driver
amdkfd: Add binding/unbinding calls to amd_iommu driver

  CREDITS                                            |    7 +
  MAINTAINERS                                        |   10 +
  drivers/gpu/drm/radeon/Kconfig                     |    2 +
  drivers/gpu/drm/radeon/Makefile                    |    3 +
  drivers/gpu/drm/radeon/amdkfd/Kconfig              |   10 +
  drivers/gpu/drm/radeon/amdkfd/Makefile             |   14 +
  drivers/gpu/drm/radeon/amdkfd/cik_mqds.h           |  185 +++
  drivers/gpu/drm/radeon/amdkfd/cik_regs.h           |  220 ++++
  drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c       |  123 ++
  drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c        |  518 +++++++++
  drivers/gpu/drm/radeon/amdkfd/kfd_crat.h           |  294 +++++
  drivers/gpu/drm/radeon/amdkfd/kfd_device.c         |  254 ++++
  .../drm/radeon/amdkfd/kfd_device_queue_manager.c   |  985 
++++++++++++++++
  .../drm/radeon/amdkfd/kfd_device_queue_manager.h   |  101 ++
  drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c       |  264 +++++
  drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c      |  161 +++
  drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c   |  305 +++++
  drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h   |   66 ++
  drivers/gpu/drm/radeon/amdkfd/kfd_module.c         |  131 +++
  drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c    |  291 +++++
  drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h    |   54 +
  drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c |  488 ++++++++
  drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c          |   97 ++
  drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h    |  682 +++++++++++
  drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h    |  107 ++
  drivers/gpu/drm/radeon/amdkfd/kfd_priv.h           |  466 ++++++++
  drivers/gpu/drm/radeon/amdkfd/kfd_process.c        |  405 +++++++
  .../drm/radeon/amdkfd/kfd_process_queue_manager.c  |  343 ++++++
  drivers/gpu/drm/radeon/amdkfd/kfd_queue.c          |  109 ++
  drivers/gpu/drm/radeon/amdkfd/kfd_topology.c       | 1207 
++++++++++++++++++++
  drivers/gpu/drm/radeon/amdkfd/kfd_topology.h       |  168 +++
  drivers/gpu/drm/radeon/amdkfd/kfd_vidmem.c         |   96 ++
  drivers/gpu/drm/radeon/cik.c                       |  154 +--
  drivers/gpu/drm/radeon/cik_reg.h                   |   65 ++
  drivers/gpu/drm/radeon/cikd.h                      |   51 +-
  drivers/gpu/drm/radeon/radeon.h                    |    9 +
  drivers/gpu/drm/radeon/radeon_device.c             |   32 +
  drivers/gpu/drm/radeon/radeon_drv.c                |    5 +
  drivers/gpu/drm/radeon/radeon_kfd.c                |  566 +++++++++
  drivers/gpu/drm/radeon/radeon_kfd.h                |  119 ++
  drivers/gpu/drm/radeon/radeon_kms.c                |    7 +
  include/linux/mm_types.h                           |   14 +
  include/uapi/linux/kfd_ioctl.h                     |  133 +++
  43 files changed, 9226 insertions(+), 95 deletions(-)

create mode 100644 drivers/gpu/drm/radeon/amdkfd/Kconfig create mode 100644 drivers/gpu/drm/radeon/amdkfd/Makefile create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_mqds.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_regs.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_crat.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device.c create mode 100644
drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.c
create mode 100644
drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.h
create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_module.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process.c create mode 100644
drivers/gpu/drm/radeon/amdkfd/kfd_process_queue_manager.c
create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_queue.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_vidmem.c create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.c create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.h create mode 100644 include/uapi/linux/kfd_ioctl.h

Signature · 1 line

1.9.1

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 44 lines · Jerome Glisse

Quoted 25 lines · Oded Gabbay

Quoted 24 lines

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them are modifications to radeon driver and 18 of them include only amdkfd code. There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under drm/radeon/amdkfd. This move was done to emphasize the fact that this driver is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point is the radeon driver. Having said that, we will probably need to move it (maybe to be directly under drm) after we integrate with additional AMD gfx drivers.

Quoted 8 lines

Quoted 4 lines

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

So quick comments on some of your questions but first of all, thanks for the time you dedicated to review the code.

Quoted 4 lines

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

We only do gpu memory pinning for kernel objects. There are no userspace objects that are pinned on the gpu memory in our driver. If that is the case, is it still a show stopper ?

Quoted 9 lines

The kernel objects are:
- pipelines (4 per device)
- mqd per hiq (only 1 per device)
- mqd per userspace queue. On KV, we support up to 1K queues per process, for a total of 512K queues. Each mqd is 151 bytes, but the allocation is done in 256 alignment. So total *possible* memory is 128MB
- kernel queue (only 1 per device)
- fence address for kernel queue
- runlists for the CP (1 or 2 per device)

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Christian.

Quoted 262 lines

Quoted 15 lines

It might be better to add a drivers/gpu/drm/amd directory and add common stuff there.

Given that this is not intended to be final HSA api AFAICT then i would say this far better to avoid the whole kfd module and add ioctl to radeon. This would avoid crazy communication btw radeon and kfd.

The whole aperture business needs some serious explanation. Especialy as you want to use userspace address there is nothing to prevent userspace program from allocating things at address you reserve for lds, scratch, ... only sane way would be to move those lds, scratch inside the virtual address reserved for kernel (see kernel memory map).

Quoted 3 lines

The whole business of locking performance counter for exclusive per process access is a big NO. Which leads me to the questionable usefullness of user space command ring.

That's like saying: "Which leads me to the questionable usefulness of HSA". I find it analogous to a situation where a network maintainer nacking a driver for a network card, which is slower than a different network card. Doesn't seem reasonable this situation is would happen. He would still put both the drivers in the kernel because people want to use the H/W and its features. So, I don't think this is a valid reason to NACK the driver.

Quoted 6 lines

I only see issues with that. First and foremost i would
need to see solid figures that kernel ioctl or syscall has a higher an overhead that is measurable in any meaning full way against a simple function call. I know the userspace command ring is a big marketing features that please ignorant userspace programmer. But really this only brings issues and for absolutely not upside afaict.

Really ? You think that doing a context switch to kernel space, with all its overhead, is _not_ more expansive than just calling a function in userspace which only puts a buffer on a ring and writes a doorbell ?

Quoted 228 lines

So i would rather see a very simple ioctl that write the doorbell and might do more than that in case of ring/queue overcommit where it would first have to wait for a free ring/queue to schedule stuff. This would also allow sane implementation of things like performance counter that could be acquire by kernel for duration of a job submitted by userspace. While still not optimal this would be better that userspace locking.

I might have more thoughts once i am done with all the patches.

Cheers,
Jérôme

Quoted 214 lines

Original Cover Letter:

This patch set implements a Heterogeneous System Architecture (HSA) driver for radeon-family GPUs.
HSA allows different processor types (CPUs, DSPs, GPUs, etc..) to share system resources more effectively via HW features including shared pageable memory, userspace-accessible work queues, and platform-level atomics. In addition to the memory protection mechanisms in GPUVM and IOMMUv2, the Sea Islands family of GPUs also performs HW-level validation of commands passed in through the queues (aka rings).

The code in this patch set is intended to serve both as a sample driver for other HSA-compatible hardware devices and as a production driver for radeon-family processors. The code is architected to support multiple CPUs each with connected GPUs, although the current implementation focuses on a single Kaveri/Berlin APU, and works alongside the existing radeon kernel graphics driver (kgd).
AMD GPUs designed for use with HSA (Sea Islands and up) share some hardware functionality between HSA compute and regular gfx/compute (memory, interrupts, registers), while other functionality has been added specifically for HSA compute (hw scheduler for virtualized compute rings). All shared hardware is owned by the radeon graphics driver, and an interface between kfd and kgd allows the kfd to make use of those shared resources, while HSA-specific functionality is managed directly by kfd by submitting packets into an HSA-specific command queue (the "HIQ").

During kfd module initialization a char device node (/dev/kfd) is created (surviving until module exit), with ioctls for queue creation & management, and data structures are initialized for managing HSA device topology. The rest of the initialization is driven by calls from the radeon kgd at the following points :

- radeon_init (kfd_init)
- radeon_exit (kfd_fini)
- radeon_driver_load_kms (kfd_device_probe, kfd_device_init)
- radeon_driver_unload_kms (kfd_device_fini)

During the probe and init processing per-device data structures are established which connect to the associated graphics kernel driver. This information is exposed to userspace via sysfs, along with a version number allowing userspace to determine if a topology change has occurred while it was reading from sysfs.
The interface between kfd and kgd also allows the kfd to request buffer management services from kgd, and allows kgd to route interrupt requests to kfd code since the interrupt block is shared between regular graphics/compute and HSA compute subsystems in the GPU.

The kfd code works with an open source usermode library ("libhsakmt") which is in the final stages of IP review and should be published in a separate repo over the next few days.
The code operates in one of three modes, selectable via the sched_policy module parameter :

- sched_policy=0 uses a hardware scheduler running in the MEC block within CP, and allows oversubscription (more queues than HW slots)
- sched_policy=1 also uses HW scheduling but does not allow oversubscription, so create_queue requests fail when we run out of HW slots
- sched_policy=2 does not use HW scheduling, so the driver manually assigns queues to HW slots by programming registers

The "no HW scheduling" option is for debug & new hardware bringup only, so has less test coverage than the other options. Default in the current code is "HW scheduling without oversubscription" since that is where we have the most test coverage but we expect to change the default to "HW scheduling with oversubscription" after further testing. This effectively removes the HW limit on the number of work queues available to applications.

Programs running on the GPU are associated with an address space through the VMID field, which is translated to a unique PASID at access time via a set of 16 VMID-to-PASID mapping registers. The available VMIDs (currently 16) are partitioned (under control of the radeon kgd) between current gfx/compute and HSA compute, with each getting 8 in the current code. The VMID-to-PASID mapping registers are updated by the HW scheduler when used, and by driver code if HW scheduling is not being used.
The Sea Islands compute queues use a new "doorbell" mechanism instead of the earlier kernel-managed write pointer registers. Doorbells use a separate BAR dedicated for this purpose, and pages within the doorbell aperture are mapped to userspace (each page mapped to only one user address space). Writes to the doorbell aperture are intercepted by GPU hardware, allowing userspace code to safely manage work queues (rings) without requiring a kernel call for every ring update.
First step for an application process is to open the kfd device. Calls to open create a kfd "process" structure only for the first thread of the process. Subsequent open calls are checked to see if they are from processes using the same mm_struct and, if so, don't do anything. The kfd per-process data lives as long as the mm_struct exists. Each mm_struct is associated with a unique PASID, allowing the IOMMUv2 to make userspace process memory accessible to the GPU.
Next step is for the application to collect topology information via sysfs. This gives userspace enough information to be able to identify specific nodes (processors) in subsequent queue management calls. Application processes can create queues on multiple processors, and processors support queues from multiple processes.
At this point the application can create work queues in userspace memory and pass them through the usermode library to kfd to have them mapped onto HW queue slots so that commands written to the queues can be executed by the GPU. Queue operations specify a processor node, and so the bulk of this code is device-specific.
Written by John Bridgman <[email protected]>

Alexey Skidanov (1):
amdkfd: Implement the Get Process Aperture IOCTL

Andrew Lewycky (3):
amdkfd: Add basic modules to amdkfd
amdkfd: Add interrupt handling module
amdkfd: Implement the Set Memory Policy IOCTL

Ben Goz (8):
amdkfd: Add queue module
amdkfd: Add mqd_manager module
amdkfd: Add kernel queue module
amdkfd: Add module parameter of scheduling policy
amdkfd: Add packet manager module
amdkfd: Add process queue manager module
amdkfd: Add device queue manager module
amdkfd: Implement the create/destroy/update queue IOCTLs

Evgeny Pinchuk (3):
amdkfd: Add topology module to amdkfd
amdkfd: Implement the Get Clock Counters IOCTL
amdkfd: Implement the PMC Acquire/Release IOCTLs

Oded Gabbay (10):
mm: Add kfd_process pointer to mm_struct drm/radeon: reduce number of free VMIDs and pipes in KV drm/radeon/cik: Don't touch int of pipes 1-7 drm/radeon: Report doorbell configuration to amdkfd drm/radeon: adding synchronization for GRBM GFX drm/radeon: Add radeon <--> amdkfd interface Update MAINTAINERS and CREDITS files with amdkfd info
amdkfd: Add IOCTL set definitions of amdkfd
amdkfd: Add amdkfd skeleton driver
amdkfd: Add binding/unbinding calls to amd_iommu driver

  CREDITS                                            |    7 +
  MAINTAINERS                                        |   10 +
  drivers/gpu/drm/radeon/Kconfig                     |    2 +
  drivers/gpu/drm/radeon/Makefile                    |    3 +
  drivers/gpu/drm/radeon/amdkfd/Kconfig              |   10 +
  drivers/gpu/drm/radeon/amdkfd/Makefile             |   14 +
  drivers/gpu/drm/radeon/amdkfd/cik_mqds.h           |  185 +++
  drivers/gpu/drm/radeon/amdkfd/cik_regs.h           |  220 ++++
  drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c       |  123 ++
  drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c        |  518 +++++++++
  drivers/gpu/drm/radeon/amdkfd/kfd_crat.h           |  294 +++++
  drivers/gpu/drm/radeon/amdkfd/kfd_device.c         |  254 ++++
  .../drm/radeon/amdkfd/kfd_device_queue_manager.c   |  985 ++++++++++++++++
  .../drm/radeon/amdkfd/kfd_device_queue_manager.h   |  101 ++
  drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c       |  264 +++++
  drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c      |  161 +++
  drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c   |  305 +++++
  drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h   |   66 ++
  drivers/gpu/drm/radeon/amdkfd/kfd_module.c         |  131 +++
  drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c    |  291 +++++
  drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h    |   54 +
  drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c |  488 ++++++++
  drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c          |   97 ++
  drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h    |  682 +++++++++++
  drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h    |  107 ++
  drivers/gpu/drm/radeon/amdkfd/kfd_priv.h           |  466 ++++++++
  drivers/gpu/drm/radeon/amdkfd/kfd_process.c        |  405 +++++++
  .../drm/radeon/amdkfd/kfd_process_queue_manager.c  |  343 ++++++
  drivers/gpu/drm/radeon/amdkfd/kfd_queue.c          |  109 ++
  drivers/gpu/drm/radeon/amdkfd/kfd_topology.c       | 1207
++++++++++++++++++++
  drivers/gpu/drm/radeon/amdkfd/kfd_topology.h       |  168 +++
  drivers/gpu/drm/radeon/amdkfd/kfd_vidmem.c         |   96 ++
  drivers/gpu/drm/radeon/cik.c                       |  154 +--
  drivers/gpu/drm/radeon/cik_reg.h                   |   65 ++
  drivers/gpu/drm/radeon/cikd.h                      |   51 +-
  drivers/gpu/drm/radeon/radeon.h                    |    9 +
  drivers/gpu/drm/radeon/radeon_device.c             |   32 +
  drivers/gpu/drm/radeon/radeon_drv.c                |    5 +
  drivers/gpu/drm/radeon/radeon_kfd.c                |  566 +++++++++
  drivers/gpu/drm/radeon/radeon_kfd.h                |  119 ++
  drivers/gpu/drm/radeon/radeon_kms.c                |    7 +
  include/linux/mm_types.h                           |   14 +
  include/uapi/linux/kfd_ioctl.h                     |  133 +++
  43 files changed, 9226 insertions(+), 95 deletions(-)

create mode 100644 drivers/gpu/drm/radeon/amdkfd/Kconfig
create mode 100644 drivers/gpu/drm/radeon/amdkfd/Makefile create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_mqds.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_regs.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_crat.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_module.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process_queue_manager.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_queue.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.c create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.h create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_vidmem.c create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.c
create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.h
create mode 100644 include/uapi/linux/kfd_ioctl.h

Quoted 4 lines

Quoted 3 lines

Quoted 3 lines

--
1.9.1

Quoted 62 lines · Christian König

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 44 lines · Jerome Glisse

Quoted 25 lines · Oded Gabbay

Quoted 24 lines

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them are modifications to radeon driver and 18 of them include only amdkfd code. There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under drm/radeon/amdkfd. This move was done to emphasize the fact that this driver is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point is the radeon driver. Having said that, we will probably need to move it (maybe to be directly under drm) after we integrate with additional AMD gfx drivers.

Quoted 8 lines

Quoted 4 lines

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

So quick comments on some of your questions but first of all, thanks for the time you dedicated to review the code.

Quoted 4 lines

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

We only do gpu memory pinning for kernel objects. There are no userspace objects that are pinned on the gpu memory in our driver. If that is the case, is it still a show stopper ?

Quoted 9 lines

The kernel objects are:
- pipelines (4 per device)
- mqd per hiq (only 1 per device)
- mqd per userspace queue. On KV, we support up to 1K queues per process, for a total of 512K queues. Each mqd is 151 bytes, but the allocation is done in 256 alignment. So total *possible* memory is 128MB
- kernel queue (only 1 per device)
- fence address for kernel queue
- runlists for the CP (1 or 2 per device)

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Quoted 1 line

Christian.

Most of the pin downs are done on device initialization.
The "mqd per userspace" is done per userspace queue creation. However, as I said, it has an upper limit of 128MB on KV, and considering the 2G local memory, I think it is OK.
The runlists are also done on userspace queue creation/deletion, but we only have 1 or 2 runlists per device, so it is not that bad.

Oded

Quoted 24 lines

Quoted 24 lines

Quoted 15 lines

It might be better to add a drivers/gpu/drm/amd directory and add common stuff there.

Given that this is not intended to be final HSA api AFAICT then i would say this far better to avoid the whole kfd module and add ioctl to radeon. This would avoid crazy communication btw radeon and kfd.

The whole aperture business needs some serious explanation. Especialy as you want to use userspace address there is nothing to prevent userspace program from allocating things at address you reserve for lds, scratch, ... only sane way would be to move those lds, scratch inside the virtual address reserved for kernel (see kernel memory map).

Quoted 3 lines

The whole business of locking performance counter for exclusive per process access is a big NO. Which leads me to the questionable usefullness of user space command ring.

That's like saying: "Which leads me to the questionable usefulness of HSA". I find it analogous to a situation where a network maintainer nacking a driver for a network card, which is slower than a different network card. Doesn't seem reasonable this situation is would happen. He would still put both the drivers in the kernel because people want to use the H/W and its features. So, I don't think this is a valid reason to NACK the driver.

Quoted 10 lines

Quoted 10 lines

Quoted 7 lines

I only see issues with that. First and foremost i would
need to see solid figures that kernel ioctl or syscall has a higher an overhead that is measurable in any meaning full way against a simple function call. I know the userspace command ring is a big marketing features that please ignorant userspace programmer. But really this only brings issues and for absolutely not upside afaict.

Really ? You think that doing a context switch to kernel space, with all its overhead, is _not_ more expansive than just calling a function in userspace which only puts a buffer on a ring and writes a doorbell ?

Quoted 233 lines

Quoted 232 lines

Quoted 231 lines

So i would rather see a very simple ioctl that write the doorbell and might do more than that in case of ring/queue overcommit where it would first have to wait for a free ring/queue to schedule stuff. This would also allow sane implementation of things like performance counter that could be acquire by kernel for duration of a job submitted by userspace. While still not optimal this would be better that userspace locking.

I might have more thoughts once i am done with all the patches.

Cheers,
Jérôme

Quoted 217 lines

Original Cover Letter:

This patch set implements a Heterogeneous System Architecture (HSA) driver for radeon-family GPUs.
HSA allows different processor types (CPUs, DSPs, GPUs, etc..) to share system resources more effectively via HW features including shared pageable memory, userspace-accessible work queues, and platform-level atomics. In addition to the memory protection mechanisms in GPUVM and IOMMUv2, the Sea Islands family of GPUs also performs HW-level validation of commands passed in through the queues (aka rings).

The code in this patch set is intended to serve both as a sample driver for other HSA-compatible hardware devices and as a production driver for radeon-family processors. The code is architected to support multiple CPUs each with connected GPUs, although the current implementation focuses on a single Kaveri/Berlin APU, and works alongside the existing radeon kernel graphics driver (kgd).
AMD GPUs designed for use with HSA (Sea Islands and up) share some hardware functionality between HSA compute and regular gfx/compute (memory, interrupts, registers), while other functionality has been added specifically for HSA compute (hw scheduler for virtualized compute rings). All shared hardware is owned by the radeon graphics driver, and an interface between kfd and kgd allows the kfd to make use of those shared resources, while HSA-specific functionality is managed directly by kfd by submitting packets into an HSA-specific command queue (the "HIQ").

During kfd module initialization a char device node (/dev/kfd) is created (surviving until module exit), with ioctls for queue creation & management, and data structures are initialized for managing HSA device topology. The rest of the initialization is driven by calls from the radeon kgd at the following points :

- radeon_init (kfd_init)
- radeon_exit (kfd_fini)
- radeon_driver_load_kms (kfd_device_probe, kfd_device_init)
- radeon_driver_unload_kms (kfd_device_fini)

During the probe and init processing per-device data structures are established which connect to the associated graphics kernel driver. This information is exposed to userspace via sysfs, along with a version number allowing userspace to determine if a topology change has occurred while it was reading from sysfs.
The interface between kfd and kgd also allows the kfd to request buffer management services from kgd, and allows kgd to route interrupt requests to kfd code since the interrupt block is shared between regular graphics/compute and HSA compute subsystems in the GPU.

The kfd code works with an open source usermode library ("libhsakmt") which is in the final stages of IP review and should be published in a separate repo over the next few days.
The code operates in one of three modes, selectable via the sched_policy module parameter :

- sched_policy=0 uses a hardware scheduler running in the MEC block within CP, and allows oversubscription (more queues than HW slots)
- sched_policy=1 also uses HW scheduling but does not allow oversubscription, so create_queue requests fail when we run out of HW slots
- sched_policy=2 does not use HW scheduling, so the driver manually assigns queues to HW slots by programming registers

The "no HW scheduling" option is for debug & new hardware bringup only, so has less test coverage than the other options. Default in the current code is "HW scheduling without oversubscription" since that is where we have the most test coverage but we expect to change the default to "HW scheduling with oversubscription" after further testing. This effectively removes the HW limit on the number of work queues available to applications.

Programs running on the GPU are associated with an address space through the VMID field, which is translated to a unique PASID at access time via a set of 16 VMID-to-PASID mapping registers. The available VMIDs (currently 16) are partitioned (under control of the radeon kgd) between current gfx/compute and HSA compute, with each getting 8 in the current code. The VMID-to-PASID mapping registers are updated by the HW scheduler when used, and by driver code if HW scheduling is not being used.
The Sea Islands compute queues use a new "doorbell" mechanism instead of the earlier kernel-managed write pointer registers. Doorbells use a separate BAR dedicated for this purpose, and pages within the doorbell aperture are mapped to userspace (each page mapped to only one user address space). Writes to the doorbell aperture are intercepted by GPU hardware, allowing userspace code to safely manage work queues (rings) without requiring a kernel call for every ring update.
First step for an application process is to open the kfd device. Calls to open create a kfd "process" structure only for the first thread of the process. Subsequent open calls are checked to see if they are from processes using the same mm_struct and, if so, don't do anything. The kfd per-process data lives as long as the mm_struct exists. Each mm_struct is associated with a unique PASID, allowing the IOMMUv2 to make userspace process memory accessible to the GPU.
Next step is for the application to collect topology information via sysfs. This gives userspace enough information to be able to identify specific nodes (processors) in subsequent queue management calls. Application processes can create queues on multiple processors, and processors support queues from multiple processes.
At this point the application can create work queues in userspace memory and pass them through the usermode library to kfd to have them mapped onto HW queue slots so that commands written to the queues can be executed by the GPU. Queue operations specify a processor node, and so the bulk of this code is device-specific.
Written by John Bridgman <[email protected]>

Alexey Skidanov (1):
amdkfd: Implement the Get Process Aperture IOCTL

Andrew Lewycky (3):
amdkfd: Add basic modules to amdkfd
amdkfd: Add interrupt handling module
amdkfd: Implement the Set Memory Policy IOCTL

Ben Goz (8):
amdkfd: Add queue module
amdkfd: Add mqd_manager module
amdkfd: Add kernel queue module
amdkfd: Add module parameter of scheduling policy
amdkfd: Add packet manager module
amdkfd: Add process queue manager module
amdkfd: Add device queue manager module
amdkfd: Implement the create/destroy/update queue IOCTLs

Evgeny Pinchuk (3):
amdkfd: Add topology module to amdkfd
amdkfd: Implement the Get Clock Counters IOCTL
amdkfd: Implement the PMC Acquire/Release IOCTLs

Oded Gabbay (10):
mm: Add kfd_process pointer to mm_struct drm/radeon: reduce number of free VMIDs and pipes in KV drm/radeon/cik: Don't touch int of pipes 1-7 drm/radeon: Report doorbell configuration to amdkfd drm/radeon: adding synchronization for GRBM GFX drm/radeon: Add radeon <--> amdkfd interface Update MAINTAINERS and CREDITS files with amdkfd info
amdkfd: Add IOCTL set definitions of amdkfd
amdkfd: Add amdkfd skeleton driver
amdkfd: Add binding/unbinding calls to amd_iommu driver

 CREDITS                                            |    7 +
 MAINTAINERS                                        |   10 +
 drivers/gpu/drm/radeon/Kconfig                     |    2 +
 drivers/gpu/drm/radeon/Makefile                    |    3 +
 drivers/gpu/drm/radeon/amdkfd/Kconfig              |   10 +
 drivers/gpu/drm/radeon/amdkfd/Makefile             |   14 +
 drivers/gpu/drm/radeon/amdkfd/cik_mqds.h           |  185 +++
 drivers/gpu/drm/radeon/amdkfd/cik_regs.h           |  220 ++++
 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c       |  123 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c        |  518 +++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_crat.h           |  294 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_device.c         |  254 ++++
 .../drm/radeon/amdkfd/kfd_device_queue_manager.c   |  985 ++++++++++++++++
 .../drm/radeon/amdkfd/kfd_device_queue_manager.h   |  101 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c       |  264 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c      |  161 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c   |  305 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h   |   66 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_module.c         |  131 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c    |  291 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h    |   54 +
 drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c |  488 ++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c          |   97 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h    |  682 +++++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h    |  107 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h           |  466 ++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_process.c        |  405 +++++++
 .../drm/radeon/amdkfd/kfd_process_queue_manager.c  |  343 ++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_queue.c          |  109 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_topology.c       | 1207
++++++++++++++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_topology.h       |  168 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_vidmem.c         |   96 ++
 drivers/gpu/drm/radeon/cik.c                       |  154 +--
 drivers/gpu/drm/radeon/cik_reg.h                   |   65 ++
 drivers/gpu/drm/radeon/cikd.h                      |   51 +-
 drivers/gpu/drm/radeon/radeon.h                    |    9 +
 drivers/gpu/drm/radeon/radeon_device.c             |   32 +
 drivers/gpu/drm/radeon/radeon_drv.c                |    5 +
 drivers/gpu/drm/radeon/radeon_kfd.c                |  566 +++++++++
 drivers/gpu/drm/radeon/radeon_kfd.h                |  119 ++
 drivers/gpu/drm/radeon/radeon_kms.c                |    7 +
 include/linux/mm_types.h                           |   14 +
 include/uapi/linux/kfd_ioctl.h                     |  133 +++
 43 files changed, 9226 insertions(+), 95 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/Kconfig
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/Makefile
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_mqds.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_regs.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_crat.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_module.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process_queue_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_queue.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_vidmem.c
 create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.c
 create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.h
 create mode 100644 include/uapi/linux/kfd_ioctl.h

--
1.9.1

Quoted 63 lines · Oded Gabbay

Quoted 62 lines · Christian König

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 44 lines · Jerome Glisse

Quoted 25 lines · Oded Gabbay

Quoted 24 lines

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them are modifications to radeon driver and 18 of them include only amdkfd code. There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under drm/radeon/amdkfd. This move was done to emphasize the fact that this driver is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point is the radeon driver. Having said that, we will probably need to move it (maybe to be directly under drm) after we integrate with additional AMD gfx drivers.

Quoted 8 lines

Quoted 4 lines

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

So quick comments on some of your questions but first of all, thanks for the time you dedicated to review the code.

Quoted 4 lines

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

We only do gpu memory pinning for kernel objects. There are no userspace objects that are pinned on the gpu memory in our driver. If that is the case, is it still a show stopper ?

Quoted 9 lines

The kernel objects are:
- pipelines (4 per device)
- mqd per hiq (only 1 per device)
- mqd per userspace queue. On KV, we support up to 1K queues per process, for a total of 512K queues. Each mqd is 151 bytes, but the allocation is done in 256 alignment. So total *possible* memory is 128MB
- kernel queue (only 1 per device)
- fence address for kernel queue
- runlists for the CP (1 or 2 per device)

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Quoted 8 lines

Quoted 1 line

Christian.

Most of the pin downs are done on device initialization.
The "mqd per userspace" is done per userspace queue creation. However, as I said, it has an upper limit of 128MB on KV, and considering the 2G local memory, I think it is OK.
The runlists are also done on userspace queue creation/deletion, but we only have 1 or 2 runlists per device, so it is not that bad.

2G local memory ? You can not assume anything on userside configuration some one might build an hsa computer with 512M and still expect a functioning desktop.

I need to go look into what all this mqd is for, what it does and what it is about. But pinning is really bad and this is an issue with userspace command scheduling an issue that obviously AMD fails to take into account in design phase.

Quoted 26 lines

Oded

Quoted 24 lines

Quoted 24 lines

Quoted 15 lines

It might be better to add a drivers/gpu/drm/amd directory and add common stuff there.

Given that this is not intended to be final HSA api AFAICT then i would say this far better to avoid the whole kfd module and add ioctl to radeon. This would avoid crazy communication btw radeon and kfd.

The whole aperture business needs some serious explanation. Especialy as you want to use userspace address there is nothing to prevent userspace program from allocating things at address you reserve for lds, scratch, ... only sane way would be to move those lds, scratch inside the virtual address reserved for kernel (see kernel memory map).

Quoted 3 lines

The whole business of locking performance counter for exclusive per process access is a big NO. Which leads me to the questionable usefullness of user space command ring.

That's like saying: "Which leads me to the questionable usefulness of HSA". I find it analogous to a situation where a network maintainer nacking a driver for a network card, which is slower than a different network card. Doesn't seem reasonable this situation is would happen. He would still put both the drivers in the kernel because people want to use the H/W and its features. So, I don't think this is a valid reason to NACK the driver.

Let me rephrase, drop the the performance counter ioctl and modulo memory pinning i see no objection. In other word, i am not NACKING whole patchset i am NACKING the performance ioctl.

Again this is another argument for round trip to the kernel. As inside kernel you could properly do exclusive gpu counter access accross single user cmd buffer execution.

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 7 lines

I only see issues with that. First and foremost i would
need to see solid figures that kernel ioctl or syscall has a higher an overhead that is measurable in any meaning full way against a simple function call. I know the userspace command ring is a big marketing features that please ignorant userspace programmer. But really this only brings issues and for absolutely not upside afaict.

Really ? You think that doing a context switch to kernel space, with all its overhead, is _not_ more expansive than just calling a function in userspace which only puts a buffer on a ring and writes a doorbell ?

I am saying the overhead is not that big and it probably will not matter in most usecase. For instance i did wrote the most useless kernel module that add two number through an ioctl (http://people.freedesktop.org/~glisse/adder.tar) and it takes ~0.35microseconds with ioctl while function is ~0.025microseconds so ioctl is 13 times slower.

Now if there is enough data that shows that a significant percentage of jobs submited to the GPU will take less that 0.35microsecond then yes userspace scheduling does make sense. But so far all we have is handwaving with no data to support any facts.

Now if we want to schedule from userspace than you will need to do something about the pinning, something that gives control to kernel so that kernel can unpin when it wants and move object when it wants no matter what userspace is doing.

Quoted 234 lines

Quoted 233 lines

Quoted 232 lines

Quoted 231 lines

So i would rather see a very simple ioctl that write the doorbell and might do more than that in case of ring/queue overcommit where it would first have to wait for a free ring/queue to schedule stuff. This would also allow sane implementation of things like performance counter that could be acquire by kernel for duration of a job submitted by userspace. While still not optimal this would be better that userspace locking.

I might have more thoughts once i am done with all the patches.

Cheers,
Jérôme

Quoted 217 lines

Original Cover Letter:

This patch set implements a Heterogeneous System Architecture (HSA) driver for radeon-family GPUs.
HSA allows different processor types (CPUs, DSPs, GPUs, etc..) to share system resources more effectively via HW features including shared pageable memory, userspace-accessible work queues, and platform-level atomics. In addition to the memory protection mechanisms in GPUVM and IOMMUv2, the Sea Islands family of GPUs also performs HW-level validation of commands passed in through the queues (aka rings).

The code in this patch set is intended to serve both as a sample driver for other HSA-compatible hardware devices and as a production driver for radeon-family processors. The code is architected to support multiple CPUs each with connected GPUs, although the current implementation focuses on a single Kaveri/Berlin APU, and works alongside the existing radeon kernel graphics driver (kgd).
AMD GPUs designed for use with HSA (Sea Islands and up) share some hardware functionality between HSA compute and regular gfx/compute (memory, interrupts, registers), while other functionality has been added specifically for HSA compute (hw scheduler for virtualized compute rings). All shared hardware is owned by the radeon graphics driver, and an interface between kfd and kgd allows the kfd to make use of those shared resources, while HSA-specific functionality is managed directly by kfd by submitting packets into an HSA-specific command queue (the "HIQ").

During kfd module initialization a char device node (/dev/kfd) is created (surviving until module exit), with ioctls for queue creation & management, and data structures are initialized for managing HSA device topology. The rest of the initialization is driven by calls from the radeon kgd at the following points :

- radeon_init (kfd_init)
- radeon_exit (kfd_fini)
- radeon_driver_load_kms (kfd_device_probe, kfd_device_init)
- radeon_driver_unload_kms (kfd_device_fini)

During the probe and init processing per-device data structures are established which connect to the associated graphics kernel driver. This information is exposed to userspace via sysfs, along with a version number allowing userspace to determine if a topology change has occurred while it was reading from sysfs.
The interface between kfd and kgd also allows the kfd to request buffer management services from kgd, and allows kgd to route interrupt requests to kfd code since the interrupt block is shared between regular graphics/compute and HSA compute subsystems in the GPU.

The kfd code works with an open source usermode library ("libhsakmt") which is in the final stages of IP review and should be published in a separate repo over the next few days.
The code operates in one of three modes, selectable via the sched_policy module parameter :

- sched_policy=0 uses a hardware scheduler running in the MEC block within CP, and allows oversubscription (more queues than HW slots)
- sched_policy=1 also uses HW scheduling but does not allow oversubscription, so create_queue requests fail when we run out of HW slots
- sched_policy=2 does not use HW scheduling, so the driver manually assigns queues to HW slots by programming registers

The "no HW scheduling" option is for debug & new hardware bringup only, so has less test coverage than the other options. Default in the current code is "HW scheduling without oversubscription" since that is where we have the most test coverage but we expect to change the default to "HW scheduling with oversubscription" after further testing. This effectively removes the HW limit on the number of work queues available to applications.

Programs running on the GPU are associated with an address space through the VMID field, which is translated to a unique PASID at access time via a set of 16 VMID-to-PASID mapping registers. The available VMIDs (currently 16) are partitioned (under control of the radeon kgd) between current gfx/compute and HSA compute, with each getting 8 in the current code. The VMID-to-PASID mapping registers are updated by the HW scheduler when used, and by driver code if HW scheduling is not being used.
The Sea Islands compute queues use a new "doorbell" mechanism instead of the earlier kernel-managed write pointer registers. Doorbells use a separate BAR dedicated for this purpose, and pages within the doorbell aperture are mapped to userspace (each page mapped to only one user address space). Writes to the doorbell aperture are intercepted by GPU hardware, allowing userspace code to safely manage work queues (rings) without requiring a kernel call for every ring update.
First step for an application process is to open the kfd device. Calls to open create a kfd "process" structure only for the first thread of the process. Subsequent open calls are checked to see if they are from processes using the same mm_struct and, if so, don't do anything. The kfd per-process data lives as long as the mm_struct exists. Each mm_struct is associated with a unique PASID, allowing the IOMMUv2 to make userspace process memory accessible to the GPU.
Next step is for the application to collect topology information via sysfs. This gives userspace enough information to be able to identify specific nodes (processors) in subsequent queue management calls. Application processes can create queues on multiple processors, and processors support queues from multiple processes.
At this point the application can create work queues in userspace memory and pass them through the usermode library to kfd to have them mapped onto HW queue slots so that commands written to the queues can be executed by the GPU. Queue operations specify a processor node, and so the bulk of this code is device-specific.
Written by John Bridgman <[email protected]>

Alexey Skidanov (1):
amdkfd: Implement the Get Process Aperture IOCTL

Andrew Lewycky (3):
amdkfd: Add basic modules to amdkfd
amdkfd: Add interrupt handling module
amdkfd: Implement the Set Memory Policy IOCTL

Ben Goz (8):
amdkfd: Add queue module
amdkfd: Add mqd_manager module
amdkfd: Add kernel queue module
amdkfd: Add module parameter of scheduling policy
amdkfd: Add packet manager module
amdkfd: Add process queue manager module
amdkfd: Add device queue manager module
amdkfd: Implement the create/destroy/update queue IOCTLs

Evgeny Pinchuk (3):
amdkfd: Add topology module to amdkfd
amdkfd: Implement the Get Clock Counters IOCTL
amdkfd: Implement the PMC Acquire/Release IOCTLs

Oded Gabbay (10):
mm: Add kfd_process pointer to mm_struct drm/radeon: reduce number of free VMIDs and pipes in KV drm/radeon/cik: Don't touch int of pipes 1-7 drm/radeon: Report doorbell configuration to amdkfd drm/radeon: adding synchronization for GRBM GFX drm/radeon: Add radeon <--> amdkfd interface Update MAINTAINERS and CREDITS files with amdkfd info
amdkfd: Add IOCTL set definitions of amdkfd
amdkfd: Add amdkfd skeleton driver
amdkfd: Add binding/unbinding calls to amd_iommu driver

 CREDITS                                            |    7 +
 MAINTAINERS                                        |   10 +
 drivers/gpu/drm/radeon/Kconfig                     |    2 +
 drivers/gpu/drm/radeon/Makefile                    |    3 +
 drivers/gpu/drm/radeon/amdkfd/Kconfig              |   10 +
 drivers/gpu/drm/radeon/amdkfd/Makefile             |   14 +
 drivers/gpu/drm/radeon/amdkfd/cik_mqds.h           |  185 +++
 drivers/gpu/drm/radeon/amdkfd/cik_regs.h           |  220 ++++
 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c       |  123 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c        |  518 +++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_crat.h           |  294 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_device.c         |  254 ++++
 .../drm/radeon/amdkfd/kfd_device_queue_manager.c   |  985 ++++++++++++++++
 .../drm/radeon/amdkfd/kfd_device_queue_manager.h   |  101 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c       |  264 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c      |  161 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c   |  305 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h   |   66 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_module.c         |  131 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c    |  291 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h    |   54 +
 drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c |  488 ++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c          |   97 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h    |  682 +++++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h    |  107 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h           |  466 ++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_process.c        |  405 +++++++
 .../drm/radeon/amdkfd/kfd_process_queue_manager.c  |  343 ++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_queue.c          |  109 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_topology.c       | 1207
++++++++++++++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_topology.h       |  168 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_vidmem.c         |   96 ++
 drivers/gpu/drm/radeon/cik.c                       |  154 +--
 drivers/gpu/drm/radeon/cik_reg.h                   |   65 ++
 drivers/gpu/drm/radeon/cikd.h                      |   51 +-
 drivers/gpu/drm/radeon/radeon.h                    |    9 +
 drivers/gpu/drm/radeon/radeon_device.c             |   32 +
 drivers/gpu/drm/radeon/radeon_drv.c                |    5 +
 drivers/gpu/drm/radeon/radeon_kfd.c                |  566 +++++++++
 drivers/gpu/drm/radeon/radeon_kfd.h                |  119 ++
 drivers/gpu/drm/radeon/radeon_kms.c                |    7 +
 include/linux/mm_types.h                           |   14 +
 include/uapi/linux/kfd_ioctl.h                     |  133 +++
 43 files changed, 9226 insertions(+), 95 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/Kconfig
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/Makefile
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_mqds.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_regs.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_crat.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_module.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process_queue_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_queue.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_vidmem.c
 create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.c
 create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.h
 create mode 100644 include/uapi/linux/kfd_ioctl.h

--
1.9.1

Quoted 73 lines · Jerome Glisse

Quoted 63 lines · Oded Gabbay

Quoted 62 lines · Christian König

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 44 lines · Jerome Glisse

Quoted 25 lines · Oded Gabbay

Quoted 24 lines

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them are modifications to radeon driver and 18 of them include only amdkfd code. There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under drm/radeon/amdkfd. This move was done to emphasize the fact that this driver is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point is the radeon driver. Having said that, we will probably need to move it (maybe to be directly under drm) after we integrate with additional AMD gfx drivers.

Quoted 8 lines

Quoted 4 lines

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

So quick comments on some of your questions but first of all, thanks for the time you dedicated to review the code.

Quoted 4 lines

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

We only do gpu memory pinning for kernel objects. There are no userspace objects that are pinned on the gpu memory in our driver. If that is the case, is it still a show stopper ?

Quoted 9 lines

The kernel objects are:
- pipelines (4 per device)
- mqd per hiq (only 1 per device)
- mqd per userspace queue. On KV, we support up to 1K queues per process, for a total of 512K queues. Each mqd is 151 bytes, but the allocation is done in 256 alignment. So total *possible* memory is 128MB
- kernel queue (only 1 per device)
- fence address for kernel queue
- runlists for the CP (1 or 2 per device)

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Quoted 8 lines

Quoted 1 line

Christian.

Most of the pin downs are done on device initialization.
The "mqd per userspace" is done per userspace queue creation. However, as I said, it has an upper limit of 128MB on KV, and considering the 2G local memory, I think it is OK.
The runlists are also done on userspace queue creation/deletion, but we only have 1 or 2 runlists per device, so it is not that bad.

Quoted 3 lines

2G local memory ? You can not assume anything on userside configuration some one might build an hsa computer with 512M and still expect a functioning desktop.

First of all, I'm only considering Kaveri computer, not "hsa" computer. Second, I would imagine we can build some protection around it, like checking total local memory and limit number of queues based on some percentage of that total local memory. So, if someone will have only 512M, he will be able to open less queues.

Quoted 1 line

Quoted 4 lines

I need to go look into what all this mqd is for, what it does and what it is about. But pinning is really bad and this is an issue with userspace command scheduling an issue that obviously AMD fails to take into account in design phase.

Maybe, but that is the H/W design non-the-less. We can't very well change the H/W.

Quoted 289 lines

Quoted 18 lines

Quoted 18 lines

Quoted 18 lines

Quoted 18 lines

It might be better to add a drivers/gpu/drm/amd directory and add common stuff there.

Given that this is not intended to be final HSA api AFAICT then i would say this far better to avoid the whole kfd module and add ioctl to radeon. This would avoid crazy communication btw radeon and kfd.

The whole aperture business needs some serious explanation. Especialy as you want to use userspace address there is nothing to prevent userspace program from allocating things at address you reserve for lds, scratch, ... only sane way would be to move those lds, scratch inside the virtual address reserved for kernel (see kernel memory map).

The whole business of locking performance counter for exclusive per process access is a big NO. Which leads me to the questionable usefullness of user space command ring.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

That's like saying: "Which leads me to the questionable usefulness of HSA". I find it analogous to a situation where a network maintainer nacking a driver for a network card, which is slower than a different network card. Doesn't seem reasonable this situation is would happen. He would still put both the drivers in the kernel because people want to use the H/W and its features. So, I don't think this is a valid reason to NACK the driver.

Let me rephrase, drop the the performance counter ioctl and modulo memory pinning i see no objection. In other word, i am not NACKING whole patchset i am NACKING the performance ioctl.

Again this is another argument for round trip to the kernel. As inside kernel you could properly do exclusive gpu counter access accross single user cmd buffer execution.

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 7 lines

I only see issues with that. First and foremost i would
need to see solid figures that kernel ioctl or syscall has a higher an overhead that is measurable in any meaning full way against a simple function call. I know the userspace command ring is a big marketing features that please ignorant userspace programmer. But really this only brings issues and for absolutely not upside afaict.

Really ? You think that doing a context switch to kernel space, with all its overhead, is _not_ more expansive than just calling a function in userspace which only puts a buffer on a ring and writes a doorbell ?

I am saying the overhead is not that big and it probably will not matter in most usecase. For instance i did wrote the most useless kernel module that add two number through an ioctl (http://people.freedesktop.org/~glisse/adder.tar) and it takes ~0.35microseconds with ioctl while function is ~0.025microseconds so ioctl is 13 times slower.

Now if there is enough data that shows that a significant percentage of jobs submited to the GPU will take less that 0.35microsecond then yes userspace scheduling does make sense. But so far all we have is handwaving with no data to support any facts.

Now if we want to schedule from userspace than you will need to do something about the pinning, something that gives control to kernel so that kernel can unpin when it wants and move object when it wants no matter what userspace is doing.

Quoted 228 lines

Quoted 228 lines

Quoted 228 lines

Quoted 228 lines

So i would rather see a very simple ioctl that write the doorbell and might do more than that in case of ring/queue overcommit where it would first have to wait for a free ring/queue to schedule stuff. This would also allow sane implementation of things like performance counter that could be acquire by kernel for duration of a job submitted by userspace. While still not optimal this would be better that userspace locking.

I might have more thoughts once i am done with all the patches.

Cheers,
Jérôme

Quoted 214 lines

Original Cover Letter:

This patch set implements a Heterogeneous System Architecture (HSA) driver for radeon-family GPUs.
HSA allows different processor types (CPUs, DSPs, GPUs, etc..) to share system resources more effectively via HW features including shared pageable memory, userspace-accessible work queues, and platform-level atomics. In addition to the memory protection mechanisms in GPUVM and IOMMUv2, the Sea Islands family of GPUs also performs HW-level validation of commands passed in through the queues (aka rings).

The code in this patch set is intended to serve both as a sample driver for other HSA-compatible hardware devices and as a production driver for radeon-family processors. The code is architected to support multiple CPUs each with connected GPUs, although the current implementation focuses on a single Kaveri/Berlin APU, and works alongside the existing radeon kernel graphics driver (kgd).
AMD GPUs designed for use with HSA (Sea Islands and up) share some hardware functionality between HSA compute and regular gfx/compute (memory, interrupts, registers), while other functionality has been added specifically for HSA compute (hw scheduler for virtualized compute rings). All shared hardware is owned by the radeon graphics driver, and an interface between kfd and kgd allows the kfd to make use of those shared resources, while HSA-specific functionality is managed directly by kfd by submitting packets into an HSA-specific command queue (the "HIQ").

During kfd module initialization a char device node (/dev/kfd) is created (surviving until module exit), with ioctls for queue creation & management, and data structures are initialized for managing HSA device topology. The rest of the initialization is driven by calls from the radeon kgd at the following points :

- radeon_init (kfd_init)
- radeon_exit (kfd_fini)
- radeon_driver_load_kms (kfd_device_probe, kfd_device_init)
- radeon_driver_unload_kms (kfd_device_fini)

During the probe and init processing per-device data structures are established which connect to the associated graphics kernel driver. This information is exposed to userspace via sysfs, along with a version number allowing userspace to determine if a topology change has occurred while it was reading from sysfs.
The interface between kfd and kgd also allows the kfd to request buffer management services from kgd, and allows kgd to route interrupt requests to kfd code since the interrupt block is shared between regular graphics/compute and HSA compute subsystems in the GPU.

The kfd code works with an open source usermode library ("libhsakmt") which is in the final stages of IP review and should be published in a separate repo over the next few days.
The code operates in one of three modes, selectable via the sched_policy module parameter :

- sched_policy=0 uses a hardware scheduler running in the MEC block within CP, and allows oversubscription (more queues than HW slots)
- sched_policy=1 also uses HW scheduling but does not allow oversubscription, so create_queue requests fail when we run out of HW slots
- sched_policy=2 does not use HW scheduling, so the driver manually assigns queues to HW slots by programming registers

The "no HW scheduling" option is for debug & new hardware bringup only, so has less test coverage than the other options. Default in the current code is "HW scheduling without oversubscription" since that is where we have the most test coverage but we expect to change the default to "HW scheduling with oversubscription" after further testing. This effectively removes the HW limit on the number of work queues available to applications.

Programs running on the GPU are associated with an address space through the VMID field, which is translated to a unique PASID at access time via a set of 16 VMID-to-PASID mapping registers. The available VMIDs (currently 16) are partitioned (under control of the radeon kgd) between current gfx/compute and HSA compute, with each getting 8 in the current code. The VMID-to-PASID mapping registers are updated by the HW scheduler when used, and by driver code if HW scheduling is not being used.
The Sea Islands compute queues use a new "doorbell" mechanism instead of the earlier kernel-managed write pointer registers. Doorbells use a separate BAR dedicated for this purpose, and pages within the doorbell aperture are mapped to userspace (each page mapped to only one user address space). Writes to the doorbell aperture are intercepted by GPU hardware, allowing userspace code to safely manage work queues (rings) without requiring a kernel call for every ring update.
First step for an application process is to open the kfd device. Calls to open create a kfd "process" structure only for the first thread of the process. Subsequent open calls are checked to see if they are from processes using the same mm_struct and, if so, don't do anything. The kfd per-process data lives as long as the mm_struct exists. Each mm_struct is associated with a unique PASID, allowing the IOMMUv2 to make userspace process memory accessible to the GPU.
Next step is for the application to collect topology information via sysfs. This gives userspace enough information to be able to identify specific nodes (processors) in subsequent queue management calls. Application processes can create queues on multiple processors, and processors support queues from multiple processes.
At this point the application can create work queues in userspace memory and pass them through the usermode library to kfd to have them mapped onto HW queue slots so that commands written to the queues can be executed by the GPU. Queue operations specify a processor node, and so the bulk of this code is device-specific.
Written by John Bridgman <[email protected]>

Alexey Skidanov (1):
amdkfd: Implement the Get Process Aperture IOCTL

Andrew Lewycky (3):
amdkfd: Add basic modules to amdkfd
amdkfd: Add interrupt handling module
amdkfd: Implement the Set Memory Policy IOCTL

Ben Goz (8):
amdkfd: Add queue module
amdkfd: Add mqd_manager module
amdkfd: Add kernel queue module
amdkfd: Add module parameter of scheduling policy
amdkfd: Add packet manager module
amdkfd: Add process queue manager module
amdkfd: Add device queue manager module
amdkfd: Implement the create/destroy/update queue IOCTLs

Evgeny Pinchuk (3):
amdkfd: Add topology module to amdkfd
amdkfd: Implement the Get Clock Counters IOCTL
amdkfd: Implement the PMC Acquire/Release IOCTLs

Oded Gabbay (10):
mm: Add kfd_process pointer to mm_struct drm/radeon: reduce number of free VMIDs and pipes in KV drm/radeon/cik: Don't touch int of pipes 1-7 drm/radeon: Report doorbell configuration to amdkfd drm/radeon: adding synchronization for GRBM GFX drm/radeon: Add radeon <--> amdkfd interface Update MAINTAINERS and CREDITS files with amdkfd info
amdkfd: Add IOCTL set definitions of amdkfd
amdkfd: Add amdkfd skeleton driver
amdkfd: Add binding/unbinding calls to amd_iommu driver

 CREDITS                                            |    7 +
 MAINTAINERS                                        |   10 +
 drivers/gpu/drm/radeon/Kconfig                     |    2 +
 drivers/gpu/drm/radeon/Makefile                    |    3 +
 drivers/gpu/drm/radeon/amdkfd/Kconfig              |   10 +
 drivers/gpu/drm/radeon/amdkfd/Makefile             |   14 +
 drivers/gpu/drm/radeon/amdkfd/cik_mqds.h           |  185 +++
 drivers/gpu/drm/radeon/amdkfd/cik_regs.h           |  220 ++++
 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c       |  123 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c        |  518 +++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_crat.h           |  294 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_device.c         |  254 ++++
 .../drm/radeon/amdkfd/kfd_device_queue_manager.c   |  985 ++++++++++++++++
 .../drm/radeon/amdkfd/kfd_device_queue_manager.h   |  101 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c       |  264 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c      |  161 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c   |  305 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h   |   66 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_module.c         |  131 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c    |  291 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h    |   54 +
 drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c |  488 ++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c          |   97 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h    |  682 +++++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h    |  107 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h           |  466 ++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_process.c        |  405 +++++++
 .../drm/radeon/amdkfd/kfd_process_queue_manager.c  |  343 ++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_queue.c          |  109 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_topology.c       | 1207
++++++++++++++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_topology.h       |  168 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_vidmem.c         |   96 ++
 drivers/gpu/drm/radeon/cik.c                       |  154 +--
 drivers/gpu/drm/radeon/cik_reg.h                   |   65 ++
 drivers/gpu/drm/radeon/cikd.h                      |   51 +-
 drivers/gpu/drm/radeon/radeon.h                    |    9 +
 drivers/gpu/drm/radeon/radeon_device.c             |   32 +
 drivers/gpu/drm/radeon/radeon_drv.c                |    5 +
 drivers/gpu/drm/radeon/radeon_kfd.c                |  566 +++++++++
 drivers/gpu/drm/radeon/radeon_kfd.h                |  119 ++
 drivers/gpu/drm/radeon/radeon_kms.c                |    7 +
 include/linux/mm_types.h                           |   14 +
 include/uapi/linux/kfd_ioctl.h                     |  133 +++
 43 files changed, 9226 insertions(+), 95 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/Kconfig
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/Makefile
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_mqds.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_regs.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_crat.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_module.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process_queue_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_queue.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_vidmem.c
 create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.c
 create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.h
 create mode 100644 include/uapi/linux/kfd_ioctl.h

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

Quoted 4 lines

Quoted 3 lines

Quoted 3 lines

--
1.9.1

Quoted 89 lines · Oded Gabbay

Quoted 73 lines · Jerome Glisse

Quoted 63 lines · Oded Gabbay

Quoted 62 lines · Christian König

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 44 lines · Jerome Glisse

Quoted 25 lines · Oded Gabbay

Quoted 24 lines

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them are modifications to radeon driver and 18 of them include only amdkfd code. There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under drm/radeon/amdkfd. This move was done to emphasize the fact that this driver is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point is the radeon driver. Having said that, we will probably need to move it (maybe to be directly under drm) after we integrate with additional AMD gfx drivers.

Quoted 8 lines

Quoted 4 lines

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

So quick comments on some of your questions but first of all, thanks for the time you dedicated to review the code.

Quoted 4 lines

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

We only do gpu memory pinning for kernel objects. There are no userspace objects that are pinned on the gpu memory in our driver. If that is the case, is it still a show stopper ?

Quoted 9 lines

The kernel objects are:
- pipelines (4 per device)
- mqd per hiq (only 1 per device)
- mqd per userspace queue. On KV, we support up to 1K queues per process, for a total of 512K queues. Each mqd is 151 bytes, but the allocation is done in 256 alignment. So total *possible* memory is 128MB
- kernel queue (only 1 per device)
- fence address for kernel queue
- runlists for the CP (1 or 2 per device)

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Quoted 8 lines

Quoted 1 line

Christian.

Most of the pin downs are done on device initialization.
The "mqd per userspace" is done per userspace queue creation. However, as I said, it has an upper limit of 128MB on KV, and considering the 2G local memory, I think it is OK.
The runlists are also done on userspace queue creation/deletion, but we only have 1 or 2 runlists per device, so it is not that bad.

Quoted 3 lines

2G local memory ? You can not assume anything on userside configuration some one might build an hsa computer with 512M and still expect a functioning desktop.

First of all, I'm only considering Kaveri computer, not "hsa" computer. Second, I would imagine we can build some protection around it, like checking total local memory and limit number of queues based on some percentage of that total local memory. So, if someone will have only 512M, he will be able to open less queues.

Quoted 5 lines

I need to go look into what all this mqd is for, what it does and what it is about. But pinning is really bad and this is an issue with userspace command scheduling an issue that obviously AMD fails to take into account in design phase.

Quoted 2 lines

Maybe, but that is the H/W design non-the-less. We can't very well change the H/W.

You can not change the hardware but it is not an excuse to allow bad design to sneak in software to work around that. So i would rather penalize bad hardware design and have command submission in the kernel, until AMD fix its hardware to allow proper scheduling by the kernel and proper control by the kernel.

Because really where we want to go is having GPU closer to a CPU in term of scheduling capacity and once we get there we want the kernel to always be able to take over and do whatever it wants behind process back.

Quoted 290 lines

Quoted 290 lines

Quoted 19 lines

Quoted 19 lines

Quoted 19 lines

Quoted 19 lines

It might be better to add a drivers/gpu/drm/amd directory and add common stuff there.

Given that this is not intended to be final HSA api AFAICT then i would say this far better to avoid the whole kfd module and add ioctl to radeon. This would avoid crazy communication btw radeon and kfd.

The whole aperture business needs some serious explanation. Especialy as you want to use userspace address there is nothing to prevent userspace program from allocating things at address you reserve for lds, scratch, ... only sane way would be to move those lds, scratch inside the virtual address reserved for kernel (see kernel memory map).

The whole business of locking performance counter for exclusive per process access is a big NO. Which leads me to the questionable usefullness of user space command ring.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

That's like saying: "Which leads me to the questionable usefulness of HSA". I find it analogous to a situation where a network maintainer nacking a driver for a network card, which is slower than a different network card. Doesn't seem reasonable this situation is would happen. He would still put both the drivers in the kernel because people want to use the H/W and its features. So, I don't think this is a valid reason to NACK the driver.

Let me rephrase, drop the the performance counter ioctl and modulo memory pinning i see no objection. In other word, i am not NACKING whole patchset i am NACKING the performance ioctl.

Again this is another argument for round trip to the kernel. As inside kernel you could properly do exclusive gpu counter access accross single user cmd buffer execution.

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 7 lines

I only see issues with that. First and foremost i would
need to see solid figures that kernel ioctl or syscall has a higher an overhead that is measurable in any meaning full way against a simple function call. I know the userspace command ring is a big marketing features that please ignorant userspace programmer. But really this only brings issues and for absolutely not upside afaict.

Really ? You think that doing a context switch to kernel space, with all its overhead, is _not_ more expansive than just calling a function in userspace which only puts a buffer on a ring and writes a doorbell ?

I am saying the overhead is not that big and it probably will not matter in most usecase. For instance i did wrote the most useless kernel module that add two number through an ioctl (http://people.freedesktop.org/~glisse/adder.tar) and it takes ~0.35microseconds with ioctl while function is ~0.025microseconds so ioctl is 13 times slower.

Now if there is enough data that shows that a significant percentage of jobs submited to the GPU will take less that 0.35microsecond then yes userspace scheduling does make sense. But so far all we have is handwaving with no data to support any facts.

Now if we want to schedule from userspace than you will need to do something about the pinning, something that gives control to kernel so that kernel can unpin when it wants and move object when it wants no matter what userspace is doing.

Quoted 228 lines

Quoted 228 lines

Quoted 228 lines

Quoted 228 lines

So i would rather see a very simple ioctl that write the doorbell and might do more than that in case of ring/queue overcommit where it would first have to wait for a free ring/queue to schedule stuff. This would also allow sane implementation of things like performance counter that could be acquire by kernel for duration of a job submitted by userspace. While still not optimal this would be better that userspace locking.

I might have more thoughts once i am done with all the patches.

Cheers,
Jérôme

Quoted 214 lines

Original Cover Letter:

This patch set implements a Heterogeneous System Architecture (HSA) driver for radeon-family GPUs.
HSA allows different processor types (CPUs, DSPs, GPUs, etc..) to share system resources more effectively via HW features including shared pageable memory, userspace-accessible work queues, and platform-level atomics. In addition to the memory protection mechanisms in GPUVM and IOMMUv2, the Sea Islands family of GPUs also performs HW-level validation of commands passed in through the queues (aka rings).

The code in this patch set is intended to serve both as a sample driver for other HSA-compatible hardware devices and as a production driver for radeon-family processors. The code is architected to support multiple CPUs each with connected GPUs, although the current implementation focuses on a single Kaveri/Berlin APU, and works alongside the existing radeon kernel graphics driver (kgd).
AMD GPUs designed for use with HSA (Sea Islands and up) share some hardware functionality between HSA compute and regular gfx/compute (memory, interrupts, registers), while other functionality has been added specifically for HSA compute (hw scheduler for virtualized compute rings). All shared hardware is owned by the radeon graphics driver, and an interface between kfd and kgd allows the kfd to make use of those shared resources, while HSA-specific functionality is managed directly by kfd by submitting packets into an HSA-specific command queue (the "HIQ").

During kfd module initialization a char device node (/dev/kfd) is created (surviving until module exit), with ioctls for queue creation & management, and data structures are initialized for managing HSA device topology. The rest of the initialization is driven by calls from the radeon kgd at the following points :

- radeon_init (kfd_init)
- radeon_exit (kfd_fini)
- radeon_driver_load_kms (kfd_device_probe, kfd_device_init)
- radeon_driver_unload_kms (kfd_device_fini)

During the probe and init processing per-device data structures are established which connect to the associated graphics kernel driver. This information is exposed to userspace via sysfs, along with a version number allowing userspace to determine if a topology change has occurred while it was reading from sysfs.
The interface between kfd and kgd also allows the kfd to request buffer management services from kgd, and allows kgd to route interrupt requests to kfd code since the interrupt block is shared between regular graphics/compute and HSA compute subsystems in the GPU.

The kfd code works with an open source usermode library ("libhsakmt") which is in the final stages of IP review and should be published in a separate repo over the next few days.
The code operates in one of three modes, selectable via the sched_policy module parameter :

- sched_policy=0 uses a hardware scheduler running in the MEC block within CP, and allows oversubscription (more queues than HW slots)
- sched_policy=1 also uses HW scheduling but does not allow oversubscription, so create_queue requests fail when we run out of HW slots
- sched_policy=2 does not use HW scheduling, so the driver manually assigns queues to HW slots by programming registers

The "no HW scheduling" option is for debug & new hardware bringup only, so has less test coverage than the other options. Default in the current code is "HW scheduling without oversubscription" since that is where we have the most test coverage but we expect to change the default to "HW scheduling with oversubscription" after further testing. This effectively removes the HW limit on the number of work queues available to applications.

Programs running on the GPU are associated with an address space through the VMID field, which is translated to a unique PASID at access time via a set of 16 VMID-to-PASID mapping registers. The available VMIDs (currently 16) are partitioned (under control of the radeon kgd) between current gfx/compute and HSA compute, with each getting 8 in the current code. The VMID-to-PASID mapping registers are updated by the HW scheduler when used, and by driver code if HW scheduling is not being used.
The Sea Islands compute queues use a new "doorbell" mechanism instead of the earlier kernel-managed write pointer registers. Doorbells use a separate BAR dedicated for this purpose, and pages within the doorbell aperture are mapped to userspace (each page mapped to only one user address space). Writes to the doorbell aperture are intercepted by GPU hardware, allowing userspace code to safely manage work queues (rings) without requiring a kernel call for every ring update.
First step for an application process is to open the kfd device. Calls to open create a kfd "process" structure only for the first thread of the process. Subsequent open calls are checked to see if they are from processes using the same mm_struct and, if so, don't do anything. The kfd per-process data lives as long as the mm_struct exists. Each mm_struct is associated with a unique PASID, allowing the IOMMUv2 to make userspace process memory accessible to the GPU.
Next step is for the application to collect topology information via sysfs. This gives userspace enough information to be able to identify specific nodes (processors) in subsequent queue management calls. Application processes can create queues on multiple processors, and processors support queues from multiple processes.
At this point the application can create work queues in userspace memory and pass them through the usermode library to kfd to have them mapped onto HW queue slots so that commands written to the queues can be executed by the GPU. Queue operations specify a processor node, and so the bulk of this code is device-specific.
Written by John Bridgman <[email protected]>

Alexey Skidanov (1):
amdkfd: Implement the Get Process Aperture IOCTL

Andrew Lewycky (3):
amdkfd: Add basic modules to amdkfd
amdkfd: Add interrupt handling module
amdkfd: Implement the Set Memory Policy IOCTL

Ben Goz (8):
amdkfd: Add queue module
amdkfd: Add mqd_manager module
amdkfd: Add kernel queue module
amdkfd: Add module parameter of scheduling policy
amdkfd: Add packet manager module
amdkfd: Add process queue manager module
amdkfd: Add device queue manager module
amdkfd: Implement the create/destroy/update queue IOCTLs

Evgeny Pinchuk (3):
amdkfd: Add topology module to amdkfd
amdkfd: Implement the Get Clock Counters IOCTL
amdkfd: Implement the PMC Acquire/Release IOCTLs

Oded Gabbay (10):
mm: Add kfd_process pointer to mm_struct drm/radeon: reduce number of free VMIDs and pipes in KV drm/radeon/cik: Don't touch int of pipes 1-7 drm/radeon: Report doorbell configuration to amdkfd drm/radeon: adding synchronization for GRBM GFX drm/radeon: Add radeon <--> amdkfd interface Update MAINTAINERS and CREDITS files with amdkfd info
amdkfd: Add IOCTL set definitions of amdkfd
amdkfd: Add amdkfd skeleton driver
amdkfd: Add binding/unbinding calls to amd_iommu driver

 CREDITS                                            |    7 +
 MAINTAINERS                                        |   10 +
 drivers/gpu/drm/radeon/Kconfig                     |    2 +
 drivers/gpu/drm/radeon/Makefile                    |    3 +
 drivers/gpu/drm/radeon/amdkfd/Kconfig              |   10 +
 drivers/gpu/drm/radeon/amdkfd/Makefile             |   14 +
 drivers/gpu/drm/radeon/amdkfd/cik_mqds.h           |  185 +++
 drivers/gpu/drm/radeon/amdkfd/cik_regs.h           |  220 ++++
 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c       |  123 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c        |  518 +++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_crat.h           |  294 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_device.c         |  254 ++++
 .../drm/radeon/amdkfd/kfd_device_queue_manager.c   |  985 ++++++++++++++++
 .../drm/radeon/amdkfd/kfd_device_queue_manager.h   |  101 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c       |  264 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c      |  161 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c   |  305 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h   |   66 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_module.c         |  131 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c    |  291 +++++
 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h    |   54 +
 drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c |  488 ++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c          |   97 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h    |  682 +++++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h    |  107 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h           |  466 ++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_process.c        |  405 +++++++
 .../drm/radeon/amdkfd/kfd_process_queue_manager.c  |  343 ++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_queue.c          |  109 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_topology.c       | 1207
++++++++++++++++++++
 drivers/gpu/drm/radeon/amdkfd/kfd_topology.h       |  168 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_vidmem.c         |   96 ++
 drivers/gpu/drm/radeon/cik.c                       |  154 +--
 drivers/gpu/drm/radeon/cik_reg.h                   |   65 ++
 drivers/gpu/drm/radeon/cikd.h                      |   51 +-
 drivers/gpu/drm/radeon/radeon.h                    |    9 +
 drivers/gpu/drm/radeon/radeon_device.c             |   32 +
 drivers/gpu/drm/radeon/radeon_drv.c                |    5 +
 drivers/gpu/drm/radeon/radeon_kfd.c                |  566 +++++++++
 drivers/gpu/drm/radeon/radeon_kfd.h                |  119 ++
 drivers/gpu/drm/radeon/radeon_kms.c                |    7 +
 include/linux/mm_types.h                           |   14 +
 include/uapi/linux/kfd_ioctl.h                     |  133 +++
 43 files changed, 9226 insertions(+), 95 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/Kconfig
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/Makefile
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_mqds.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_regs.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_crat.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_module.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process_queue_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_queue.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_vidmem.c
 create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.c
 create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.h
 create mode 100644 include/uapi/linux/kfd_ioctl.h

Quoted 7 lines

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

Quoted 4 lines

Quoted 3 lines

Quoted 3 lines

--
1.9.1

Quoted 93 lines · Jerome Glisse

Quoted 91 lines · Oded Gabbay

Quoted 73 lines · Jerome Glisse

Quoted 63 lines · Oded Gabbay

Quoted 62 lines · Christian König

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 44 lines · Jerome Glisse

Quoted 25 lines · Oded Gabbay

Quoted 24 lines

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them are modifications to radeon driver and 18 of them include only amdkfd code. There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under drm/radeon/amdkfd. This move was done to emphasize the fact that this driver is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point is the radeon driver. Having said that, we will probably need to move it (maybe to be directly under drm) after we integrate with additional AMD gfx drivers.

Quoted 8 lines

Quoted 4 lines

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

So quick comments on some of your questions but first of all, thanks for the time you dedicated to review the code.

Quoted 4 lines

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

We only do gpu memory pinning for kernel objects. There are no userspace objects that are pinned on the gpu memory in our driver. If that is the case, is it still a show stopper ?

Quoted 9 lines

The kernel objects are:
- pipelines (4 per device)
- mqd per hiq (only 1 per device)
- mqd per userspace queue. On KV, we support up to 1K queues per process, for a total of 512K queues. Each mqd is 151 bytes, but the allocation is done in 256 alignment. So total *possible* memory is 128MB
- kernel queue (only 1 per device)
- fence address for kernel queue
- runlists for the CP (1 or 2 per device)

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Quoted 8 lines

Quoted 1 line

Christian.

Most of the pin downs are done on device initialization.
The "mqd per userspace" is done per userspace queue creation. However, as I said, it has an upper limit of 128MB on KV, and considering the 2G local memory, I think it is OK.
The runlists are also done on userspace queue creation/deletion, but we only have 1 or 2 runlists per device, so it is not that bad.

Quoted 3 lines

2G local memory ? You can not assume anything on userside configuration some one might build an hsa computer with 512M and still expect a functioning desktop.

First of all, I'm only considering Kaveri computer, not "hsa" computer. Second, I would imagine we can build some protection around it, like checking total local memory and limit number of queues based on some percentage of that total local memory. So, if someone will have only 512M, he will be able to open less queues.

Quoted 5 lines

I need to go look into what all this mqd is for, what it does and what it is about. But pinning is really bad and this is an issue with userspace command scheduling an issue that obviously AMD fails to take into account in design phase.

Maybe, but that is the H/W design non-the-less. We can't very well change the H/W.

Quoted 4 lines

You can not change the hardware but it is not an excuse to allow bad design to sneak in software to work around that. So i would rather penalize bad hardware design and have command submission in the kernel, until AMD fix its hardware to allow proper scheduling by the kernel and proper control by the kernel.

I'm sorry but I do *not* think this is a bad design. S/W scheduling in the kernel can not, IMO, scale well to 100K queues and 10K processes.

Quoted 4 lines

Because really where we want to go is having GPU closer to a CPU in term of scheduling capacity and once we get there we want the kernel to always be able to take over and do whatever it wants behind process back.

Who do you refer to when you say "we" ? AFAIK, the hw scheduling direction is where AMD is now and where it is heading in the future. That doesn't preclude the option to allow the kernel to take over and do what he wants. I agree that in KV we have a problem where we can't do a mid-wave preemption, so theoretically, a long running compute kernel can make things messy, but in Carrizo, we will have this ability. Having said that, it will only be through the CP H/W scheduling. So AMD is _not_ going to abandon H/W scheduling. You can dislike it, but this is the situation.

Quoted 57 lines

Quoted 57 lines

Quoted 57 lines

Quoted 19 lines

Quoted 19 lines

Quoted 19 lines

Quoted 19 lines

It might be better to add a drivers/gpu/drm/amd directory and add common stuff there.

Given that this is not intended to be final HSA api AFAICT then i would say this far better to avoid the whole kfd module and add ioctl to radeon. This would avoid crazy communication btw radeon and kfd.

The whole aperture business needs some serious explanation. Especialy as you want to use userspace address there is nothing to prevent userspace program from allocating things at address you reserve for lds, scratch, ... only sane way would be to move those lds, scratch inside the virtual address reserved for kernel (see kernel memory map).

The whole business of locking performance counter for exclusive per process access is a big NO. Which leads me to the questionable usefullness of user space command ring.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

That's like saying: "Which leads me to the questionable usefulness of HSA". I find it analogous to a situation where a network maintainer nacking a driver for a network card, which is slower than a different network card. Doesn't seem reasonable this situation is would happen. He would still put both the drivers in the kernel because people want to use the H/W and its features. So, I don't think this is a valid reason to NACK the driver.

Let me rephrase, drop the the performance counter ioctl and modulo memory pinning i see no objection. In other word, i am not NACKING whole patchset i am NACKING the performance ioctl.

Again this is another argument for round trip to the kernel. As inside kernel you could properly do exclusive gpu counter access accross single user cmd buffer execution.

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 7 lines

I only see issues with that. First and foremost i would
need to see solid figures that kernel ioctl or syscall has a higher an overhead that is measurable in any meaning full way against a simple function call. I know the userspace command ring is a big marketing features that please ignorant userspace programmer. But really this only brings issues and for absolutely not upside afaict.

Really ? You think that doing a context switch to kernel space, with all its overhead, is _not_ more expansive than just calling a function in userspace which only puts a buffer on a ring and writes a doorbell ?

I am saying the overhead is not that big and it probably will not matter in most usecase. For instance i did wrote the most useless kernel module that add two number through an ioctl (http://people.freedesktop.org/~glisse/adder.tar) and it takes ~0.35microseconds with ioctl while function is ~0.025microseconds so ioctl is 13 times slower.

Now if there is enough data that shows that a significant percentage of jobs submited to the GPU will take less that 0.35microsecond then yes userspace scheduling does make sense. But so far all we have is handwaving with no data to support any facts.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Now if we want to schedule from userspace than you will need to do something about the pinning, something that gives control to kernel so that kernel can unpin when it wants and move object when it wants no matter what userspace is doing.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 94 lines · Oded Gabbay

Quoted 93 lines · Jerome Glisse

Quoted 91 lines · Oded Gabbay

Quoted 73 lines · Jerome Glisse

Quoted 63 lines · Oded Gabbay

Quoted 62 lines · Christian König

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 44 lines · Jerome Glisse

Quoted 25 lines · Oded Gabbay

Quoted 24 lines

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them are modifications to radeon driver and 18 of them include only amdkfd code. There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under drm/radeon/amdkfd. This move was done to emphasize the fact that this driver is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point is the radeon driver. Having said that, we will probably need to move it (maybe to be directly under drm) after we integrate with additional AMD gfx drivers.

Quoted 8 lines

Quoted 4 lines

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

So quick comments on some of your questions but first of all, thanks for the time you dedicated to review the code.

Quoted 4 lines

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

We only do gpu memory pinning for kernel objects. There are no userspace objects that are pinned on the gpu memory in our driver. If that is the case, is it still a show stopper ?

Quoted 9 lines

The kernel objects are:
- pipelines (4 per device)
- mqd per hiq (only 1 per device)
- mqd per userspace queue. On KV, we support up to 1K queues per process, for a total of 512K queues. Each mqd is 151 bytes, but the allocation is done in 256 alignment. So total *possible* memory is 128MB
- kernel queue (only 1 per device)
- fence address for kernel queue
- runlists for the CP (1 or 2 per device)

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Quoted 8 lines

Quoted 1 line

Christian.

Most of the pin downs are done on device initialization.
The "mqd per userspace" is done per userspace queue creation. However, as I said, it has an upper limit of 128MB on KV, and considering the 2G local memory, I think it is OK.
The runlists are also done on userspace queue creation/deletion, but we only have 1 or 2 runlists per device, so it is not that bad.

Quoted 3 lines

2G local memory ? You can not assume anything on userside configuration some one might build an hsa computer with 512M and still expect a functioning desktop.

First of all, I'm only considering Kaveri computer, not "hsa" computer. Second, I would imagine we can build some protection around it, like checking total local memory and limit number of queues based on some percentage of that total local memory. So, if someone will have only 512M, he will be able to open less queues.

Quoted 5 lines

I need to go look into what all this mqd is for, what it does and what it is about. But pinning is really bad and this is an issue with userspace command scheduling an issue that obviously AMD fails to take into account in design phase.

Maybe, but that is the H/W design non-the-less. We can't very well change the H/W.

Quoted 6 lines

Quoted 4 lines

You can not change the hardware but it is not an excuse to allow bad design to sneak in software to work around that. So i would rather penalize bad hardware design and have command submission in the kernel, until AMD fix its hardware to allow proper scheduling by the kernel and proper control by the kernel.

I'm sorry but I do *not* think this is a bad design. S/W scheduling in the kernel can not, IMO, scale well to 100K queues and 10K processes.

I am not advocating for having kernel decide down to the very last details. I am advocating for kernel being able to preempt at any time and be able to decrease or increase user queue priority so overall kernel is in charge of resources management and it can handle rogue client in proper fashion.

Quoted 4 lines

Quoted 4 lines

Because really where we want to go is having GPU closer to a CPU in term of scheduling capacity and once we get there we want the kernel to always be able to take over and do whatever it wants behind process back.

Quoted 9 lines

Who do you refer to when you say "we" ? AFAIK, the hw scheduling direction is where AMD is now and where it is heading in the future. That doesn't preclude the option to allow the kernel to take over and do what he wants. I agree that in KV we have a problem where we can't do a mid-wave preemption, so theoretically, a long running compute kernel can make things messy, but in Carrizo, we will have this ability. Having said that, it will only be through the CP H/W scheduling. So AMD is _not_ going to abandon H/W scheduling. You can dislike it, but this is the situation.

We was for the overall Linux community but maybe i should not pretend to talk for anyone interested in having a common standard.

My point is that current hardware do not have approriate hardware support for preemption hence, current hardware should use ioctl to schedule job and AMD should think a bit more on commiting to a design and handwaving any hardware short coming as something that can be work around in the software. The pinning thing is broken by design, only way to work around it is through kernel cmd queue scheduling that's a fact.

Once hardware support proper preemption and allows to move around/evict buffer use on behalf of userspace command queue then we can allow userspace scheduling but until then my personnal opinion is that it should not be allowed and that people will have to pay the ioctl price which i proved to be small, because really if you 100K queue each with one job, i would not expect that all those 100K job will complete in less time than it takes to execute an ioctl ie by even if you do not have the ioctl delay what ever you schedule will have to wait on previously submited jobs.

Quoted 58 lines

Quoted 58 lines

Quoted 58 lines

Quoted 58 lines

Quoted 20 lines

Quoted 20 lines

Quoted 20 lines

Quoted 20 lines

It might be better to add a drivers/gpu/drm/amd directory and add common stuff there.

Given that this is not intended to be final HSA api AFAICT then i would say this far better to avoid the whole kfd module and add ioctl to radeon. This would avoid crazy communication btw radeon and kfd.

The whole aperture business needs some serious explanation. Especialy as you want to use userspace address there is nothing to prevent userspace program from allocating things at address you reserve for lds, scratch, ... only sane way would be to move those lds, scratch inside the virtual address reserved for kernel (see kernel memory map).

The whole business of locking performance counter for exclusive per process access is a big NO. Which leads me to the questionable usefullness of user space command ring.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

That's like saying: "Which leads me to the questionable usefulness of HSA". I find it analogous to a situation where a network maintainer nacking a driver for a network card, which is slower than a different network card. Doesn't seem reasonable this situation is would happen. He would still put both the drivers in the kernel because people want to use the H/W and its features. So, I don't think this is a valid reason to NACK the driver.

Let me rephrase, drop the the performance counter ioctl and modulo memory pinning i see no objection. In other word, i am not NACKING whole patchset i am NACKING the performance ioctl.

Again this is another argument for round trip to the kernel. As inside kernel you could properly do exclusive gpu counter access accross single user cmd buffer execution.

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 7 lines

I only see issues with that. First and foremost i would
need to see solid figures that kernel ioctl or syscall has a higher an overhead that is measurable in any meaning full way against a simple function call. I know the userspace command ring is a big marketing features that please ignorant userspace programmer. But really this only brings issues and for absolutely not upside afaict.

Really ? You think that doing a context switch to kernel space, with all its overhead, is _not_ more expansive than just calling a function in userspace which only puts a buffer on a ring and writes a doorbell ?

I am saying the overhead is not that big and it probably will not matter in most usecase. For instance i did wrote the most useless kernel module that add two number through an ioctl (http://people.freedesktop.org/~glisse/adder.tar) and it takes ~0.35microseconds with ioctl while function is ~0.025microseconds so ioctl is 13 times slower.

Now if there is enough data that shows that a significant percentage of jobs submited to the GPU will take less that 0.35microsecond then yes userspace scheduling does make sense. But so far all we have is handwaving with no data to support any facts.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Now if we want to schedule from userspace than you will need to do something about the pinning, something that gives control to kernel so that kernel can unpin when it wants and move object when it wants no matter what userspace is doing.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Quoted 132 lines · Jerome Glisse

Quoted 94 lines · Oded Gabbay

Quoted 93 lines · Jerome Glisse

Quoted 91 lines · Oded Gabbay

Quoted 73 lines · Jerome Glisse

Quoted 63 lines · Oded Gabbay

Quoted 62 lines · Christian König

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 44 lines · Jerome Glisse

Quoted 25 lines · Oded Gabbay

Quoted 24 lines

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them are modifications to radeon driver and 18 of them include only amdkfd code. There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under drm/radeon/amdkfd. This move was done to emphasize the fact that this driver is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point is the radeon driver. Having said that, we will probably need to move it (maybe to be directly under drm) after we integrate with additional AMD gfx drivers.

Quoted 8 lines

Quoted 4 lines

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

So quick comments on some of your questions but first of all, thanks for the time you dedicated to review the code.

Quoted 4 lines

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

We only do gpu memory pinning for kernel objects. There are no userspace objects that are pinned on the gpu memory in our driver. If that is the case, is it still a show stopper ?

Quoted 9 lines

The kernel objects are:
- pipelines (4 per device)
- mqd per hiq (only 1 per device)
- mqd per userspace queue. On KV, we support up to 1K queues per process, for a total of 512K queues. Each mqd is 151 bytes, but the allocation is done in 256 alignment. So total *possible* memory is 128MB
- kernel queue (only 1 per device)
- fence address for kernel queue
- runlists for the CP (1 or 2 per device)

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Quoted 8 lines

Quoted 1 line

Christian.

Most of the pin downs are done on device initialization.
The "mqd per userspace" is done per userspace queue creation. However, as I said, it has an upper limit of 128MB on KV, and considering the 2G local memory, I think it is OK.
The runlists are also done on userspace queue creation/deletion, but we only have 1 or 2 runlists per device, so it is not that bad.

Quoted 3 lines

2G local memory ? You can not assume anything on userside configuration some one might build an hsa computer with 512M and still expect a functioning desktop.

First of all, I'm only considering Kaveri computer, not "hsa" computer. Second, I would imagine we can build some protection around it, like checking total local memory and limit number of queues based on some percentage of that total local memory. So, if someone will have only 512M, he will be able to open less queues.

Quoted 5 lines

I need to go look into what all this mqd is for, what it does and what it is about. But pinning is really bad and this is an issue with userspace command scheduling an issue that obviously AMD fails to take into account in design phase.

Maybe, but that is the H/W design non-the-less. We can't very well change the H/W.

Quoted 6 lines

Quoted 4 lines

You can not change the hardware but it is not an excuse to allow bad design to sneak in software to work around that. So i would rather penalize bad hardware design and have command submission in the kernel, until AMD fix its hardware to allow proper scheduling by the kernel and proper control by the kernel.

I'm sorry but I do *not* think this is a bad design. S/W scheduling in the kernel can not, IMO, scale well to 100K queues and 10K processes.

I am not advocating for having kernel decide down to the very last details. I am advocating for kernel being able to preempt at any time and be able to decrease or increase user queue priority so overall kernel is in charge of resources management and it can handle rogue client in proper fashion.

Quoted 4 lines

Quoted 4 lines

Because really where we want to go is having GPU closer to a CPU in term of scheduling capacity and once we get there we want the kernel to always be able to take over and do whatever it wants behind process back.

Quoted 9 lines

Who do you refer to when you say "we" ? AFAIK, the hw scheduling direction is where AMD is now and where it is heading in the future. That doesn't preclude the option to allow the kernel to take over and do what he wants. I agree that in KV we have a problem where we can't do a mid-wave preemption, so theoretically, a long running compute kernel can make things messy, but in Carrizo, we will have this ability. Having said that, it will only be through the CP H/W scheduling. So AMD is _not_ going to abandon H/W scheduling. You can dislike it, but this is the situation.

We was for the overall Linux community but maybe i should not pretend to talk for anyone interested in having a common standard.

My point is that current hardware do not have approriate hardware support for preemption hence, current hardware should use ioctl to schedule job and AMD should think a bit more on commiting to a design and handwaving any hardware short coming as something that can be work around in the software. The pinning thing is broken by design, only way to work around it is through kernel cmd queue scheduling that's a fact.

Quoted 8 lines

Once hardware support proper preemption and allows to move around/evict buffer use on behalf of userspace command queue then we can allow userspace scheduling but until then my personnal opinion is that it should not be allowed and that people will have to pay the ioctl price which i proved to be small, because really if you 100K queue each with one job, i would not expect that all those 100K job will complete in less time than it takes to execute an ioctl ie by even if you do not have the ioctl delay what ever you schedule will have to wait on previously submited jobs.

But Jerome, the core problem still remains in effect, even with your suggestion. If an application, either via userspace queue or via ioctl, submits a long-running kernel, than the CPU in general can't stop the GPU from running it. And if that kernel does while(1); than that's it, game's over, and no matter how you submitted the work. So I don't really see the big advantage in your proposal. Only in CZ we can stop this wave (by CP H/W scheduling only). What are you saying is basically I won't allow people to use compute on Linux KV system because it _may_ get the system stuck.

So even if I really wanted to, and I may agree with you theoretically on that, I can't fulfill your desire to make the "kernel being able to preempt at any time and be able to decrease or increase user queue priority so overall kernel is in charge of resources management and it can handle rogue client in proper fashion". Not in KV, and I guess not in CZ as well.

Oded

Quoted 66 lines

Quoted 65 lines

Quoted 65 lines

Quoted 65 lines

Quoted 65 lines

Quoted 21 lines

Quoted 21 lines

Quoted 21 lines

Quoted 21 lines

It might be better to add a drivers/gpu/drm/amd directory and add common stuff there.

Given that this is not intended to be final HSA api AFAICT then i would say this far better to avoid the whole kfd module and add ioctl to radeon. This would avoid crazy communication btw radeon and kfd.

The whole aperture business needs some serious explanation. Especialy as you want to use userspace address there is nothing to prevent userspace program from allocating things at address you reserve for lds, scratch, ... only sane way would be to move those lds, scratch inside the virtual address reserved for kernel (see kernel memory map).

The whole business of locking performance counter for exclusive per process access is a big NO. Which leads me to the questionable usefullness of user space command ring.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

That's like saying: "Which leads me to the questionable usefulness of HSA". I find it analogous to a situation where a network maintainer nacking a driver for a network card, which is slower than a different network card. Doesn't seem reasonable this situation is would happen. He would still put both the drivers in the kernel because people want to use the H/W and its features. So, I don't think this is a valid reason to NACK the driver.

Let me rephrase, drop the the performance counter ioctl and modulo memory pinning i see no objection. In other word, i am not NACKING whole patchset i am NACKING the performance ioctl.

Again this is another argument for round trip to the kernel. As inside kernel you could properly do exclusive gpu counter access accross single user cmd buffer execution.

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 7 lines

I only see issues with that. First and foremost i would
need to see solid figures that kernel ioctl or syscall has a higher an overhead that is measurable in any meaning full way against a simple function call. I know the userspace command ring is a big marketing features that please ignorant userspace programmer. But really this only brings issues and for absolutely not upside afaict.

Really ? You think that doing a context switch to kernel space, with all its overhead, is _not_ more expansive than just calling a function in userspace which only puts a buffer on a ring and writes a doorbell ?

I am saying the overhead is not that big and it probably will not matter in most usecase. For instance i did wrote the most useless kernel module that add two number through an ioctl (http://people.freedesktop.org/~glisse/adder.tar) and it takes ~0.35microseconds with ioctl while function is ~0.025microseconds so ioctl is 13 times slower.

Now if there is enough data that shows that a significant percentage of jobs submited to the GPU will take less that 0.35microsecond then yes userspace scheduling does make sense. But so far all we have is handwaving with no data to support any facts.

Now if we want to schedule from userspace than you will need to do something about the pinning, something that gives control to kernel so that kernel can unpin when it wants and move object when it wants no matter what userspace is doing.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 6 lines

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Quoted 152 lines · Oded Gabbay

Quoted 132 lines · Jerome Glisse

Quoted 94 lines · Oded Gabbay

Quoted 93 lines · Jerome Glisse

Quoted 91 lines · Oded Gabbay

Quoted 73 lines · Jerome Glisse

Quoted 63 lines · Oded Gabbay

Quoted 62 lines · Christian König

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 44 lines · Jerome Glisse

Quoted 25 lines · Oded Gabbay

Quoted 24 lines

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them are modifications to radeon driver and 18 of them include only amdkfd code. There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under drm/radeon/amdkfd. This move was done to emphasize the fact that this driver is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point is the radeon driver. Having said that, we will probably need to move it (maybe to be directly under drm) after we integrate with additional AMD gfx drivers.

Quoted 8 lines

Quoted 4 lines

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

So quick comments on some of your questions but first of all, thanks for the time you dedicated to review the code.

Quoted 4 lines

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

We only do gpu memory pinning for kernel objects. There are no userspace objects that are pinned on the gpu memory in our driver. If that is the case, is it still a show stopper ?

Quoted 9 lines

The kernel objects are:
- pipelines (4 per device)
- mqd per hiq (only 1 per device)
- mqd per userspace queue. On KV, we support up to 1K queues per process, for a total of 512K queues. Each mqd is 151 bytes, but the allocation is done in 256 alignment. So total *possible* memory is 128MB
- kernel queue (only 1 per device)
- fence address for kernel queue
- runlists for the CP (1 or 2 per device)

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Quoted 8 lines

Quoted 1 line

Christian.

Most of the pin downs are done on device initialization.
The "mqd per userspace" is done per userspace queue creation. However, as I said, it has an upper limit of 128MB on KV, and considering the 2G local memory, I think it is OK.
The runlists are also done on userspace queue creation/deletion, but we only have 1 or 2 runlists per device, so it is not that bad.

Quoted 3 lines

2G local memory ? You can not assume anything on userside configuration some one might build an hsa computer with 512M and still expect a functioning desktop.

First of all, I'm only considering Kaveri computer, not "hsa" computer. Second, I would imagine we can build some protection around it, like checking total local memory and limit number of queues based on some percentage of that total local memory. So, if someone will have only 512M, he will be able to open less queues.

Quoted 5 lines

I need to go look into what all this mqd is for, what it does and what it is about. But pinning is really bad and this is an issue with userspace command scheduling an issue that obviously AMD fails to take into account in design phase.

Maybe, but that is the H/W design non-the-less. We can't very well change the H/W.

Quoted 6 lines

Quoted 4 lines

You can not change the hardware but it is not an excuse to allow bad design to sneak in software to work around that. So i would rather penalize bad hardware design and have command submission in the kernel, until AMD fix its hardware to allow proper scheduling by the kernel and proper control by the kernel.

I'm sorry but I do *not* think this is a bad design. S/W scheduling in the kernel can not, IMO, scale well to 100K queues and 10K processes.

I am not advocating for having kernel decide down to the very last details. I am advocating for kernel being able to preempt at any time and be able to decrease or increase user queue priority so overall kernel is in charge of resources management and it can handle rogue client in proper fashion.

Quoted 4 lines

Quoted 4 lines

Because really where we want to go is having GPU closer to a CPU in term of scheduling capacity and once we get there we want the kernel to always be able to take over and do whatever it wants behind process back.

Quoted 9 lines

Who do you refer to when you say "we" ? AFAIK, the hw scheduling direction is where AMD is now and where it is heading in the future. That doesn't preclude the option to allow the kernel to take over and do what he wants. I agree that in KV we have a problem where we can't do a mid-wave preemption, so theoretically, a long running compute kernel can make things messy, but in Carrizo, we will have this ability. Having said that, it will only be through the CP H/W scheduling. So AMD is _not_ going to abandon H/W scheduling. You can dislike it, but this is the situation.

We was for the overall Linux community but maybe i should not pretend to talk for anyone interested in having a common standard.

My point is that current hardware do not have approriate hardware support for preemption hence, current hardware should use ioctl to schedule job and AMD should think a bit more on commiting to a design and handwaving any hardware short coming as something that can be work around in the software. The pinning thing is broken by design, only way to work around it is through kernel cmd queue scheduling that's a fact.

Quoted 8 lines

Once hardware support proper preemption and allows to move around/evict buffer use on behalf of userspace command queue then we can allow userspace scheduling but until then my personnal opinion is that it should not be allowed and that people will have to pay the ioctl price which i proved to be small, because really if you 100K queue each with one job, i would not expect that all those 100K job will complete in less time than it takes to execute an ioctl ie by even if you do not have the ioctl delay what ever you schedule will have to wait on previously submited jobs.

But Jerome, the core problem still remains in effect, even with your suggestion. If an application, either via userspace queue or via ioctl, submits a long-running kernel, than the CPU in general can't stop the GPU from running it. And if that kernel does while(1); than that's it, game's over, and no matter how you submitted the work. So I don't really see the big advantage in your proposal. Only in CZ we can stop this wave (by CP H/W scheduling only). What are you saying is basically I won't allow people to use compute on Linux KV system because it _may_ get the system stuck.

Quoted 8 lines

So even if I really wanted to, and I may agree with you theoretically on that, I can't fulfill your desire to make the "kernel being able to preempt at any time and be able to decrease or increase user queue priority so overall kernel is in charge of resources management and it can handle rogue client in proper fashion". Not in KV, and I guess not in CZ as well.

Oded

I do understand that but using kernel ioctl provide the same kind of control as we have now ie we can bind/unbind buffer on per command buffer submission basis, just like with current graphic or compute stuff.

Yes current graphic and compute stuff can launch a while and never return back and yes currently we have nothing against that but we should and solution would be simple just kill the gpu thread.

Quoted 66 lines

Quoted 66 lines

Quoted 65 lines

Quoted 65 lines

Quoted 65 lines

Quoted 65 lines

Quoted 21 lines

Quoted 21 lines

Quoted 21 lines

Quoted 21 lines

It might be better to add a drivers/gpu/drm/amd directory and add common stuff there.

Given that this is not intended to be final HSA api AFAICT then i would say this far better to avoid the whole kfd module and add ioctl to radeon. This would avoid crazy communication btw radeon and kfd.

The whole aperture business needs some serious explanation. Especialy as you want to use userspace address there is nothing to prevent userspace program from allocating things at address you reserve for lds, scratch, ... only sane way would be to move those lds, scratch inside the virtual address reserved for kernel (see kernel memory map).

The whole business of locking performance counter for exclusive per process access is a big NO. Which leads me to the questionable usefullness of user space command ring.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

That's like saying: "Which leads me to the questionable usefulness of HSA". I find it analogous to a situation where a network maintainer nacking a driver for a network card, which is slower than a different network card. Doesn't seem reasonable this situation is would happen. He would still put both the drivers in the kernel because people want to use the H/W and its features. So, I don't think this is a valid reason to NACK the driver.

Let me rephrase, drop the the performance counter ioctl and modulo memory pinning i see no objection. In other word, i am not NACKING whole patchset i am NACKING the performance ioctl.

Again this is another argument for round trip to the kernel. As inside kernel you could properly do exclusive gpu counter access accross single user cmd buffer execution.

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 7 lines

I only see issues with that. First and foremost i would
need to see solid figures that kernel ioctl or syscall has a higher an overhead that is measurable in any meaning full way against a simple function call. I know the userspace command ring is a big marketing features that please ignorant userspace programmer. But really this only brings issues and for absolutely not upside afaict.

Really ? You think that doing a context switch to kernel space, with all its overhead, is _not_ more expansive than just calling a function in userspace which only puts a buffer on a ring and writes a doorbell ?

I am saying the overhead is not that big and it probably will not matter in most usecase. For instance i did wrote the most useless kernel module that add two number through an ioctl (http://people.freedesktop.org/~glisse/adder.tar) and it takes ~0.35microseconds with ioctl while function is ~0.025microseconds so ioctl is 13 times slower.

Now if there is enough data that shows that a significant percentage of jobs submited to the GPU will take less that 0.35microsecond then yes userspace scheduling does make sense. But so far all we have is handwaving with no data to support any facts.

Now if we want to schedule from userspace than you will need to do something about the pinning, something that gives control to kernel so that kernel can unpin when it wants and move object when it wants no matter what userspace is doing.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 7 lines

Quoted 6 lines

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Quoted 166 lines · Jerome Glisse

Quoted 152 lines · Oded Gabbay

Quoted 132 lines · Jerome Glisse

Quoted 94 lines · Oded Gabbay

Quoted 93 lines · Jerome Glisse

Quoted 91 lines · Oded Gabbay

Quoted 73 lines · Jerome Glisse

Quoted 63 lines · Oded Gabbay

Quoted 62 lines · Christian König

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 44 lines · Jerome Glisse

Quoted 25 lines · Oded Gabbay

Quoted 24 lines

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series
restructured with a cleaner history and no totally-different-early-versions
of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them
are modifications to radeon driver and 18 of them include only amdkfd code.
There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under
drm/radeon/amdkfd. This move was done to emphasize the fact that this driver
is an AMD-only driver at this point. Having said that, we do foresee a
generic hsa framework being implemented in the future and in that case, we
will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to
keep it as a seperate driver from radeon. Therefore, the amdkfd code is
contained in its own folder. The amdkfd folder was put under the radeon
folder because the only AMD gfx driver in the Linux kernel at this point
is the radeon driver. Having said that, we will probably need to move it
(maybe to be directly under drm) after we integrate with additional AMD gfx
drivers.

Quoted 8 lines

Quoted 4 lines

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

So quick comments on some of your questions but first of all, thanks for the time you dedicated to review the code.

Quoted 4 lines

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

We only do gpu memory pinning for kernel objects. There are no userspace objects that are pinned on the gpu memory in our driver. If that is the case, is it still a show stopper ?

Quoted 9 lines

The kernel objects are:
- pipelines (4 per device)
- mqd per hiq (only 1 per device)
- mqd per userspace queue. On KV, we support up to 1K queues per process, for a total of 512K queues. Each mqd is 151 bytes, but the allocation is done in 256 alignment. So total *possible* memory is 128MB
- kernel queue (only 1 per device)
- fence address for kernel queue
- runlists for the CP (1 or 2 per device)

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Quoted 8 lines

Quoted 1 line

Christian.

Most of the pin downs are done on device initialization.
The "mqd per userspace" is done per userspace queue creation. However, as I said, it has an upper limit of 128MB on KV, and considering the 2G local memory, I think it is OK.
The runlists are also done on userspace queue creation/deletion, but we only have 1 or 2 runlists per device, so it is not that bad.

Quoted 3 lines

2G local memory ? You can not assume anything on userside configuration some one might build an hsa computer with 512M and still expect a functioning desktop.

First of all, I'm only considering Kaveri computer, not "hsa" computer. Second, I would imagine we can build some protection around it, like checking total local memory and limit number of queues based on some percentage of that total local memory. So, if someone will have only 512M, he will be able to open less queues.

Quoted 5 lines

I need to go look into what all this mqd is for, what it does and what it is about. But pinning is really bad and this is an issue with userspace command scheduling an issue that obviously AMD fails to take into account in design phase.

Maybe, but that is the H/W design non-the-less. We can't very well change the H/W.

Quoted 6 lines

Quoted 4 lines

You can not change the hardware but it is not an excuse to allow bad design to sneak in software to work around that. So i would rather penalize bad hardware design and have command submission in the kernel, until AMD fix its hardware to allow proper scheduling by the kernel and proper control by the kernel.

I'm sorry but I do *not* think this is a bad design. S/W scheduling in the kernel can not, IMO, scale well to 100K queues and 10K processes.

I am not advocating for having kernel decide down to the very last details. I am advocating for kernel being able to preempt at any time and be able to decrease or increase user queue priority so overall kernel is in charge of resources management and it can handle rogue client in proper fashion.

Quoted 4 lines

Quoted 4 lines

Because really where we want to go is having GPU closer to a CPU in term of scheduling capacity and once we get there we want the kernel to always be able to take over and do whatever it wants behind process back.

Quoted 9 lines

Who do you refer to when you say "we" ? AFAIK, the hw scheduling direction is where AMD is now and where it is heading in the future. That doesn't preclude the option to allow the kernel to take over and do what he wants. I agree that in KV we have a problem where we can't do a mid-wave preemption, so theoretically, a long running compute kernel can make things messy, but in Carrizo, we will have this ability. Having said that, it will only be through the CP H/W scheduling. So AMD is _not_ going to abandon H/W scheduling. You can dislike it, but this is the situation.

We was for the overall Linux community but maybe i should not pretend to talk for anyone interested in having a common standard.

My point is that current hardware do not have approriate hardware support for preemption hence, current hardware should use ioctl to schedule job and AMD should think a bit more on commiting to a design and handwaving any hardware short coming as something that can be work around in the software. The pinning thing is broken by design, only way to work around it is through kernel cmd queue scheduling that's a fact.

Quoted 8 lines

Once hardware support proper preemption and allows to move around/evict buffer use on behalf of userspace command queue then we can allow userspace scheduling but until then my personnal opinion is that it should not be allowed and that people will have to pay the ioctl price which i proved to be small, because really if you 100K queue each with one job, i would not expect that all those 100K job will complete in less time than it takes to execute an ioctl ie by even if you do not have the ioctl delay what ever you schedule will have to wait on previously submited jobs.

But Jerome, the core problem still remains in effect, even with your suggestion. If an application, either via userspace queue or via ioctl, submits a long-running kernel, than the CPU in general can't stop the GPU from running it. And if that kernel does while(1); than that's it, game's over, and no matter how you submitted the work. So I don't really see the big advantage in your proposal. Only in CZ we can stop this wave (by CP H/W scheduling only). What are you saying is basically I won't allow people to use compute on Linux KV system because it _may_ get the system stuck.

Quoted 8 lines

So even if I really wanted to, and I may agree with you theoretically on that, I can't fulfill your desire to make the "kernel being able to preempt at any time and be able to decrease or increase user queue priority so overall kernel is in charge of resources management and it can handle rogue client in proper fashion". Not in KV, and I guess not in CZ as well.

Oded

I do understand that but using kernel ioctl provide the same kind of control as we have now ie we can bind/unbind buffer on per command buffer submission basis, just like with current graphic or compute stuff.

Quoted 4 lines

Yes current graphic and compute stuff can launch a while and never return back and yes currently we have nothing against that but we should and solution would be simple just kill the gpu thread.

OK, so in that case, the kernel can simple unmap all the queues by simply writing an UNMAP_QUEUES packet to the HIQ. Even if the queues are userspace, they will not be mapped to the internal CP scheduler. Does that satisfy the kernel control level you want ?

Oded

Quoted 66 lines

Quoted 66 lines

Quoted 66 lines

Quoted 65 lines

Quoted 65 lines

Quoted 65 lines

Quoted 65 lines

Quoted 21 lines

Quoted 21 lines

Quoted 21 lines

Quoted 21 lines

It might be better to add a drivers/gpu/drm/amd directory and add common stuff there.

Given that this is not intended to be final HSA api AFAICT then i would say this far better to avoid the whole kfd module and add ioctl to radeon. This would avoid crazy communication btw radeon and kfd.

The whole aperture business needs some serious explanation. Especialy as you want to use userspace address there is nothing to prevent userspace program from allocating things at address you reserve for lds, scratch, ... only sane way would be to move those lds, scratch inside the virtual address reserved for kernel (see kernel memory map).

The whole business of locking performance counter for exclusive per process access is a big NO. Which leads me to the questionable usefullness of user space command ring.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

That's like saying: "Which leads me to the questionable usefulness of HSA". I find it analogous to a situation where a network maintainer nacking a driver for a network card, which is slower than a different network card. Doesn't seem reasonable this situation is would happen. He would still put both the drivers in the kernel because people want to use the H/W and its features. So, I don't think this is a valid reason to NACK the driver.

Let me rephrase, drop the the performance counter ioctl and modulo memory pinning i see no objection. In other word, i am not NACKING whole patchset i am NACKING the performance ioctl.

Again this is another argument for round trip to the kernel. As inside kernel you could properly do exclusive gpu counter access accross single user cmd buffer execution.

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 7 lines

I only see issues with that. First and foremost i would
need to see solid figures that kernel ioctl or syscall has a higher an overhead that is measurable in any meaning full way against a simple function call. I know the userspace command ring is a big marketing features that please ignorant userspace programmer. But really this only brings issues and for absolutely not upside afaict.

Really ? You think that doing a context switch to kernel space, with all its overhead, is _not_ more expansive than just calling a function in userspace which only puts a buffer on a ring and writes a doorbell ?

I am saying the overhead is not that big and it probably will not matter in most usecase. For instance i did wrote the most useless kernel module that add two number through an ioctl (http://people.freedesktop.org/~glisse/adder.tar) and it takes ~0.35microseconds with ioctl while function is ~0.025microseconds so ioctl is 13 times slower.

Now if there is enough data that shows that a significant percentage of jobs submited to the GPU will take less that 0.35microsecond then yes userspace scheduling does make sense. But so far all we have is handwaving with no data to support any facts.

Now if we want to schedule from userspace than you will need to do something about the pinning, something that gives control to kernel so that kernel can unpin when it wants and move object when it wants no matter what userspace is doing.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

-----Original Message-----
From: dri-devel [mailto:[email protected]] On Behalf Of Jerome Glisse
Sent: Monday, July 21, 2014 7:06 PM
To: Gabbay, Oded
Cc: Lewycky, Andrew; Pinchuk, Evgeny; Daenzer, Michel; linux- [email protected]; [email protected]; linux-mm; Skidanov, Alexey; Andrew Morton
Subject: Re: [PATCH v2 00/25] AMDKFD kernel driver

Quoted 12 lines · Oded Gabbay

Quoted 11 lines · Jerome Glisse

Quoted 10 lines · Oded Gabbay

Quoted 9 lines · Jerome Glisse

Quoted 8 lines · Oded Gabbay

Quoted 7 lines · Jerome Glisse

Quoted 6 lines · Oded Gabbay

Quoted 5 lines · Jerome Glisse

Quoted 4 lines · Oded Gabbay

Quoted 3 lines · Christian König

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 2 lines · Jerome Glisse

Quoted 1 line · Oded Gabbay

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a
v2 patch series restructured with a cleaner history and
no totally-different-early-versions of the code.

Instead of 83 patches, there are now a total of 25
patches, where 5 of them are modifications to radeon driver

and 18 of them include only amdkfd code.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

There is no code going away or even modified between

patches, only added.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

The driver was renamed from radeon_kfd to amdkfd and
moved to reside under drm/radeon/amdkfd. This move was
done to emphasize the fact that this driver is an
AMD-only driver at this point. Having said that, we do
foresee a generic hsa framework being implemented in the

future and in that case, we will adjust amdkfd to work within that framework.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

As the amdkfd driver should support multiple AMD gfx
drivers, we want to keep it as a seperate driver from
radeon. Therefore, the amdkfd code is contained in its
own folder. The amdkfd folder was put under the radeon
folder because the only AMD gfx driver in the Linux
kernel at this point is the radeon driver. Having said
that, we will probably need to move it (maybe to be directly

under drm) after we integrate with additional AMD gfx drivers.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

For people who like to review using git, the v2 patch set is

located at:

Quoted 36 lines

Quoted 36 lines

Quoted 36 lines

Quoted 36 lines

Quoted 36 lines

Quoted 36 lines

Quoted 36 lines

Quoted 36 lines

Quoted 36 lines

Quoted 36 lines

Quoted 18 lines

Quoted 8 lines

http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-nex
t-3.17-v2

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches.
There is many things that need more documentation
espacialy as of right now there is no userspace i can go look at.

So quick comments on some of your questions but first of all, thanks for the time you dedicated to review the code.

Quoted 4 lines

There few show stopper, biggest one is gpu memory pinning
this is a big no, that would need serious arguments for
any hope of convincing me on that side.

We only do gpu memory pinning for kernel objects. There are no userspace objects that are pinned on the gpu memory in our driver. If that is the case, is it still a show stopper ?

Quoted 10 lines

The kernel objects are:
- pipelines (4 per device)
- mqd per hiq (only 1 per device)
- mqd per userspace queue. On KV, we support up to 1K queues per process, for a total of 512K queues. Each mqd is 151 bytes, but the allocation is done in
256 alignment. So total *possible* memory is 128MB
- kernel queue (only 1 per device)
- fence address for kernel queue
- runlists for the CP (1 or 2 per device)

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 1 line

Christian.

Most of the pin downs are done on device initialization. The "mqd per userspace" is done per userspace queue creation. However, as I said, it has an upper limit of 128MB on KV, and considering the 2G local memory, I think it is OK.
The runlists are also done on userspace queue creation/deletion, but we only have 1 or 2 runlists per device, so

it is not that bad.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

2G local memory ? You can not assume anything on userside configuration some one might build an hsa computer with 512M and still expect a functioning desktop.

First of all, I'm only considering Kaveri computer, not "hsa"

computer.

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Second, I would imagine we can build some protection around it, like checking total local memory and limit number of queues based on some percentage of that total local memory. So, if someone will have only 512M, he will be able to open less queues.

Quoted 5 lines

I need to go look into what all this mqd is for, what it does and what it is about. But pinning is really bad and this is an issue with userspace command scheduling an issue that obviously AMD fails to take into account in design phase.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 2 lines

Maybe, but that is the H/W design non-the-less. We can't very well change the H/W.

You can not change the hardware but it is not an excuse to allow bad design to sneak in software to work around that. So i would rather penalize bad hardware design and have command submission in the kernel, until AMD fix its hardware to allow proper scheduling

by the kernel and proper control by the kernel.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

I'm sorry but I do *not* think this is a bad design. S/W scheduling in the kernel can not, IMO, scale well to 100K queues and

10K processes.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

I am not advocating for having kernel decide down to the very last details. I am advocating for kernel being able to preempt at any time and be able to decrease or increase user queue priority so overall kernel is in charge of resources management and it can handle

rogue client in proper fashion.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Because really where we want to go is having GPU closer to a CPU in term of scheduling capacity and once we get there we want the kernel to always be able to take over and do whatever it wants

behind process back.

Quoted 13 lines

Quoted 13 lines

Quoted 13 lines

Quoted 13 lines

Quoted 9 lines

Who do you refer to when you say "we" ? AFAIK, the hw scheduling direction is where AMD is now and where it is heading in the future. That doesn't preclude the option to allow the kernel to take over and do what he wants. I agree that in KV we have a problem where we can't do a mid-wave preemption, so theoretically, a long running compute kernel can make things messy, but in Carrizo, we will have this ability. Having said that, it will only be through the CP H/W scheduling. So AMD is _not_ going to abandon H/W scheduling. You can dislike it, but this is the situation.

We was for the overall Linux community but maybe i should not pretend to talk for anyone interested in having a common standard.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

My point is that current hardware do not have approriate hardware support for preemption hence, current hardware should use ioctl to schedule job and AMD should think a bit more on commiting to a design and handwaving any hardware short coming as something that can be work around in the software. The pinning thing is broken by design, only way to work around it is through kernel cmd queue

scheduling that's a fact.

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Once hardware support proper preemption and allows to move around/evict buffer use on behalf of userspace command queue then we can allow userspace scheduling but until then my personnal opinion is that it should not be allowed and that people will have to pay the ioctl price which i proved to be small, because really if you 100K queue each with one job, i would not expect that all those 100K job will complete in less time than it takes to execute an ioctl ie by even if you do not have the ioctl delay what ever you

schedule will have to wait on previously submited jobs.

Quoted 24 lines

Quoted 24 lines

Quoted 11 lines

But Jerome, the core problem still remains in effect, even with your suggestion. If an application, either via userspace queue or via ioctl, submits a long-running kernel, than the CPU in general can't stop the GPU from running it. And if that kernel does while(1); than that's it, game's over, and no matter how you submitted the work. So I don't really see the big advantage in your proposal. Only in CZ we can stop this wave (by CP H/W scheduling only). What are you saying is basically I won't allow people to use compute on Linux KV system because it _may_ get the system stuck.

Quoted 8 lines

So even if I really wanted to, and I may agree with you theoretically on that, I can't fulfill your desire to make the "kernel being able to preempt at any time and be able to decrease or increase user queue priority so overall kernel is in charge of resources management and it can handle rogue client in proper fashion". Not in KV, and I guess not in CZ as well.

Oded

I do understand that but using kernel ioctl provide the same kind of control as we have now ie we can bind/unbind buffer on per command buffer submission basis, just like with current graphic or compute stuff.

Quoted 8 lines

Quoted 4 lines

Yes current graphic and compute stuff can launch a while and never return back and yes currently we have nothing against that but we should and solution would be simple just kill the gpu thread.

OK, so in that case, the kernel can simple unmap all the queues by simply writing an UNMAP_QUEUES packet to the HIQ. Even if the queues are userspace, they will not be mapped to the internal CP scheduler. Does that satisfy the kernel control level you want ?

This raises questions, what does happen to currently running thread when you unmap queue ? Do they keep running until done ? If not than this means this will break user application and those is not an acceptable solution.

Otherwise, infrastructre inside radeon would be needed to force this queue unmap on bo_pin failure so gfx pinning can be retry.

Also how do you cope with doorbell exhaustion ? Do you just plan to error out ?
In which case this is another DDOS vector but only affecting the gpu.

And there is many other questions that need answer, like my kernel memory map question because as of right now i assume that kfd allow any thread on the gpu to access any kernel memory.

Otherthings are how ill formated packet are handled by the hardware ? I do not see any mecanism to deal with SIGBUS or SIGFAULT.

Also it is a worrisome prospect of seeing resource management completely ignore for future AMD hardware. Kernel exist for a reason ! Kernel main purpose is to provide resource management if AMD fails to understand that, this is not looking good on long term and i expect none of the HSA technology will get momentum and i would certainly advocate against any use of it inside product i work on.

Cheers,
Jérôme

Quoted 12 lines

Oded

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

It might be better to add a drivers/gpu/drm/amd directory
and add common stuff there.

Given that this is not intended to be final HSA api AFAICT
then i would say this far better to avoid the whole kfd module

and add ioctl to radeon.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

This would avoid crazy communication btw radeon and kfd.

The whole aperture business needs some serious
explanation. Especialy as you want to use userspace
address there is nothing to prevent userspace program from
allocating things at address you reserve for lds, scratch,
... only sane way would be to move those lds, scratch inside

the virtual address reserved for kernel (see kernel memory map).

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 4 lines

The whole business of locking performance counter for
exclusive per process access is a big NO. Which leads me
to the questionable usefullness of user space command ring.

That's like saying: "Which leads me to the questionable usefulness of HSA". I find it analogous to a situation where a network maintainer nacking a driver for a network card, which is slower than a different network card. Doesn't seem reasonable this situation is would happen. He would still put both the drivers in the kernel because people

want to use the H/W and its features. So, I don't think this is a valid reason to NACK the driver.

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Let me rephrase, drop the the performance counter ioctl and modulo memory pinning i see no objection. In other word, i am not NACKING whole patchset i am NACKING the performance ioctl.

Again this is another argument for round trip to the kernel. As inside kernel you could properly do exclusive gpu counter access accross single user cmd buffer execution.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

I only see issues with that. First and foremost i would
need to see solid figures that kernel ioctl or syscall has
a higher an overhead that is measurable in any meaning
full way against a simple function call. I know the
userspace command ring is a big marketing features that
please ignorant userspace programmer. But really this only

brings issues and for absolutely not upside afaict.

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Really ? You think that doing a context switch to kernel space, with all its overhead, is _not_ more expansive than just calling a function in userspace which only puts a buffer on a

ring and writes a doorbell ?

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

I am saying the overhead is not that big and it probably will not matter in most usecase. For instance i did wrote the most useless kernel module that add two number through an ioctl
(http://people.freedesktop.org/~glisse/adder.tar) and it takes ~0.35microseconds with ioctl while function is ~0.025microseconds

so ioctl is 13 times slower.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Now if there is enough data that shows that a significant percentage of jobs submited to the GPU will take less that 0.35microsecond then yes userspace scheduling does make sense. But so far all we have is handwaving with no data to support any

facts.

Quoted 17 lines

Quoted 16 lines

Quoted 16 lines

Quoted 15 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Now if we want to schedule from userspace than you will need to do something about the pinning, something that gives control to kernel so that kernel can unpin when it wants and move object when it wants no matter what userspace is doing.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Quoted 4 lines

_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

So even if I really wanted to, and I may agree with you theoretically on that, I can't fulfill your desire to make the "kernel being able to preempt at any time and be able to decrease or increase user queue priority so overall kernel is in charge of resources management and it can handle rogue client in proper fashion". Not in KV, and I guess not in CZ as well.

Quoted 7 lines

Also it is a worrisome prospect of seeing resource management completely ignore for future AMD hardware. Kernel exist for a reason ! Kernel main purpose is to provide resource management if AMD fails to understand that, this is not looking good on long term and i expect none of the HSA technology will get momentum and i would certainly advocate against any use of it inside product i work on.

Hi Jerome;

I was following along until the above comment. It seems to be the exact opposite of what Oded has been saying, which is that future AMD hardware *does* have more capabilities for resource management and that we do have some capabilities today. Can you help me understand what the comment it was based on ?

Quoted 171 lines · Oded Gabbay

Quoted 170 lines · Jerome Glisse

Quoted 152 lines · Oded Gabbay

Quoted 132 lines · Jerome Glisse

Quoted 94 lines · Oded Gabbay

Quoted 93 lines · Jerome Glisse

Quoted 91 lines · Oded Gabbay

Quoted 73 lines · Jerome Glisse

Quoted 63 lines · Oded Gabbay

Quoted 62 lines · Christian König

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 44 lines · Jerome Glisse

Quoted 33 lines · Oded Gabbay

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series
restructured with a cleaner history and no totally-different-early-versions
of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them
are modifications to radeon driver and 18 of them include only amdkfd code.
There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under
drm/radeon/amdkfd. This move was done to emphasize the fact that this driver
is an AMD-only driver at this point. Having said that, we do foresee a
generic hsa framework being implemented in the future and in that case, we
will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to
keep it as a seperate driver from radeon. Therefore, the amdkfd code is
contained in its own folder. The amdkfd folder was put under the radeon
folder because the only AMD gfx driver in the Linux kernel at this point
is the radeon driver. Having said that, we will probably need to move it
(maybe to be directly under drm) after we integrate with additional AMD gfx
drivers.

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many
things that need more documentation espacialy as of right now there is
no userspace i can go look at.

So quick comments on some of your questions but first of all, thanks for the time you dedicated to review the code.

Quoted 4 lines

There few show stopper, biggest one is gpu memory pinning this is a big
no, that would need serious arguments for any hope of convincing me on
that side.

We only do gpu memory pinning for kernel objects. There are no userspace objects that are pinned on the gpu memory in our driver. If that is the case, is it still a show stopper ?

Quoted 9 lines

The kernel objects are:
- pipelines (4 per device)
- mqd per hiq (only 1 per device)
- mqd per userspace queue. On KV, we support up to 1K queues per process, for a total of 512K queues. Each mqd is 151 bytes, but the allocation is done in 256 alignment. So total *possible* memory is 128MB
- kernel queue (only 1 per device)
- fence address for kernel queue
- runlists for the CP (1 or 2 per device)

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Quoted 8 lines

Quoted 1 line

Christian.

Most of the pin downs are done on device initialization.
The "mqd per userspace" is done per userspace queue creation. However, as I said, it has an upper limit of 128MB on KV, and considering the 2G local memory, I think it is OK.
The runlists are also done on userspace queue creation/deletion, but we only have 1 or 2 runlists per device, so it is not that bad.

Quoted 3 lines

2G local memory ? You can not assume anything on userside configuration some one might build an hsa computer with 512M and still expect a functioning desktop.

First of all, I'm only considering Kaveri computer, not "hsa" computer. Second, I would imagine we can build some protection around it, like checking total local memory and limit number of queues based on some percentage of that total local memory. So, if someone will have only 512M, he will be able to open less queues.

Quoted 5 lines

I need to go look into what all this mqd is for, what it does and what it is about. But pinning is really bad and this is an issue with userspace command scheduling an issue that obviously AMD fails to take into account in design phase.

Maybe, but that is the H/W design non-the-less. We can't very well change the H/W.

Quoted 6 lines

Quoted 4 lines

You can not change the hardware but it is not an excuse to allow bad design to sneak in software to work around that. So i would rather penalize bad hardware design and have command submission in the kernel, until AMD fix its hardware to allow proper scheduling by the kernel and proper control by the kernel.

I'm sorry but I do *not* think this is a bad design. S/W scheduling in the kernel can not, IMO, scale well to 100K queues and 10K processes.

I am not advocating for having kernel decide down to the very last details. I am advocating for kernel being able to preempt at any time and be able to decrease or increase user queue priority so overall kernel is in charge of resources management and it can handle rogue client in proper fashion.

Quoted 4 lines

Quoted 4 lines

Because really where we want to go is having GPU closer to a CPU in term of scheduling capacity and once we get there we want the kernel to always be able to take over and do whatever it wants behind process back.

Quoted 9 lines

Who do you refer to when you say "we" ? AFAIK, the hw scheduling direction is where AMD is now and where it is heading in the future. That doesn't preclude the option to allow the kernel to take over and do what he wants. I agree that in KV we have a problem where we can't do a mid-wave preemption, so theoretically, a long running compute kernel can make things messy, but in Carrizo, we will have this ability. Having said that, it will only be through the CP H/W scheduling. So AMD is _not_ going to abandon H/W scheduling. You can dislike it, but this is the situation.

We was for the overall Linux community but maybe i should not pretend to talk for anyone interested in having a common standard.

My point is that current hardware do not have approriate hardware support for preemption hence, current hardware should use ioctl to schedule job and AMD should think a bit more on commiting to a design and handwaving any hardware short coming as something that can be work around in the software. The pinning thing is broken by design, only way to work around it is through kernel cmd queue scheduling that's a fact.

Quoted 8 lines

Once hardware support proper preemption and allows to move around/evict buffer use on behalf of userspace command queue then we can allow userspace scheduling but until then my personnal opinion is that it should not be allowed and that people will have to pay the ioctl price which i proved to be small, because really if you 100K queue each with one job, i would not expect that all those 100K job will complete in less time than it takes to execute an ioctl ie by even if you do not have the ioctl delay what ever you schedule will have to wait on previously submited jobs.

But Jerome, the core problem still remains in effect, even with your suggestion. If an application, either via userspace queue or via ioctl, submits a long-running kernel, than the CPU in general can't stop the GPU from running it. And if that kernel does while(1); than that's it, game's over, and no matter how you submitted the work. So I don't really see the big advantage in your proposal. Only in CZ we can stop this wave (by CP H/W scheduling only). What are you saying is basically I won't allow people to use compute on Linux KV system because it _may_ get the system stuck.

Quoted 8 lines

So even if I really wanted to, and I may agree with you theoretically on that, I can't fulfill your desire to make the "kernel being able to preempt at any time and be able to decrease or increase user queue priority so overall kernel is in charge of resources management and it can handle rogue client in proper fashion". Not in KV, and I guess not in CZ as well.

Oded

I do understand that but using kernel ioctl provide the same kind of control as we have now ie we can bind/unbind buffer on per command buffer submission basis, just like with current graphic or compute stuff.

Yes current graphic and compute stuff can launch a while and never return back and yes currently we have nothing against that but we should and solution would be simple just kill the gpu thread.

Quoted 4 lines

OK, so in that case, the kernel can simple unmap all the queues by simply writing an UNMAP_QUEUES packet to the HIQ. Even if the queues are userspace, they will not be mapped to the internal CP scheduler. Does that satisfy the kernel control level you want ?

This raises questions, what does happen to currently running thread when you unmap queue ? Do they keep running until done ? If not than this means this will break user application and those is not an acceptable solution.

Otherwise, infrastructre inside radeon would be needed to force this queue unmap on bo_pin failure so gfx pinning can be retry.

Also how do you cope with doorbell exhaustion ? Do you just plan to error out ? In which case this is another DDOS vector but only affecting the gpu.

And there is many other questions that need answer, like my kernel memory map question because as of right now i assume that kfd allow any thread on the gpu to access any kernel memory.

Otherthings are how ill formated packet are handled by the hardware ? I do not see any mecanism to deal with SIGBUS or SIGFAULT.

Also it is a worrisome prospect of seeing resource management completely ignore for future AMD hardware. Kernel exist for a reason ! Kernel main purpose is to provide resource management if AMD fails to understand that, this is not looking good on long term and i expect none of the HSA technology will get momentum and i would certainly advocate against any use of it inside product i work on.

Cheers,
Jérôme

Quoted 80 lines

Oded

Quoted 66 lines

Quoted 66 lines

Quoted 66 lines

Quoted 65 lines

Quoted 65 lines

Quoted 65 lines

Quoted 65 lines

Quoted 21 lines

Quoted 21 lines

Quoted 21 lines

Quoted 21 lines

It might be better to add a drivers/gpu/drm/amd directory and add common
stuff there.

Given that this is not intended to be final HSA api AFAICT then i would
say this far better to avoid the whole kfd module and add ioctl to radeon.
This would avoid crazy communication btw radeon and kfd.

The whole aperture business needs some serious explanation. Especialy as
you want to use userspace address there is nothing to prevent userspace
program from allocating things at address you reserve for lds, scratch,
... only sane way would be to move those lds, scratch inside the virtual
address reserved for kernel (see kernel memory map).

The whole business of locking performance counter for exclusive per process
access is a big NO. Which leads me to the questionable usefullness of user
space command ring.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

That's like saying: "Which leads me to the questionable usefulness of HSA". I find it analogous to a situation where a network maintainer nacking a driver for a network card, which is slower than a different network card. Doesn't seem reasonable this situation is would happen. He would still put both the drivers in the kernel because people want to use the H/W and its features. So, I don't think this is a valid reason to NACK the driver.

Let me rephrase, drop the the performance counter ioctl and modulo memory pinning i see no objection. In other word, i am not NACKING whole patchset i am NACKING the performance ioctl.

Again this is another argument for round trip to the kernel. As inside kernel you could properly do exclusive gpu counter access accross single user cmd buffer execution.

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 7 lines

I only see issues with that. First and foremost i would
need to see solid figures that kernel ioctl or syscall has a higher an
overhead that is measurable in any meaning full way against a simple
function call. I know the userspace command ring is a big marketing features
that please ignorant userspace programmer. But really this only brings issues
and for absolutely not upside afaict.

Really ? You think that doing a context switch to kernel space, with all its overhead, is _not_ more expansive than just calling a function in userspace which only puts a buffer on a ring and writes a doorbell ?

I am saying the overhead is not that big and it probably will not matter in most usecase. For instance i did wrote the most useless kernel module that add two number through an ioctl (http://people.freedesktop.org/~glisse/adder.tar) and it takes ~0.35microseconds with ioctl while function is ~0.025microseconds so ioctl is 13 times slower.

Now if there is enough data that shows that a significant percentage of jobs submited to the GPU will take less that 0.35microsecond then yes userspace scheduling does make sense. But so far all we have is handwaving with no data to support any facts.

Now if we want to schedule from userspace than you will need to do something about the pinning, something that gives control to kernel so that kernel can unpin when it wants and move object when it wants no matter what userspace is doing.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

But Jerome, the core problem still remains in effect, even with your suggestion. If an application, either via userspace queue or via ioctl, submits a long-running kernel, than the CPU in general can't stop the GPU from running it. And if that kernel does while(1); than that's it, game's over, and no matter how you submitted the work. So I don't really see the big advantage in your proposal. Only in CZ we can stop this wave (by CP H/W scheduling only). What are you saying is basically I won't allow people to use compute on Linux KV system because it _may_ get the system stuck.

So even if I really wanted to, and I may agree with you theoretically on that, I can't fulfill your desire to make the "kernel being able to preempt at any time and be able to decrease or increase user queue priority so overall kernel is in charge of resources management and it can handle rogue client in proper fashion". Not in KV, and I guess not in CZ as well.

Quoted 10 lines · Oded Gabbay

But Jerome, the core problem still remains in effect, even with your suggestion. If an application, either via userspace queue or via ioctl, submits a long-running kernel, than the CPU in general can't stop the GPU from running it. And if that kernel does while(1); than that's it, game's over, and no matter how you submitted the work. So I don't really see the big advantage in your proposal. Only in CZ we can stop this wave (by CP H/W scheduling only). What are you saying is basically I won't allow people to use compute on Linux KV system because it _may_ get the system stuck.

Quoted 6 lines

So even if I really wanted to, and I may agree with you theoretically on that, I can't fulfill your desire to make the "kernel being able to preempt at any time and be able to decrease or increase user queue priority so overall kernel is in charge of resources management and it can handle rogue client in proper fashion". Not in KV, and I guess not in CZ as well.

At least on intel the execlist stuff which is used for preemption can be used by both the cpu and the firmware scheduler. So we can actually preempt when doing cpu scheduling.

It sounds like current amd hw doesn't have any preemption at all. And without preemption I don't think we should ever consider to allow userspace to directly submit stuff to the hw and overload. Imo the kernel _must_ sit in between and reject clients that don't behave. Of course you can only ever react (worst case with a gpu reset, there's code floating around for that on intel-gfx), but at least you can do something.

If userspace has a direct submit path to the hw then this gets really tricky, if not impossible.
-Daniel

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 56 lines · Jerome Glisse

Quoted 40 lines · Oded Gabbay

Quoted 39 lines

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions
of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them
are modifications to radeon driver and 18 of them include only amdkfd code.
There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under
drm/radeon/amdkfd. This move was done to emphasize the fact that this driver
is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we
will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to
keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point
is the radeon driver. Having said that, we will probably need to move it
(maybe to be directly under drm) after we integrate with additional AMD gfx
drivers.

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Quoted 5 lines

Quoted 1 line

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

So quick comments on some of your questions but first of all, thanks for the time you dedicated to review the code.

Quoted 4 lines

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

We only do gpu memory pinning for kernel objects. There are no userspace objects that are pinned on the gpu memory in our driver. If that is the case, is it still a show stopper ?

Quoted 9 lines

The kernel objects are:
- pipelines (4 per device)
- mqd per hiq (only 1 per device)
- mqd per userspace queue. On KV, we support up to 1K queues per process, for a total of 512K queues. Each mqd is 151 bytes, but the allocation is done in 256 alignment. So total *possible* memory is 128MB
- kernel queue (only 1 per device)
- fence address for kernel queue
- runlists for the CP (1 or 2 per device)

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Quoted 71 lines · Christian König

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 56 lines · Jerome Glisse

Quoted 40 lines · Oded Gabbay

Quoted 39 lines

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions
of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them
are modifications to radeon driver and 18 of them include only amdkfd code.
There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under
drm/radeon/amdkfd. This move was done to emphasize the fact that this driver
is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we
will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to
keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point
is the radeon driver. Having said that, we will probably need to move it
(maybe to be directly under drm) after we integrate with additional AMD gfx
drivers.

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Quoted 5 lines

Quoted 1 line

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

So quick comments on some of your questions but first of all, thanks for the time you dedicated to review the code.

Quoted 4 lines

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

We only do gpu memory pinning for kernel objects. There are no userspace objects that are pinned on the gpu memory in our driver. If that is the case, is it still a show stopper ?

Quoted 9 lines

The kernel objects are:
- pipelines (4 per device)
- mqd per hiq (only 1 per device)
- mqd per userspace queue. On KV, we support up to 1K queues per process, for a total of 512K queues. Each mqd is 151 bytes, but the allocation is done in 256 alignment. So total *possible* memory is 128MB
- kernel queue (only 1 per device)
- fence address for kernel queue
- runlists for the CP (1 or 2 per device)

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

Quoted 2 lines

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Aside, i915 perspective again (i.e. how we solved this): When scheduling away from contexts we unpin them and put them into the lru. And in the shrinker we have a last-ditch callback to switch to a default context (since you can't ever have no context once you've started) which means we can evict any context object if it's getting in the way.

We must do that since the contexts have to be in global gtt, which is shared for scanouts. So fragmenting that badly with lots of context objects and other stuff is a no-go, since that means we'll start to fail pageflips.

I don't know whether ttm has a ready-made concept for such opportunistically pinned stuff. I guess you could wire up the "switch to dflt context" action to the evict/move function if ttm wants to get rid of the currently used hw context.

Oh and: This is another reason for letting the kernel schedule contexts, since you can't do this defrag trick if the gpu does all the scheduling itself.
-Daniel

Signature · 7 lines

Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Quoted 72 lines · Daniel Vetter

Quoted 71 lines · Christian König

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 56 lines · Jerome Glisse

Quoted 40 lines · Oded Gabbay

Quoted 39 lines

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions
of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them
are modifications to radeon driver and 18 of them include only amdkfd code.
There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under
drm/radeon/amdkfd. This move was done to emphasize the fact that this driver
is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we
will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to
keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point
is the radeon driver. Having said that, we will probably need to move it
(maybe to be directly under drm) after we integrate with additional AMD gfx
drivers.

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Quoted 5 lines

Quoted 1 line

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

So quick comments on some of your questions but first of all, thanks for the time you dedicated to review the code.

Quoted 4 lines

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

We only do gpu memory pinning for kernel objects. There are no userspace objects that are pinned on the gpu memory in our driver. If that is the case, is it still a show stopper ?

Quoted 9 lines

The kernel objects are:
- pipelines (4 per device)
- mqd per hiq (only 1 per device)
- mqd per userspace queue. On KV, we support up to 1K queues per process, for a total of 512K queues. Each mqd is 151 bytes, but the allocation is done in 256 alignment. So total *possible* memory is 128MB
- kernel queue (only 1 per device)
- fence address for kernel queue
- runlists for the CP (1 or 2 per device)

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

Quoted 8 lines

Quoted 2 lines

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Aside, i915 perspective again (i.e. how we solved this): When scheduling away from contexts we unpin them and put them into the lru. And in the shrinker we have a last-ditch callback to switch to a default context (since you can't ever have no context once you've started) which means we can evict any context object if it's getting in the way.

So Intel hardware report through some interrupt or some channel when it is not using a context ? ie kernel side get notification when some user context is done executing ?

The issue with radeon hardware AFAICT is that the hardware do not report any thing about the userspace context running ie you do not get notification when a context is not use. Well AFAICT. Maybe hardware do provide that.

Like the VMID is a limited resources so you have to dynamicly bind them so maybe we can only allocate pinned buffer for each VMID and then when binding a PASID to a VMID it also copy back pinned buffer to pasid unpinned copy.

Quoted 82 lines · Jerome Glisse

Quoted 72 lines · Daniel Vetter

Quoted 71 lines · Christian König

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 56 lines · Jerome Glisse

Quoted 40 lines · Oded Gabbay

Quoted 39 lines

Forgot to cc mailing list on cover letter. Sorry.

As a continuation to the existing discussion, here is a v2 patch series restructured with a cleaner history and no totally-different-early-versions
of the code.

Instead of 83 patches, there are now a total of 25 patches, where 5 of them
are modifications to radeon driver and 18 of them include only amdkfd code.
There is no code going away or even modified between patches, only added.

The driver was renamed from radeon_kfd to amdkfd and moved to reside under
drm/radeon/amdkfd. This move was done to emphasize the fact that this driver
is an AMD-only driver at this point. Having said that, we do foresee a generic hsa framework being implemented in the future and in that case, we
will adjust amdkfd to work within that framework.

As the amdkfd driver should support multiple AMD gfx drivers, we want to
keep it as a seperate driver from radeon. Therefore, the amdkfd code is contained in its own folder. The amdkfd folder was put under the radeon folder because the only AMD gfx driver in the Linux kernel at this point
is the radeon driver. Having said that, we will probably need to move it
(maybe to be directly under drm) after we integrate with additional AMD gfx
drivers.

For people who like to review using git, the v2 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2

Quoted 5 lines

Quoted 1 line

Written by Oded Gabbayh <[email protected]>

So quick comments before i finish going over all patches. There is many things that need more documentation espacialy as of right now there is no userspace i can go look at.

So quick comments on some of your questions but first of all, thanks for the time you dedicated to review the code.

Quoted 4 lines

There few show stopper, biggest one is gpu memory pinning this is a big no, that would need serious arguments for any hope of convincing me on that side.

We only do gpu memory pinning for kernel objects. There are no userspace objects that are pinned on the gpu memory in our driver. If that is the case, is it still a show stopper ?

Quoted 9 lines

The kernel objects are:
- pipelines (4 per device)
- mqd per hiq (only 1 per device)
- mqd per userspace queue. On KV, we support up to 1K queues per process, for a total of 512K queues. Each mqd is 151 bytes, but the allocation is done in 256 alignment. So total *possible* memory is 128MB
- kernel queue (only 1 per device)
- fence address for kernel queue
- runlists for the CP (1 or 2 per device)

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

Quoted 8 lines

Quoted 2 lines

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Aside, i915 perspective again (i.e. how we solved this): When scheduling away from contexts we unpin them and put them into the lru. And in the shrinker we have a last-ditch callback to switch to a default context (since you can't ever have no context once you've started) which means we can evict any context object if it's getting in the way.

Quoted 3 lines

So Intel hardware report through some interrupt or some channel when it is not using a context ? ie kernel side get notification when some user context is done executing ?

Yes, as long as we do the scheduling with the cpu we get interrupts for context switches. The mechanic is already published in the execlist patches currently floating around. We get a special context switch interrupt.

But we have this unpin logic already on the current code where we switch contexts through in-line cs commands from the kernel. There we obviously use the normal batch completion events.

Quoted 3 lines

The issue with radeon hardware AFAICT is that the hardware do not report any thing about the userspace context running ie you do not get notification when a context is not use. Well AFAICT. Maybe hardware do provide that.

I'm not sure whether we can do the same trick with the hw scheduler. But then unpinning hw contexts will drain the pipeline anyway, so I guess we can just stop feeding the hw scheduler until it runs dry. And then unpin and evict.

Quoted 4 lines

Like the VMID is a limited resources so you have to dynamicly bind them so maybe we can only allocate pinned buffer for each VMID and then when binding a PASID to a VMID it also copy back pinned buffer to pasid unpinned copy.

Yeah, pasid assignment will be fun. Not sure whether Jesse's patches will do this already. We _do_ already have fun with ctx id assigments though since we move them around (and the hw id is the ggtt address afaik). So we need to remap them already. Not sure on the details for pasid mapping, iirc it's a separate field somewhere in the context struct. Jesse knows the details.
-Daniel

Quoted 4 lines

I'm not sure whether we can do the same trick with the hw scheduler. But then unpinning hw contexts will drain the pipeline anyway, so I guess we can just stop feeding the hw scheduler until it runs dry. And then unpin and evict.

So, I'm afraid but we can't do this for AMD Kaveri because:

Quoted 5 lines · Oded Gabbay

Quoted 4 lines

I'm not sure whether we can do the same trick with the hw scheduler. But then unpinning hw contexts will drain the pipeline anyway, so I guess we can just stop feeding the hw scheduler until it runs dry. And then unpin and evict.

So, I'm afraid but we can't do this for AMD Kaveri because:

Well as long as you can drain the hw scheduler queue (and you can do that, worst case you have to unmap all the doorbells and other stuff to intercept further submission from userspace) you can evict stuff.

And if we don't want compute to be a denial of service on the display side of the driver we need this ability. Now if you go through an ioctl instead of the doorbell (I agree with Jerome here, the doorbell should be supported by benchmarks on linux) this gets a bit easier, but it's not a requirement really.
-Daniel

Quoted 10 lines · Daniel Vetter

Quoted 5 lines · Oded Gabbay

Quoted 4 lines

I'm not sure whether we can do the same trick with the hw scheduler. But then unpinning hw contexts will drain the pipeline anyway, so I guess we can just stop feeding the hw scheduler until it runs dry. And then unpin and evict.

So, I'm afraid but we can't do this for AMD Kaveri because:

Well as long as you can drain the hw scheduler queue (and you can do that, worst case you have to unmap all the doorbells and other stuff to intercept further submission from userspace) you can evict stuff.

I can't drain the hw scheduler queue, as I can't do mid-wave preemption. Moreover, if I use the dequeue request register to preempt a queue during a dispatch it may be that some waves (wave groups actually) of the dispatch have not yet been created, and when I reactivate the mqd, they should be created but are not. However, this works fine if you use the HIQ. the CP ucode correctly saves and restores the state of an outstanding dispatch. I don't think we have access to the state from software at all, so it's not a bug, it is "as designed".

Quoted 7 lines

And if we don't want compute to be a denial of service on the display side of the driver we need this ability. Now if you go through an ioctl instead of the doorbell (I agree with Jerome here, the doorbell should be supported by benchmarks on linux) this gets a bit easier, but it's not a requirement really.
-Daniel

On KV, we have the theoretical option of DOS on the display side as we can't do a mid-wave preemption. On CZ, we won't have this problem.

Oded

Quoted 12 lines · Oded Gabbay

Quoted 10 lines · Daniel Vetter

Quoted 5 lines · Oded Gabbay

Quoted 4 lines

I'm not sure whether we can do the same trick with the hw scheduler. But then unpinning hw contexts will drain the pipeline anyway, so I guess we can just stop feeding the hw scheduler until it runs dry. And then unpin and evict.

So, I'm afraid but we can't do this for AMD Kaveri because:

Well as long as you can drain the hw scheduler queue (and you can do that, worst case you have to unmap all the doorbells and other stuff to intercept further submission from userspace) you can evict stuff.

Quoted 9 lines

I can't drain the hw scheduler queue, as I can't do mid-wave preemption. Moreover, if I use the dequeue request register to preempt a queue during a dispatch it may be that some waves (wave groups actually) of the dispatch have not yet been created, and when I reactivate the mqd, they should be created but are not. However, this works fine if you use the HIQ. the CP ucode correctly saves and restores the state of an outstanding dispatch. I don't think we have access to the state from software at all, so it's not a bug, it is "as designed".

I think here Daniel is suggesting to unmapp the doorbell page, and track each write made by userspace to it and while unmapped wait for the gpu to drain or use some kind of fence on a special queue. Once GPU is drain we can move pinned buffer, then remap the doorbell and update it to the last value written by userspace which will resume execution to the next job.

Quoted 23 lines · Jerome Glisse

Quoted 12 lines · Oded Gabbay

Quoted 10 lines · Daniel Vetter

Quoted 5 lines · Oded Gabbay

Quoted 4 lines

I'm not sure whether we can do the same trick with the hw scheduler. But then unpinning hw contexts will drain the pipeline anyway, so I guess we can just stop feeding the hw scheduler until it runs dry. And then unpin and evict.

So, I'm afraid but we can't do this for AMD Kaveri because:

Well as long as you can drain the hw scheduler queue (and you can do that, worst case you have to unmap all the doorbells and other stuff to intercept further submission from userspace) you can evict stuff.

Quoted 9 lines

I can't drain the hw scheduler queue, as I can't do mid-wave preemption. Moreover, if I use the dequeue request register to preempt a queue during a dispatch it may be that some waves (wave groups actually) of the dispatch have not yet been created, and when I reactivate the mqd, they should be created but are not. However, this works fine if you use the HIQ. the CP ucode correctly saves and restores the state of an outstanding dispatch. I don't think we have access to the state from software at all, so it's not a bug, it is "as designed".

Quoted 5 lines

I think here Daniel is suggesting to unmapp the doorbell page, and track each write made by userspace to it and while unmapped wait for the gpu to drain or use some kind of fence on a special queue. Once GPU is drain we can move pinned buffer, then remap the doorbell and update it to the last value written by userspace which will resume execution to the next job.

Exactly, just prevent userspace from submitting more. And if you have misbehaving userspace that submits too much, reset the gpu and tell it that you're sorry but won't schedule any more work.

We have this already in i915 (since like all other gpus we're not preempting right now) and it works. There's some code floating around to even restrict the reset to _just_ the offending submission context, with nothing else getting corrupted.

You can do all this with the doorbells and unmapping them, but it's a pain. Much easier if you have a real ioctl, and I haven't seen anyone with perf data indicating that an ioctl would be too much overhead on linux. Neither in this thread nor internally here at intel.

Quoted 39 lines · Daniel Vetter

Quoted 23 lines · Jerome Glisse

Quoted 12 lines · Oded Gabbay

Quoted 10 lines · Daniel Vetter

Quoted 5 lines · Oded Gabbay

Quoted 4 lines

I'm not sure whether we can do the same trick with the hw scheduler. But then unpinning hw contexts will drain the pipeline anyway, so I guess we can just stop feeding the hw scheduler until it runs dry. And then unpin and evict.

So, I'm afraid but we can't do this for AMD Kaveri because:

Well as long as you can drain the hw scheduler queue (and you can do that, worst case you have to unmap all the doorbells and other stuff to intercept further submission from userspace) you can evict stuff.

Quoted 9 lines

I can't drain the hw scheduler queue, as I can't do mid-wave preemption. Moreover, if I use the dequeue request register to preempt a queue during a dispatch it may be that some waves (wave groups actually) of the dispatch have not yet been created, and when I reactivate the mqd, they should be created but are not. However, this works fine if you use the HIQ. the CP ucode correctly saves and restores the state of an outstanding dispatch. I don't think we have access to the state from software at all, so it's not a bug, it is "as designed".

Quoted 5 lines

I think here Daniel is suggesting to unmapp the doorbell page, and track each write made by userspace to it and while unmapped wait for the gpu to drain or use some kind of fence on a special queue. Once GPU is drain we can move pinned buffer, then remap the doorbell and update it to the last value written by userspace which will resume execution to the next job.

Exactly, just prevent userspace from submitting more. And if you have misbehaving userspace that submits too much, reset the gpu and tell it that you're sorry but won't schedule any more work.

We have this already in i915 (since like all other gpus we're not preempting right now) and it works. There's some code floating around to even restrict the reset to _just_ the offending submission context, with nothing else getting corrupted.

Quoted 4 lines

You can do all this with the doorbells and unmapping them, but it's a pain. Much easier if you have a real ioctl, and I haven't seen anyone with perf data indicating that an ioctl would be too much overhead on linux. Neither in this thread nor internally here at intel.

Aside: Another reason why the ioctl is better than the doorbell is integration with other drivers. Yeah I know this is about compute, but sooner or later someone will want to e.g. post-proc video frames between the v4l capture device and the gpu mpeg encoder. Or something else fancy.

Then you want to be able to somehow integrate into a cross-driver fence framework like android syncpts, and you can't do that without an ioctl for the compute submissions.
-Daniel

Quoted 23 lines · Jerome Glisse

Quoted 12 lines · Oded Gabbay

Quoted 10 lines · Daniel Vetter

Quoted 5 lines · Oded Gabbay

Quoted 4 lines

I'm not sure whether we can do the same trick with the hw scheduler. But then unpinning hw contexts will drain the pipeline anyway, so I guess we can just stop feeding the hw scheduler until it runs dry. And then unpin and evict.

So, I'm afraid but we can't do this for AMD Kaveri because:

Well as long as you can drain the hw scheduler queue (and you can do that, worst case you have to unmap all the doorbells and other stuff to intercept further submission from userspace) you can evict stuff.

Quoted 9 lines

I can't drain the hw scheduler queue, as I can't do mid-wave preemption. Moreover, if I use the dequeue request register to preempt a queue during a dispatch it may be that some waves (wave groups actually) of the dispatch have not yet been created, and when I reactivate the mqd, they should be created but are not. However, this works fine if you use the HIQ. the CP ucode correctly saves and restores the state of an outstanding dispatch. I don't think we have access to the state from software at all, so it's not a bug, it is "as designed".

Quoted 5 lines

I think here Daniel is suggesting to unmapp the doorbell page, and track each write made by userspace to it and while unmapped wait for the gpu to drain or use some kind of fence on a special queue. Once GPU is drain we can move pinned buffer, then remap the doorbell and update it to the last value written by userspace which will resume execution to the next job.

Exactly, just prevent userspace from submitting more. And if you have misbehaving userspace that submits too much, reset the gpu and tell it that you're sorry but won't schedule any more work.

We have this already in i915 (since like all other gpus we're not preempting right now) and it works. There's some code floating around to even restrict the reset to _just_ the offending submission context, with nothing else getting corrupted.

You can do all this with the doorbells and unmapping them, but it's a pain. Much easier if you have a real ioctl, and I haven't seen anyone with perf data indicating that an ioctl would be too much overhead on linux. Neither in this thread nor internally here at intel.
-Daniel

Quoted 3 lines

Exactly, just prevent userspace from submitting more. And if you have misbehaving userspace that submits too much, reset the gpu and tell it that you're sorry but won't schedule any more work.

I'm not sure how you intend to know if a userspace misbehaves or not. Can you elaborate ?

Quoted 4 lines · Oded Gabbay

Quoted 3 lines

Exactly, just prevent userspace from submitting more. And if you have misbehaving userspace that submits too much, reset the gpu and tell it that you're sorry but won't schedule any more work.

Quoted 2 lines

I'm not sure how you intend to know if a userspace misbehaves or not. Can you elaborate ?

Well that's mostly policy, currently in i915 we only have a check for hangs, and if userspace hangs a bit too often then we stop it. I guess you can do that with the queue unmapping you've describe in reply to Jerome's mail.

Quoted 4 lines · Oded Gabbay

Quoted 3 lines

Exactly, just prevent userspace from submitting more. And if you have misbehaving userspace that submits too much, reset the gpu and tell it that you're sorry but won't schedule any more work.

Quoted 2 lines

I'm not sure how you intend to know if a userspace misbehaves or not. Can you elaborate ?

Well that's mostly policy, currently in i915 we only have a check for hangs, and if userspace hangs a bit too often then we stop it. I guess you can do that with the queue unmapping you've describe in reply to Jerome's mail.
-Daniel

Quoted 8 lines · Daniel Vetter

Quoted 6 lines · Oded Gabbay

Quoted 3 lines

Exactly, just prevent userspace from submitting more. And if you have misbehaving userspace that submits too much, reset the gpu and tell it that you're sorry but won't schedule any more work.

I'm not sure how you intend to know if a userspace misbehaves or not. Can you elaborate ?

Quoted 6 lines

Well that's mostly policy, currently in i915 we only have a check for hangs, and if userspace hangs a bit too often then we stop it. I guess you can do that with the queue unmapping you've describe in reply to Jerome's mail.
-Daniel

What do you mean by hang ? Like the tdr mechanism in Windows (checks if a gpu job takes more than 2 seconds, I think, and if so, terminates the job).

Quoted 15 lines · Oded Gabbay

Quoted 14 lines · Daniel Vetter

Quoted 6 lines · Oded Gabbay

Quoted 3 lines

Exactly, just prevent userspace from submitting more. And if you have misbehaving userspace that submits too much, reset the gpu and tell it that you're sorry but won't schedule any more work.

I'm not sure how you intend to know if a userspace misbehaves or not. Can you elaborate ?

Well that's mostly policy, currently in i915 we only have a check for hangs, and if userspace hangs a bit too often then we stop it. I guess you can do that with the queue unmapping you've describe in reply to Jerome's mail.
-Daniel

Quoted 2 lines

What do you mean by hang ? Like the tdr mechanism in Windows (checks if a gpu job takes more than 2 seconds, I think, and if so, terminates the job).

Essentially yes. But we also have some hw features to kill jobs quicker, e.g. for media workloads.
-Daniel

Quoted 16 lines · Oded Gabbay

Quoted 15 lines · Daniel Vetter

Quoted 14 lines · Oded Gabbay

Quoted 6 lines

Quoted 3 lines

Exactly, just prevent userspace from submitting more. And if you have misbehaving userspace that submits too much, reset the gpu and tell it that you're sorry but won't schedule any more work.

I'm not sure how you intend to know if a userspace misbehaves or not. Can you elaborate ?

Well that's mostly policy, currently in i915 we only have a check for hangs, and if userspace hangs a bit too often then we stop it. I guess you can do that with the queue unmapping you've describe in reply to Jerome's mail.
-Daniel

Quoted 7 lines

Quoted 2 lines

What do you mean by hang ? Like the tdr mechanism in Windows (checks if a gpu job takes more than 2 seconds, I think, and if so, terminates the job).

Essentially yes. But we also have some hw features to kill jobs quicker, e.g. for media workloads.
-Daniel

Yeah, so this is what I'm talking about when I say that you and Jerome come from a graphics POV and amdkfd come from a compute POV, no offense intended.

For compute jobs, we simply can't use this logic to terminate jobs. Graphics are mostly Real-Time while compute jobs can take from a few ms to a few hours!!! And I'm not talking about an entire application runtime but on a single submission of jobs by the userspace app. We have tests with jobs that take between 20-30 minutes to complete. In theory, we can even imagine a compute job which takes 1 or 2 days (on larger APUs).

Now, I understand the question of how do we prevent the compute job from monopolizing the GPU, and internally here we have some ideas that we will probably share in the next few days, but my point is that I don't think we can terminate a compute job because it is running for more than x seconds. It is like you would terminate a CPU process which runs more than x seconds.

I think this is a *very* important discussion (detecting a misbehaved compute process) and I would like to continue it, but I don't think moving the job submission from userspace control to kernel control will solve this core problem.

Oded

-----Original Message-----
From: Christian König [mailto:[email protected]]
Sent: Wednesday, July 23, 2014 3:04 AM
To: Gabbay, Oded; Jerome Glisse; David Airlie; Alex Deucher; Andrew Morton; Bridgman, John; Joerg Roedel; Lewycky, Andrew; Daenzer, Michel; Goz, Ben; Skidanov, Alexey; [email protected]; dri- [email protected]; linux-mm; Sellek, Tom
Subject: Re: [PATCH v2 00/25] AMDKFD kernel driver

Am 23.07.2014 08:50, schrieb Oded Gabbay:

Quoted 4 lines · Daniel Vetter

Quoted 3 lines · Oded Gabbay

Quoted 2 lines · Daniel Vetter

Quoted 1 line

On Tue, Jul 22, 2014 at 10:19 AM, Oded Gabbay

<[email protected]>

Quoted 35 lines

Quoted 14 lines

Quoted 14 lines

Quoted 14 lines

Quoted 6 lines · wrote:

Quoted 3 lines

Exactly, just prevent userspace from submitting more. And if you have misbehaving userspace that submits too much, reset the gpu and tell it that you're sorry but won't schedule any more work.

I'm not sure how you intend to know if a userspace misbehaves or not. Can you elaborate ?

Well that's mostly policy, currently in i915 we only have a check for hangs, and if userspace hangs a bit too often then we stop it. I guess you can do that with the queue unmapping you've describe in reply to Jerome's mail.
-Daniel

Quoted 8 lines

Quoted 3 lines

What do you mean by hang ? Like the tdr mechanism in Windows (checks if a gpu job takes more than 2 seconds, I think, and if so, terminates the job).

Essentially yes. But we also have some hw features to kill jobs quicker, e.g. for media workloads.
-Daniel

Yeah, so this is what I'm talking about when I say that you and Jerome come from a graphics POV and amdkfd come from a compute POV, no offense intended.

For compute jobs, we simply can't use this logic to terminate jobs. Graphics are mostly Real-Time while compute jobs can take from a few ms to a few hours!!! And I'm not talking about an entire application runtime but on a single submission of jobs by the userspace app. We have tests with jobs that take between 20-30 minutes to complete. In theory, we can even imagine a compute job which takes 1 or 2 days (on larger APUs).

Quoted 6 lines

Now, I understand the question of how do we prevent the compute job from monopolizing the GPU, and internally here we have some ideas that we will probably share in the next few days, but my point is that I don't think we can terminate a compute job because it is running for more than x seconds. It is like you would terminate a CPU process which runs more than x seconds.

Yeah that's why one of the first things I've did was making the timeout configurable in the radeon module.

But it doesn't necessary needs be a timeout, we should also kill a running job submission if the CPU process associated with the job is killed.

Quoted 4 lines

I think this is a *very* important discussion (detecting a misbehaved compute process) and I would like to continue it, but I don't think moving the job submission from userspace control to kernel control will solve this core problem.

We need to get this topic solved, otherwise the driver won't make it upstream. Allowing userpsace to monopolizing resources either memory, CPU or GPU time or special things like counters etc... is a strict no go for a kernel module.

I agree that moving the job submission from userpsace to kernel wouldn't solve this problem. As Daniel and I pointed out now multiple times it's rather easily possible to prevent further job submissions from userspace, in the worst case by unmapping the doorbell page.

Moving it to an IOCTL would just make it a bit less complicated.

Christian.

Quoted 2 lines

Oded

Am 23.07.2014 08:50, schrieb Oded Gabbay:

Quoted 42 lines · Daniel Vetter

Quoted 20 lines · Oded Gabbay

Quoted 19 lines · Daniel Vetter

Quoted 18 lines

Quoted 9 lines · Oded Gabbay

Quoted 5 lines

Exactly, just prevent userspace from submitting more. And if you have
misbehaving userspace that submits too much, reset the gpu and tell it
that you're sorry but won't schedule any more work.

I'm not sure how you intend to know if a userspace misbehaves or not. Can
you elaborate ?

Well that's mostly policy, currently in i915 we only have a check for hangs, and if userspace hangs a bit too often then we stop it. I guess you can do that with the queue unmapping you've describe in reply to Jerome's mail.
-Daniel

Quoted 9 lines

Quoted 4 lines

What do you mean by hang ? Like the tdr mechanism in Windows (checks if a
gpu job takes more than 2 seconds, I think, and if so, terminates the job).

Essentially yes. But we also have some hw features to kill jobs quicker, e.g. for media workloads.
-Daniel

Yeah, so this is what I'm talking about when I say that you and Jerome come from a graphics POV and amdkfd come from a compute POV, no offense intended.

For compute jobs, we simply can't use this logic to terminate jobs. Graphics are mostly Real-Time while compute jobs can take from a few ms to a few hours!!! And I'm not talking about an entire application runtime but on a single submission of jobs by the userspace app. We have tests with jobs that take between 20-30 minutes to complete. In theory, we can even imagine a compute job which takes 1 or 2 days (on larger APUs).

Quoted 6 lines

Now, I understand the question of how do we prevent the compute job from monopolizing the GPU, and internally here we have some ideas that we will probably share in the next few days, but my point is that I don't think we can terminate a compute job because it is running for more than x seconds. It is like you would terminate a CPU process which runs more than x seconds.

Yeah that's why one of the first things I've did was making the timeout configurable in the radeon module.

But it doesn't necessary needs be a timeout, we should also kill a running job submission if the CPU process associated with the job is killed.

Quoted 4 lines

I think this is a *very* important discussion (detecting a misbehaved compute process) and I would like to continue it, but I don't think moving the job submission from userspace control to kernel control will solve this core problem.

We need to get this topic solved, otherwise the driver won't make it upstream. Allowing userpsace to monopolizing resources either memory, CPU or GPU time or special things like counters etc... is a strict no go for a kernel module.

I agree that moving the job submission from userpsace to kernel wouldn't solve this problem. As Daniel and I pointed out now multiple times it's rather easily possible to prevent further job submissions from userspace, in the worst case by unmapping the doorbell page.

Moving it to an IOCTL would just make it a bit less complicated.

Quoted 66 lines · Christian König

Am 23.07.2014 08:50, schrieb Oded Gabbay:

Quoted 42 lines · Daniel Vetter

Quoted 20 lines · Oded Gabbay

Quoted 19 lines · Daniel Vetter

Quoted 18 lines

Quoted 9 lines · Oded Gabbay

Quoted 5 lines

Exactly, just prevent userspace from submitting more. And if you have
misbehaving userspace that submits too much, reset the gpu and tell it
that you're sorry but won't schedule any more work.

I'm not sure how you intend to know if a userspace misbehaves or not. Can
you elaborate ?

Well that's mostly policy, currently in i915 we only have a check for hangs, and if userspace hangs a bit too often then we stop it. I guess you can do that with the queue unmapping you've describe in reply to Jerome's mail.
-Daniel

Quoted 9 lines

Quoted 4 lines

What do you mean by hang ? Like the tdr mechanism in Windows (checks if a
gpu job takes more than 2 seconds, I think, and if so, terminates the job).

Essentially yes. But we also have some hw features to kill jobs quicker, e.g. for media workloads.
-Daniel

Yeah, so this is what I'm talking about when I say that you and Jerome come from a graphics POV and amdkfd come from a compute POV, no offense intended.

For compute jobs, we simply can't use this logic to terminate jobs. Graphics are mostly Real-Time while compute jobs can take from a few ms to a few hours!!! And I'm not talking about an entire application runtime but on a single submission of jobs by the userspace app. We have tests with jobs that take between 20-30 minutes to complete. In theory, we can even imagine a compute job which takes 1 or 2 days (on larger APUs).

Quoted 6 lines

Now, I understand the question of how do we prevent the compute job from monopolizing the GPU, and internally here we have some ideas that we will probably share in the next few days, but my point is that I don't think we can terminate a compute job because it is running for more than x seconds. It is like you would terminate a CPU process which runs more than x seconds.

Yeah that's why one of the first things I've did was making the timeout configurable in the radeon module.

But it doesn't necessary needs be a timeout, we should also kill a running job submission if the CPU process associated with the job is killed.

Quoted 4 lines

I think this is a *very* important discussion (detecting a misbehaved compute process) and I would like to continue it, but I don't think moving the job submission from userspace control to kernel control will solve this core problem.

We need to get this topic solved, otherwise the driver won't make it upstream. Allowing userpsace to monopolizing resources either memory, CPU or GPU time or special things like counters etc... is a strict no go for a kernel module.

Quoted 7 lines

I agree that moving the job submission from userpsace to kernel wouldn't solve this problem. As Daniel and I pointed out now multiple times it's rather easily possible to prevent further job submissions from userspace, in the worst case by unmapping the doorbell page.

Moving it to an IOCTL would just make it a bit less complicated.

It is not only complexity, my main concern is not really the amount of memory pinned (well it would be if it was vram which by the way you need to remove the api that allow to allocate vram just so that it clearly shows that vram is not allowed).

Issue is with GPU address space fragmentation, new process hsa queue might be allocated in middle of gtt space and stays there for so long that i will forbid any big buffer to be bind to gtt. Thought with virtual address space for graphics this is less of an issue and only the kernel suffer but still it might block the kernel from evicting some VRAM because i can not bind a system buffer big enough to GTT because some GTT space is taken by some HSA queue.

To mitigate this at very least, you need to implement special memory allocation inside ttm and radeon to force this per queue to be allocate for instance from top of GTT space. Like reserve top 8M of GTT and have it grow/shrink depending on number of queue.

Quoted 87 lines · Jerome Glisse

Quoted 66 lines · Christian König

Am 23.07.2014 08:50, schrieb Oded Gabbay:

Quoted 42 lines · Daniel Vetter

Quoted 20 lines · Oded Gabbay

Quoted 19 lines · Daniel Vetter

Quoted 18 lines

Quoted 9 lines · Oded Gabbay

Quoted 5 lines

Exactly, just prevent userspace from submitting more. And if you have
misbehaving userspace that submits too much, reset the gpu and tell it
that you're sorry but won't schedule any more work.

I'm not sure how you intend to know if a userspace misbehaves or not. Can
you elaborate ?

Well that's mostly policy, currently in i915 we only have a check for hangs, and if userspace hangs a bit too often then we stop it. I guess you can do that with the queue unmapping you've describe in reply to Jerome's mail.
-Daniel

Quoted 9 lines

Quoted 4 lines

What do you mean by hang ? Like the tdr mechanism in Windows (checks if a
gpu job takes more than 2 seconds, I think, and if so, terminates the job).

Essentially yes. But we also have some hw features to kill jobs quicker, e.g. for media workloads.
-Daniel

Yeah, so this is what I'm talking about when I say that you and Jerome come from a graphics POV and amdkfd come from a compute POV, no offense intended.

For compute jobs, we simply can't use this logic to terminate jobs. Graphics are mostly Real-Time while compute jobs can take from a few ms to a few hours!!! And I'm not talking about an entire application runtime but on a single submission of jobs by the userspace app. We have tests with jobs that take between 20-30 minutes to complete. In theory, we can even imagine a compute job which takes 1 or 2 days (on larger APUs).

Quoted 6 lines

Now, I understand the question of how do we prevent the compute job from monopolizing the GPU, and internally here we have some ideas that we will probably share in the next few days, but my point is that I don't think we can terminate a compute job because it is running for more than x seconds. It is like you would terminate a CPU process which runs more than x seconds.

Yeah that's why one of the first things I've did was making the timeout configurable in the radeon module.

But it doesn't necessary needs be a timeout, we should also kill a running job submission if the CPU process associated with the job is killed.

Quoted 4 lines

I think this is a *very* important discussion (detecting a misbehaved compute process) and I would like to continue it, but I don't think moving the job submission from userspace control to kernel control will solve this core problem.

We need to get this topic solved, otherwise the driver won't make it upstream. Allowing userpsace to monopolizing resources either memory, CPU or GPU time or special things like counters etc... is a strict no go for a kernel module.

Quoted 7 lines

I agree that moving the job submission from userpsace to kernel wouldn't solve this problem. As Daniel and I pointed out now multiple times it's rather easily possible to prevent further job submissions from userspace, in the worst case by unmapping the doorbell page.

Moving it to an IOCTL would just make it a bit less complicated.

It is not only complexity, my main concern is not really the amount of memory pinned (well it would be if it was vram which by the way you need to remove the api that allow to allocate vram just so that it clearly shows that vram is not allowed).

Issue is with GPU address space fragmentation, new process hsa queue might be allocated in middle of gtt space and stays there for so long that i will forbid any big buffer to be bind to gtt. Thought with virtual address space for graphics this is less of an issue and only the kernel suffer but still it might block the kernel from evicting some VRAM because i can not bind a system buffer big enough to GTT because some GTT space is taken by some HSA queue.

Quoted 4 lines

To mitigate this at very least, you need to implement special memory allocation inside ttm and radeon to force this per queue to be allocate for instance from top of GTT space. Like reserve top 8M of GTT and have it grow/shrink depending on number of queue.

This same sort of thing can already happen with gfx, although it's less likely since the workloads are usually shorter. That said, we can issue compute jobs right today with the current CS ioctl and we may end up with a buffer pinned in an inopportune spot.

I'm not sure
reserving a static pool at init really helps that much. If you aren't using any HSA apps, it just wastes gtt space. So you have a trade
off: waste memory for a possibly unused MQD descriptor pool or

allocate MQD descriptors on the fly, but possibly end up with a long running one stuck in a bad location. Additionally, we already have a ttm flag for whether we want to allocate from the top or bottom of the pool. We use it today for gfx depending on the buffer (e.g., buffers smaller than 512k are allocated from the bottom and buffers larger than 512 are allocated from the top). So we can't really re-size a static buffer easily as there may already be other buffers pinned up there.

If we add sysfs controls to limit the amount of hsa processes, and queues per process so you could use this to dynamically limit the max amount gtt memory that would be in use for MQD descriptors.

Alex

Quoted 24 lines · Daniel Vetter

Quoted 22 lines · Oded Gabbay

Quoted 20 lines · Daniel Vetter

Quoted 9 lines · Oded Gabbay

Quoted 4 lines

Exactly, just prevent userspace from submitting more. And if you have misbehaving userspace that submits too much, reset the gpu and tell it that you're sorry but won't schedule any more work.

I'm not sure how you intend to know if a userspace misbehaves or not. Can
you elaborate ?

Well that's mostly policy, currently in i915 we only have a check for hangs, and if userspace hangs a bit too often then we stop it. I guess you can do that with the queue unmapping you've describe in reply to Jerome's mail.
-Daniel

Quoted 9 lines

Quoted 3 lines

What do you mean by hang ? Like the tdr mechanism in Windows (checks if a gpu job takes more than 2 seconds, I think, and if so, terminates the job).

Essentially yes. But we also have some hw features to kill jobs quicker, e.g. for media workloads.
-Daniel

Yeah, so this is what I'm talking about when I say that you and Jerome come from a graphics POV and amdkfd come from a compute POV, no offense intended.

For compute jobs, we simply can't use this logic to terminate jobs. Graphics are mostly Real-Time while compute jobs can take from a few ms to a few hours!!! And I'm not talking about an entire application runtime but on a single submission of jobs by the userspace app. We have tests with jobs that take between 20-30 minutes to complete. In theory, we can even imagine a compute job which takes 1 or 2 days (on larger APUs).

Now, I understand the question of how do we prevent the compute job from monopolizing the GPU, and internally here we have some ideas that we will probably share in the next few days, but my point is that I don't think we can terminate a compute job because it is running for more than x seconds. It is like you would terminate a CPU process which runs more than x seconds.

I think this is a *very* important discussion (detecting a misbehaved compute process) and I would like to continue it, but I don't think moving the job submission from userspace control to kernel control will solve this core problem.

Quoted 51 lines · Oded Gabbay

Quoted 24 lines · Daniel Vetter

Quoted 22 lines · Oded Gabbay

Quoted 20 lines · Daniel Vetter

Quoted 9 lines · Oded Gabbay

Quoted 4 lines

Exactly, just prevent userspace from submitting more. And if you have misbehaving userspace that submits too much, reset the gpu and tell it that you're sorry but won't schedule any more work.

I'm not sure how you intend to know if a userspace misbehaves or not. Can
you elaborate ?

Well that's mostly policy, currently in i915 we only have a check for hangs, and if userspace hangs a bit too often then we stop it. I guess you can do that with the queue unmapping you've describe in reply to Jerome's mail.
-Daniel

Quoted 9 lines

Quoted 3 lines

What do you mean by hang ? Like the tdr mechanism in Windows (checks if a gpu job takes more than 2 seconds, I think, and if so, terminates the job).

Essentially yes. But we also have some hw features to kill jobs quicker, e.g. for media workloads.
-Daniel

Yeah, so this is what I'm talking about when I say that you and Jerome come from a graphics POV and amdkfd come from a compute POV, no offense intended.

For compute jobs, we simply can't use this logic to terminate jobs. Graphics are mostly Real-Time while compute jobs can take from a few ms to a few hours!!! And I'm not talking about an entire application runtime but on a single submission of jobs by the userspace app. We have tests with jobs that take between 20-30 minutes to complete. In theory, we can even imagine a compute job which takes 1 or 2 days (on larger APUs).

Now, I understand the question of how do we prevent the compute job from monopolizing the GPU, and internally here we have some ideas that we will probably share in the next few days, but my point is that I don't think we can terminate a compute job because it is running for more than x seconds. It is like you would terminate a CPU process which runs more than x seconds.

Quoted 4 lines

I think this is a *very* important discussion (detecting a misbehaved compute process) and I would like to continue it, but I don't think moving the job submission from userspace control to kernel control will solve this core problem.

Well graphics gets away with cooperative scheduling since usually people want to see stuff within a few frames, so we can legitimately kill jobs after a fairly short timeout. Imo if you want to allow userspace to submit compute jobs that are atomic and take a few minutes to hours with no break-up in between and no hw means to preempt then that design is screwed up. We really can't tell the core vm that "sorry we will hold onto these gobloads of memory you really need now for another few hours". Pinning memory like that essentially without a time limit is restricted to root.
-Daniel

-----Original Message-----
From: Daniel Vetter [mailto:[email protected]]
Sent: Wednesday, July 23, 2014 3:06 AM
To: Gabbay, Oded
Cc: Jerome Glisse; Christian König; David Airlie; Alex Deucher; Andrew Morton; Bridgman, John; Joerg Roedel; Lewycky, Andrew; Daenzer, Michel; Goz, Ben; Skidanov, Alexey; [email protected]; dri- [email protected]; linux-mm; Sellek, Tom
Subject: Re: [PATCH v2 00/25] AMDKFD kernel driver

Quoted 7 lines · Oded Gabbay

Quoted 6 lines · Daniel Vetter

Quoted 4 lines · Oded Gabbay

Quoted 2 lines · Daniel Vetter

On Tue, Jul 22, 2014 at 10:19 AM, Oded Gabbay

<[email protected]>

Quoted 23 lines

Quoted 23 lines

Quoted 21 lines

Quoted 12 lines

Quoted 9 lines · wrote:

Quoted 4 lines

Exactly, just prevent userspace from submitting more. And if you have misbehaving userspace that submits too much, reset the gpu and tell it that you're sorry but won't schedule any more work.

I'm not sure how you intend to know if a userspace misbehaves or not. Can
you elaborate ?

Quoted 6 lines

Well that's mostly policy, currently in i915 we only have a check for hangs, and if userspace hangs a bit too often then we stop it. I guess you can do that with the queue unmapping you've describe in reply to Jerome's mail.
-Daniel

What do you mean by hang ? Like the tdr mechanism in Windows (checks if a gpu job takes more than 2 seconds, I think, and if so, terminates the job).

Quoted 7 lines

Quoted 4 lines

Essentially yes. But we also have some hw features to kill jobs quicker, e.g. for media workloads.
-Daniel

Yeah, so this is what I'm talking about when I say that you and Jerome come from a graphics POV and amdkfd come from a compute POV, no

offense intended.

Quoted 7 lines

For compute jobs, we simply can't use this logic to terminate jobs. Graphics are mostly Real-Time while compute jobs can take from a few ms to a few hours!!! And I'm not talking about an entire application runtime but on a single submission of jobs by the userspace app. We have tests with jobs that take between 20-30 minutes to complete. In theory, we can even imagine a compute job which takes 1 or 2 days (on

larger APUs).

Quoted 5 lines

Now, I understand the question of how do we prevent the compute job from monopolizing the GPU, and internally here we have some ideas that we will probably share in the next few days, but my point is that I don't think we can terminate a compute job because it is running for more

than x seconds.

Quoted 1 line

It is like you would terminate a CPU process which runs more than x

seconds.

Quoted 5 lines

I think this is a *very* important discussion (detecting a misbehaved compute process) and I would like to continue it, but I don't think moving the job submission from userspace control to kernel control will solve this core problem.

Well graphics gets away with cooperative scheduling since usually people want to see stuff within a few frames, so we can legitimately kill jobs after a fairly short timeout. Imo if you want to allow userspace to submit compute jobs that are atomic and take a few minutes to hours with no break-up in between and no hw means to preempt then that design is screwed up. We really can't tell the core vm that "sorry we will hold onto these gobloads of memory you really need now for another few hours". Pinning memory like that essentially without a time limit is restricted to root.

-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Quoted 75 lines

-----Original Message-----
From: Daniel Vetter [mailto:[email protected]]
Sent: Wednesday, July 23, 2014 3:06 AM
To: Gabbay, Oded
Cc: Jerome Glisse; Christian Konig; David Airlie; Alex Deucher; Andrew Morton; Bridgman, John; Joerg Roedel; Lewycky, Andrew; Daenzer, Michel; Goz, Ben; Skidanov, Alexey; [email protected]; dri- [email protected]; linux-mm; Sellek, Tom
Subject: Re: [PATCH v2 00/25] AMDKFD kernel driver

Quoted 7 lines · Oded Gabbay

Quoted 6 lines · Daniel Vetter

Quoted 4 lines · Oded Gabbay

Quoted 2 lines · Daniel Vetter

On Tue, Jul 22, 2014 at 10:19 AM, Oded Gabbay

<[email protected]>

Quoted 23 lines

Quoted 23 lines

Quoted 21 lines

Quoted 12 lines

Quoted 9 lines · wrote:

Quoted 4 lines

Exactly, just prevent userspace from submitting more. And if you have misbehaving userspace that submits too much, reset the gpu and tell it that you're sorry but won't schedule any more work.

I'm not sure how you intend to know if a userspace misbehaves or not. Can
you elaborate ?

Quoted 6 lines

Well that's mostly policy, currently in i915 we only have a check for hangs, and if userspace hangs a bit too often then we stop it. I guess you can do that with the queue unmapping you've describe in reply to Jerome's mail.
-Daniel

What do you mean by hang ? Like the tdr mechanism in Windows (checks if a gpu job takes more than 2 seconds, I think, and if so, terminates the job).

Quoted 7 lines

Quoted 4 lines

Essentially yes. But we also have some hw features to kill jobs quicker, e.g. for media workloads.
-Daniel

Yeah, so this is what I'm talking about when I say that you and Jerome come from a graphics POV and amdkfd come from a compute POV, no

offense intended.

Quoted 7 lines

For compute jobs, we simply can't use this logic to terminate jobs. Graphics are mostly Real-Time while compute jobs can take from a few ms to a few hours!!! And I'm not talking about an entire application runtime but on a single submission of jobs by the userspace app. We have tests with jobs that take between 20-30 minutes to complete. In theory, we can even imagine a compute job which takes 1 or 2 days (on

larger APUs).

Quoted 5 lines

Now, I understand the question of how do we prevent the compute job from monopolizing the GPU, and internally here we have some ideas that we will probably share in the next few days, but my point is that I don't think we can terminate a compute job because it is running for more

than x seconds.

Quoted 1 line

It is like you would terminate a CPU process which runs more than x

seconds.

Quoted 5 lines

I think this is a *very* important discussion (detecting a misbehaved compute process) and I would like to continue it, but I don't think moving the job submission from userspace control to kernel control will solve this core problem.

Quoted 8 lines

Well graphics gets away with cooperative scheduling since usually people want to see stuff within a few frames, so we can legitimately kill jobs after a fairly short timeout. Imo if you want to allow userspace to submit compute jobs that are atomic and take a few minutes to hours with no break-up in between and no hw means to preempt then that design is screwed up. We really can't tell the core vm that "sorry we will hold onto these gobloads of memory you really need now for another few hours". Pinning memory like that essentially without a time limit is restricted to root.

Hi Daniel;

I don't really understand the reference to "gobloads of memory". Unlike radeon graphics, the userspace data for HSA applications is maintained in pageable system memory and accessed via the IOMMUv2 (ATC/PRI). The IOMMUv2 driver and mm subsystem takes care of faulting in memory pages as needed, nothing is long-term pinned.

-----Original Message-----
From: Daniel Vetter [mailto:[email protected]] On Behalf Of Daniel Vetter
Sent: Wednesday, July 23, 2014 10:42 AM
To: Bridgman, John
Cc: Daniel Vetter; Gabbay, Oded; Jerome Glisse; Christian König; David Airlie; Alex Deucher; Andrew Morton; Joerg Roedel; Lewycky, Andrew; Daenzer, Michel; Goz, Ben; Skidanov, Alexey; [email protected]; dri- [email protected]; linux-mm; Sellek, Tom
Subject: Re: [PATCH v2 00/25] AMDKFD kernel driver

Quoted 21 lines · John

Quoted 21 lines

-----Original Message-----
From: Daniel Vetter [mailto:[email protected]]
Sent: Wednesday, July 23, 2014 3:06 AM
To: Gabbay, Oded
Cc: Jerome Glisse; Christian König; David Airlie; Alex Deucher; Andrew Morton; Bridgman, John; Joerg Roedel; Lewycky, Andrew; Daenzer, Michel; Goz, Ben; Skidanov, Alexey; [email protected]; dri- [email protected]; linux-mm; Sellek, Tom
Subject: Re: [PATCH v2 00/25] AMDKFD kernel driver

Quoted 6 lines · Oded Gabbay

Quoted 5 lines · Daniel Vetter

Quoted 3 lines · Oded Gabbay

Quoted 1 line · Daniel Vetter

Quoted 7 lines

Quoted 7 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

On Tue, Jul 22, 2014 at 10:19 AM, Oded Gabbay

<[email protected]>

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines · wrote:

Quoted 4 lines

Exactly, just prevent userspace from submitting more. And if you have misbehaving userspace that submits too much, reset the gpu and tell it that you're sorry but won't schedule any more

work.

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

I'm not sure how you intend to know if a userspace misbehaves or

not.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

Can
you elaborate ?

Well that's mostly policy, currently in i915 we only have a check for hangs, and if userspace hangs a bit too often then we stop

it.

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 7 lines

Quoted 4 lines

I guess you can do that with the queue unmapping you've describe in reply to Jerome's mail.
-Daniel

What do you mean by hang ? Like the tdr mechanism in Windows (checks if a gpu job takes more than 2 seconds, I think, and if so, terminates the job).

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 4 lines

Essentially yes. But we also have some hw features to kill jobs quicker, e.g. for media workloads.
-Daniel

Yeah, so this is what I'm talking about when I say that you and Jerome come from a graphics POV and amdkfd come from a compute

POV,

Quoted 26 lines

Quoted 26 lines

Quoted 1 line

no

offense intended.

Quoted 8 lines

For compute jobs, we simply can't use this logic to terminate jobs. Graphics are mostly Real-Time while compute jobs can take from a few ms to a few hours!!! And I'm not talking about an entire application runtime but on a single submission of jobs by the userspace app. We have tests with jobs that take between 20-30 minutes to complete. In theory, we can even imagine a compute job which takes 1 or 2 days (on

larger APUs).

Quoted 6 lines

Now, I understand the question of how do we prevent the compute job from monopolizing the GPU, and internally here we have some ideas that we will probably share in the next few days, but my point is that I don't think we can terminate a compute job because it is running for more

than x seconds.

Quoted 1 line

It is like you would terminate a CPU process which runs more than x

seconds.

Quoted 5 lines

I think this is a *very* important discussion (detecting a misbehaved compute process) and I would like to continue it, but I don't think moving the job submission from userspace control to kernel control will solve this core problem.

Quoted 8 lines

Quoted 8 lines

Well graphics gets away with cooperative scheduling since usually people want to see stuff within a few frames, so we can legitimately kill jobs after a fairly short timeout. Imo if you want to allow userspace to submit compute jobs that are atomic and take a few minutes to hours with no break-up in between and no hw means to preempt then that design is screwed up. We really can't tell the core vm that "sorry we will hold onto these gobloads of memory you really need now for another few hours". Pinning memory like that essentially

without a time limit is restricted to root.

Quoted 9 lines

Hi Daniel;

I don't really understand the reference to "gobloads of memory". Unlike radeon graphics, the userspace data for HSA applications is maintained in pageable system memory and accessed via the IOMMUv2 (ATC/PRI). The
IOMMUv2 driver and mm subsystem takes care of faulting in memory pages as needed, nothing is long-term pinned.

Yeah I've lost that part of the equation a bit since I've always thought that proper faulting support without preemption is not really possible. I guess those platforms completely stall on a fault until the ptes are all set up?

-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

-----Original Message-----
From: dri-devel [mailto:[email protected]] On Behalf Of Bridgman, John
Sent: Wednesday, July 23, 2014 11:07 AM
To: Daniel Vetter
Cc: Lewycky, Andrew; linux-mm; Daniel Vetter; Daenzer, Michel; linux- [email protected]; Sellek, Tom; Skidanov, Alexey; dri- [email protected]; Andrew Morton
Subject: RE: [PATCH v2 00/25] AMDKFD kernel driver

Quoted 120 lines

-----Original Message-----
From: Daniel Vetter [mailto:[email protected]] On Behalf Of Daniel Vetter
Sent: Wednesday, July 23, 2014 10:42 AM
To: Bridgman, John
Cc: Daniel Vetter; Gabbay, Oded; Jerome Glisse; Christian König; David Airlie; Alex Deucher; Andrew Morton; Joerg Roedel; Lewycky, Andrew; Daenzer, Michel; Goz, Ben; Skidanov, Alexey; [email protected]; dri- [email protected]; linux-mm; Sellek, Tom
Subject: Re: [PATCH v2 00/25] AMDKFD kernel driver

Quoted 21 lines · John

Quoted 21 lines

-----Original Message-----
From: Daniel Vetter [mailto:[email protected]]
Sent: Wednesday, July 23, 2014 3:06 AM
To: Gabbay, Oded
Cc: Jerome Glisse; Christian König; David Airlie; Alex Deucher; Andrew Morton; Bridgman, John; Joerg Roedel; Lewycky, Andrew; Daenzer, Michel; Goz, Ben; Skidanov, Alexey; [email protected]; dri- [email protected]; linux-mm; Sellek, Tom
Subject: Re: [PATCH v2 00/25] AMDKFD kernel driver

Quoted 6 lines · Oded Gabbay

Quoted 5 lines · Daniel Vetter

Quoted 3 lines · Oded Gabbay

Quoted 1 line · Daniel Vetter

Quoted 8 lines

Quoted 8 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

On Tue, Jul 22, 2014 at 10:19 AM, Oded Gabbay

<[email protected]>

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines · wrote:

Quoted 5 lines

Exactly, just prevent userspace from submitting more. And if you have misbehaving userspace that submits too much, reset the gpu and tell it that you're sorry but won't schedule any more

work.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

I'm not sure how you intend to know if a userspace misbehaves or

not.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 2 lines

Can
you elaborate ?

Well that's mostly policy, currently in i915 we only have a check for hangs, and if userspace hangs a bit too often then we stop

it.

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 7 lines

Quoted 4 lines

I guess you can do that with the queue unmapping you've describe in reply to Jerome's mail.
-Daniel

What do you mean by hang ? Like the tdr mechanism in Windows (checks if a gpu job takes more than 2 seconds, I think, and if so, terminates the job).

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 4 lines

Essentially yes. But we also have some hw features to kill jobs quicker, e.g. for media workloads.
-Daniel

Yeah, so this is what I'm talking about when I say that you and Jerome come from a graphics POV and amdkfd come from a compute

POV,

Quoted 27 lines

Quoted 27 lines

Quoted 1 line

no

offense intended.

Quoted 8 lines

For compute jobs, we simply can't use this logic to terminate jobs. Graphics are mostly Real-Time while compute jobs can take from a few ms to a few hours!!! And I'm not talking about an entire application runtime but on a single submission of jobs by the userspace app. We have tests with jobs that take between 20-30 minutes to complete. In theory, we can even imagine a compute job which takes 1 or 2 days (on

larger APUs).

Quoted 6 lines

Now, I understand the question of how do we prevent the compute job from monopolizing the GPU, and internally here we have some ideas that we will probably share in the next few days, but my point is that I don't think we can terminate a compute job because it is running for more

than x seconds.

Quoted 2 lines

It is like you would terminate a CPU process which runs more than x

seconds.

Quoted 5 lines

I think this is a *very* important discussion (detecting a misbehaved compute process) and I would like to continue it, but I don't think moving the job submission from userspace control to kernel control will solve this core problem.

Quoted 9 lines

Quoted 9 lines

Well graphics gets away with cooperative scheduling since usually people want to see stuff within a few frames, so we can legitimately kill jobs after a fairly short timeout. Imo if you want to allow userspace to submit compute jobs that are atomic and take a few minutes to hours with no break-up in between and no hw means to preempt then that design is screwed up. We really can't tell the core vm that "sorry we will hold onto these gobloads of memory you really need now for another few hours". Pinning memory like that essentially

without a time limit is restricted to root.

Quoted 9 lines

Hi Daniel;

I don't really understand the reference to "gobloads of memory". Unlike radeon graphics, the userspace data for HSA applications is maintained in pageable system memory and accessed via the IOMMUv2 (ATC/PRI). The
IOMMUv2 driver and mm subsystem takes care of faulting in memory pages as needed, nothing is long-term pinned.

Quoted 3 lines

Yeah I've lost that part of the equation a bit since I've always thought that proper faulting support without preemption is not really possible. I guess those platforms completely stall on a fault until the ptes

are all set up?

Correct. The GPU thread accessing the faulted page definitely stalls but processing can continue on other GPU threads.

I don't remember offhand how much of the GPU=>ATC=>IOMMUv2=>system RAM path gets stalled (ie whether other HSA apps get blocked) but AFAIK graphics processing (assuming it is not using ATC path to system memory) is not affected. I will double-check that though, haven't asked internally for a couple of years but I do remember concluding something along the lines of "OK, that'll do" ;)

Quoted 5 lines

-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Quoted 4 lines · Jerome Glisse

Quoted 3 lines · Daniel Vetter

Quoted 2 lines · Christian K?nig

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 1 line · Jerome Glisse

Quoted 14 lines

Quoted 5 lines

Quoted 5 lines

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

Quoted 8 lines

Quoted 2 lines

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Aside, i915 perspective again (i.e. how we solved this): When scheduling away from contexts we unpin them and put them into the lru. And in the shrinker we have a last-ditch callback to switch to a default context (since you can't ever have no context once you've started) which means we can evict any context object if it's getting in the way.

Quoted 3 lines

So Intel hardware report through some interrupt or some channel when it is not using a context ? ie kernel side get notification when some user context is done executing ?

Yes, as long as we do the scheduling with the cpu we get interrupts for context switches. The mechanic is already published in the execlist patches currently floating around. We get a special context switch interrupt.

But we have this unpin logic already on the current code where we switch contexts through in-line cs commands from the kernel. There we obviously use the normal batch completion events.

Quoted 3 lines

The issue with radeon hardware AFAICT is that the hardware do not report any thing about the userspace context running ie you do not get notification when a context is not use. Well AFAICT. Maybe hardware do provide that.

I'm not sure whether we can do the same trick with the hw scheduler. But then unpinning hw contexts will drain the pipeline anyway, so I guess we can just stop feeding the hw scheduler until it runs dry. And then unpin and evict.

Quoted 3 lines

Like the VMID is a limited resources so you have to dynamicly bind them so maybe we can only allocate pinned buffer for each VMID and then when binding a PASID to a VMID it also copy back pinned buffer to pasid unpinned copy.

Yeah, pasid assignment will be fun. Not sure whether Jesse's patches will do this already. We _do_ already have fun with ctx id assigments though since we move them around (and the hw id is the ggtt address afaik). So we need to remap them already. Not sure on the details for pasid mapping, iirc it's a separate field somewhere in the context struct. Jesse knows the details.

-----Original Message-----
From: dri-devel [mailto:[email protected]] On Behalf Of Jesse Barnes
Sent: Wednesday, July 23, 2014 5:00 PM
To: [email protected]
Subject: Re: [PATCH v2 00/25] AMDKFD kernel driver

On Mon, 21 Jul 2014 19:05:46 +0200
daniel at ffwll.ch (Daniel Vetter) wrote:

Quoted 5 lines · Jerome Glisse

Quoted 4 lines · Daniel Vetter

Quoted 3 lines · Christian K?nig

Quoted 2 lines

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 1 line · Jerome Glisse

[snip!!]

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 2 lines

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Aside, i915 perspective again (i.e. how we solved this): When scheduling away from contexts we unpin them and put them into the lru. And in the shrinker we have a last-ditch callback to switch to a default context (since you can't ever have no context once you've started) which means we can evict any context object if it's

getting in the way.

Quoted 5 lines

Quoted 4 lines

So Intel hardware report through some interrupt or some channel when it is not using a context ? ie kernel side get notification when some user context is done executing ?

Quoted 8 lines

Yes, as long as we do the scheduling with the cpu we get interrupts for context switches. The mechanic is already published in the execlist patches currently floating around. We get a special context switch interrupt.

But we have this unpin logic already on the current code where we switch contexts through in-line cs commands from the kernel. There we obviously use the normal batch completion events.

Yeah and we can continue that going forward. And of course if your hw can do page faulting, you don't need to pin the normal data buffers.

Usually there are some special buffers that need to be pinned for longer periods though, anytime the context could be active. Sounds like in this case the userland queues, which makes some sense. But maybe for smaller systems the size limit could be clamped to something smaller than 128M. Or tie it into the rlimit somehow, just like we do for mlock() stuff.

Quoted 3 lines

Quoted 3 lines

The issue with radeon hardware AFAICT is that the hardware do not report any thing about the userspace context running ie you do not get notification when a context is not use. Well AFAICT. Maybe hardware

do provide that.

Quoted 5 lines

I'm not sure whether we can do the same trick with the hw scheduler. But then unpinning hw contexts will drain the pipeline anyway, so I guess we can just stop feeding the hw scheduler until it runs dry. And then unpin and evict.

Yeah we should have an idea which contexts have been fed to the scheduler, at least with kernel based submission. With userspace submission we'll be in a tougher spot... but as you say we can always idle things and unpin everything under pressure. That's a really big hammer to apply though.

Quoted 3 lines

Quoted 3 lines

Like the VMID is a limited resources so you have to dynamicly bind them so maybe we can only allocate pinned buffer for each VMID and then when binding a PASID to a VMID it also copy back pinned buffer to

pasid unpinned copy.

Quoted 7 lines

Yeah, pasid assignment will be fun. Not sure whether Jesse's patches will do this already. We _do_ already have fun with ctx id assigments though since we move them around (and the hw id is the ggtt address afaik). So we need to remap them already. Not sure on the details for pasid mapping, iirc it's a separate field somewhere in the context struct. Jesse knows the details.

The PASID space is a bit bigger, 20 bits iirc. So we probably won't run out quickly or often. But when we do I thought we could apply the same trick Linux uses for ASID management on SPARC and ia64 (iirc on sparc anyway, maybe MIPS too): "allocate" a PASID everytime you need one, but don't tie it to the process at all, just use it as a counter that lets you know when you need to do a full TLB flush, then start the allocation process over. This lets you minimize TLB flushing and gracefully handles oversubscription.

My current code doesn't bother though; context creation will fail if we run out of PASIDs on a given device.

--
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Quoted 10 lines

-----Original Message----- From: dri-devel [mailto:[email protected]] On Behalf Of Jesse Barnes Sent: Wednesday, July 23, 2014 5:00 PM To:
[email protected] Subject: Re: [PATCH v2 00/25] AMDKFD kernel driver

On Mon, 21 Jul 2014 19:05:46 +0200 daniel at ffwll.ch (Daniel Vetter) wrote:

Quoted 8 lines

Quoted 6 lines · Jerome Glisse

Quoted 5 lines · Daniel Vetter

Quoted 4 lines

Quoted 2 lines · Christian K?nig

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 1 line · Jerome Glisse

[snip!!]

My BlackBerry thumb thanks you ;)

Quoted 35 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Aside, i915 perspective again (i.e. how we solved this):
When scheduling away from contexts we unpin them and put them into the lru. And in the shrinker we have a last-ditch callback to switch to a default context (since you can't ever have no context once you've started) which means we can evict any context object if it's

getting in the way.

Quoted 5 lines

Quoted 4 lines

So Intel hardware report through some interrupt or some channel when it is not using a context ? ie kernel side get notification when some user context is done executing ?

Quoted 8 lines

Yes, as long as we do the scheduling with the cpu we get interrupts for context switches. The mechanic is already published in the execlist patches currently floating around. We get a special context switch interrupt.

But we have this unpin logic already on the current code where we switch contexts through in-line cs commands from the kernel. There we obviously use the normal batch completion events.

Yeah and we can continue that going forward. And of course if your hw can do page faulting, you don't need to pin the normal data buffers.

Quoted 7 lines

Usually there are some special buffers that need to be pinned for longer periods though, anytime the context could be active. Sounds like in this case the userland queues, which makes some sense. But maybe for smaller systems the size limit could be clamped to something smaller than 128M. Or tie it into the rlimit somehow, just like we do for mlock() stuff.

Yeah, even the queues are in pageable memory, it's just a ~256 byte structure per queue (the Memory Queue Descriptor) that describes the queue to hardware, plus a couple of pages for each process using HSA to hold things like doorbells. Current thinking is to limit # processes using HSA to ~256 and #queues per process to ~1024 by default in the initial code, although my guess is that we could take the #queues per process default limit even lower.

Quoted 30 lines

Quoted 4 lines

Quoted 4 lines

The issue with radeon hardware AFAICT is that the hardware do not report any thing about the userspace context running ie you do not get notification when a context is not use. Well AFAICT. Maybe hardware

do provide that.

Quoted 5 lines

I'm not sure whether we can do the same trick with the hw scheduler. But then unpinning hw contexts will drain the pipeline anyway, so I guess we can just stop feeding the hw scheduler until it runs dry. And then unpin and evict.

Yeah we should have an idea which contexts have been fed to the scheduler, at least with kernel based submission. With userspace submission we'll be in a tougher spot... but as you say we can always idle things and unpin everything under pressure. That's a really big hammer to apply though.

Quoted 4 lines

Quoted 4 lines

Like the VMID is a limited resources so you have to dynamicly bind them so maybe we can only allocate pinned buffer for each VMID and then when binding a PASID to a VMID it also copy back pinned buffer to

pasid unpinned copy.

Quoted 7 lines

Yeah, pasid assignment will be fun. Not sure whether Jesse's patches will do this already. We _do_ already have fun with ctx id assigments though since we move them around (and the hw id is the ggtt address afaik). So we need to remap them already. Not sure on the details for pasid mapping, iirc it's a separate field somewhere in the context struct. Jesse knows the details.

Quoted 8 lines

The PASID space is a bit bigger, 20 bits iirc. So we probably won't run out quickly or often. But when we do I thought we could apply the same trick Linux uses for ASID management on SPARC and ia64 (iirc on sparc anyway, maybe MIPS too): "allocate" a PASID everytime you need one, but don't tie it to the process at all, just use it as a counter that lets you know when you need to do a full TLB flush, then start the allocation process over. This lets you minimize TLB flushing and gracefully handles oversubscription.

IIRC we have a 9-bit limit for PASID on current hardware, although that will go up in future.

Quoted 8 lines

My current code doesn't bother though; context creation will fail if we run out of PASIDs on a given device.

-- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list [email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________ dri-devel mailing list [email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Quoted 61 lines · John

Quoted 10 lines

-----Original Message----- From: dri-devel [mailto:[email protected]] On Behalf Of Jesse Barnes Sent: Wednesday, July 23, 2014 5:00 PM To:
[email protected] Subject: Re: [PATCH v2 00/25] AMDKFD kernel driver

On Mon, 21 Jul 2014 19:05:46 +0200 daniel at ffwll.ch (Daniel Vetter) wrote:

Quoted 8 lines

Quoted 6 lines · Jerome Glisse

Quoted 5 lines · Daniel Vetter

Quoted 4 lines

Quoted 2 lines · Christian K?nig

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 1 line · Jerome Glisse

[snip!!]

My BlackBerry thumb thanks you ;)

Quoted 35 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Aside, i915 perspective again (i.e. how we solved this):
When scheduling away from contexts we unpin them and put them into the lru. And in the shrinker we have a last-ditch callback to switch to a default context (since you can't ever have no context once you've started) which means we can evict any context object if it's

getting in the way.

Quoted 5 lines

Quoted 4 lines

So Intel hardware report through some interrupt or some channel when it is not using a context ? ie kernel side get notification when some user context is done executing ?

Quoted 8 lines

Yes, as long as we do the scheduling with the cpu we get interrupts for context switches. The mechanic is already published in the execlist patches currently floating around. We get a special context switch interrupt.

But we have this unpin logic already on the current code where we switch contexts through in-line cs commands from the kernel. There we obviously use the normal batch completion events.

Yeah and we can continue that going forward. And of course if your hw can do page faulting, you don't need to pin the normal data buffers.

Quoted 7 lines

Usually there are some special buffers that need to be pinned for longer periods though, anytime the context could be active. Sounds like in this case the userland queues, which makes some sense. But maybe for smaller systems the size limit could be clamped to something smaller than 128M. Or tie it into the rlimit somehow, just like we do for mlock() stuff.

Quoted 8 lines

Yeah, even the queues are in pageable memory, it's just a ~256 byte structure per queue (the Memory Queue Descriptor) that describes the queue to hardware, plus a couple of pages for each process using HSA to hold things like doorbells. Current thinking is to limit # processes using HSA to ~256 and #queues per process to ~1024 by default in the initial code, although my guess is that we could take the #queues per process default limit even lower.

So my mistake. struct cik_mqd is actually 604 bytes, and it is allocated on 256 boundary.
I had in mind to reserve 64MB of gart by default, which translates to 512 queues per process, with 128 processes. Add 2 kernel module parameters, # of max-queues-per-process and # of max-processes (default is, as I said, 512 and 128) for better control of system admin.

Quoted 71 lines · Oded Gabbay

Quoted 61 lines · John

Quoted 10 lines

-----Original Message----- From: dri-devel [mailto:[email protected]] On Behalf Of Jesse Barnes Sent: Wednesday, July 23, 2014 5:00 PM To:
[email protected] Subject: Re: [PATCH v2 00/25] AMDKFD kernel driver

On Mon, 21 Jul 2014 19:05:46 +0200 daniel at ffwll.ch (Daniel Vetter) wrote:

Quoted 8 lines

Quoted 6 lines · Jerome Glisse

Quoted 5 lines · Daniel Vetter

Quoted 4 lines

Quoted 2 lines · Christian K?nig

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 1 line · Jerome Glisse

[snip!!]

My BlackBerry thumb thanks you ;)

Quoted 35 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Aside, i915 perspective again (i.e. how we solved this):
When scheduling away from contexts we unpin them and put them into the lru. And in the shrinker we have a last-ditch callback to switch to a default context (since you can't ever have no context once you've started) which means we can evict any context object if it's

getting in the way.

Quoted 5 lines

Quoted 4 lines

So Intel hardware report through some interrupt or some channel when it is not using a context ? ie kernel side get notification when some user context is done executing ?

Quoted 8 lines

Yes, as long as we do the scheduling with the cpu we get interrupts for context switches. The mechanic is already published in the execlist patches currently floating around. We get a special context switch interrupt.

But we have this unpin logic already on the current code where we switch contexts through in-line cs commands from the kernel. There we obviously use the normal batch completion events.

Yeah and we can continue that going forward. And of course if your hw can do page faulting, you don't need to pin the normal data buffers.

Quoted 7 lines

Usually there are some special buffers that need to be pinned for longer periods though, anytime the context could be active. Sounds like in this case the userland queues, which makes some sense. But maybe for smaller systems the size limit could be clamped to something smaller than 128M. Or tie it into the rlimit somehow, just like we do for mlock() stuff.

Quoted 8 lines

Yeah, even the queues are in pageable memory, it's just a ~256 byte structure per queue (the Memory Queue Descriptor) that describes the queue to hardware, plus a couple of pages for each process using HSA to hold things like doorbells. Current thinking is to limit # processes using HSA to ~256 and #queues per process to ~1024 by default in the initial code, although my guess is that we could take the #queues per process default limit even lower.

Quoted 7 lines

So my mistake. struct cik_mqd is actually 604 bytes, and it is allocated on 256 boundary.
I had in mind to reserve 64MB of gart by default, which translates to 512 queues per process, with 128 processes. Add 2 kernel module parameters, # of max-queues-per-process and # of max-processes (default is, as I said, 512 and 128) for better control of system admin.

So as i said somewhere else in this thread, this should not be reserved but use a special allocation. Any HSA GPU use virtual address space for userspace so only issue is for kernel side GTT.

What i would like is seeing radeon pinned GTT allocation at bottom of GTT space (ie all ring buffer and the ib pool buffer). Then have an allocator that allocate new queue from top of GTT address space and grow to the bottom.

It should not staticly reserved 64M or anything. When doing allocation it should move any ttm buffer that are in the region it want to allocate to a different location.

As this needs some work, i am not against reserving some small amount (couple MB) as a first stage but anything more would need a proper solution like the one i just described.

Quoted 89 lines · Jerome Glisse

Quoted 71 lines · Oded Gabbay

Quoted 61 lines · John

Quoted 10 lines

-----Original Message----- From: dri-devel [mailto:[email protected]] On Behalf Of Jesse Barnes Sent: Wednesday, July 23, 2014 5:00 PM To:
[email protected] Subject: Re: [PATCH v2 00/25] AMDKFD kernel driver

On Mon, 21 Jul 2014 19:05:46 +0200 daniel at ffwll.ch (Daniel Vetter) wrote:

Quoted 8 lines

Quoted 6 lines · Jerome Glisse

Quoted 5 lines · Daniel Vetter

Quoted 4 lines

Quoted 2 lines · Christian K?nig

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 1 line · Jerome Glisse

[snip!!]

My BlackBerry thumb thanks you ;)

Quoted 35 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Aside, i915 perspective again (i.e. how we solved this):
When scheduling away from contexts we unpin them and put them into the lru. And in the shrinker we have a last-ditch callback to switch to a default context (since you can't ever have no context once you've started) which means we can evict any context object if it's

getting in the way.

Quoted 5 lines

Quoted 4 lines

So Intel hardware report through some interrupt or some channel when it is not using a context ? ie kernel side get notification when some user context is done executing ?

Quoted 8 lines

Yes, as long as we do the scheduling with the cpu we get interrupts for context switches. The mechanic is already published in the execlist patches currently floating around. We get a special context switch interrupt.

But we have this unpin logic already on the current code where we switch contexts through in-line cs commands from the kernel. There we obviously use the normal batch completion events.

Yeah and we can continue that going forward. And of course if your hw can do page faulting, you don't need to pin the normal data buffers.

Quoted 7 lines

Usually there are some special buffers that need to be pinned for longer periods though, anytime the context could be active. Sounds like in this case the userland queues, which makes some sense. But maybe for smaller systems the size limit could be clamped to something smaller than 128M. Or tie it into the rlimit somehow, just like we do for mlock() stuff.

Quoted 8 lines

Yeah, even the queues are in pageable memory, it's just a ~256 byte structure per queue (the Memory Queue Descriptor) that describes the queue to hardware, plus a couple of pages for each process using HSA to hold things like doorbells. Current thinking is to limit # processes using HSA to ~256 and #queues per process to ~1024 by default in the initial code, although my guess is that we could take the #queues per process default limit even lower.

Quoted 7 lines

So my mistake. struct cik_mqd is actually 604 bytes, and it is allocated on 256 boundary.
I had in mind to reserve 64MB of gart by default, which translates to 512 queues per process, with 128 processes. Add 2 kernel module parameters, # of max-queues-per-process and # of max-processes (default is, as I said, 512 and 128) for better control of system admin.

So as i said somewhere else in this thread, this should not be reserved but use a special allocation. Any HSA GPU use virtual address space for userspace so only issue is for kernel side GTT.

What i would like is seeing radeon pinned GTT allocation at bottom of GTT space (ie all ring buffer and the ib pool buffer). Then have an allocator that allocate new queue from top of GTT address space and grow to the bottom.

Quoted 8 lines

It should not staticly reserved 64M or anything. When doing allocation it should move any ttm buffer that are in the region it want to allocate to a different location.

As this needs some work, i am not against reserving some small amount (couple MB) as a first stage but anything more would need a proper solution like the one i just described.

It's still a trade off. Even if we reserve a couple of megs it'll be wasted if we are not running HSA apps. And even today if we run a compute job using the current interfaces we could end up in the same case. So while I think it's definitely a good goal to come up with some solution for fragmentation, I don't think it should be a show-stopper right now.

A better solution to deal with fragmentation of GTT and provide a better way to allocate larger buffers in vram would be to break up vram <-> system pool transfers into multiple transfers depending on the available GTT size. Or use GPUVM dynamically for vram <-> system transfers.

Alex

Quoted 99 lines · Alex Deucher

Quoted 89 lines · Jerome Glisse

Quoted 71 lines · Oded Gabbay

Quoted 61 lines · John

Quoted 10 lines

-----Original Message----- From: dri-devel [mailto:[email protected]] On Behalf Of Jesse Barnes Sent: Wednesday, July 23, 2014 5:00 PM To:
[email protected] Subject: Re: [PATCH v2 00/25] AMDKFD kernel driver

On Mon, 21 Jul 2014 19:05:46 +0200 daniel at ffwll.ch (Daniel Vetter) wrote:

Quoted 8 lines

Quoted 6 lines · Jerome Glisse

Quoted 5 lines · Daniel Vetter

Quoted 4 lines

Quoted 2 lines · Christian K?nig

Am 21.07.2014 14:36, schrieb Oded Gabbay:

Quoted 1 line · Jerome Glisse

[snip!!]

My BlackBerry thumb thanks you ;)

Quoted 35 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

The main questions here are if it's avoid able to pin down the memory and if the memory is pinned down at driver load, by request from userspace or by anything else.

As far as I can see only the "mqd per userspace queue" might be a bit questionable, everything else sounds reasonable.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Aside, i915 perspective again (i.e. how we solved this):
When scheduling away from contexts we unpin them and put them into the lru. And in the shrinker we have a last-ditch callback to switch to a default context (since you can't ever have no context once you've started) which means we can evict any context object if it's

getting in the way.

Quoted 5 lines

Quoted 4 lines

So Intel hardware report through some interrupt or some channel when it is not using a context ? ie kernel side get notification when some user context is done executing ?

Quoted 8 lines

Yes, as long as we do the scheduling with the cpu we get interrupts for context switches. The mechanic is already published in the execlist patches currently floating around. We get a special context switch interrupt.

But we have this unpin logic already on the current code where we switch contexts through in-line cs commands from the kernel. There we obviously use the normal batch completion events.

Yeah and we can continue that going forward. And of course if your hw can do page faulting, you don't need to pin the normal data buffers.

Quoted 7 lines

Usually there are some special buffers that need to be pinned for longer periods though, anytime the context could be active. Sounds like in this case the userland queues, which makes some sense. But maybe for smaller systems the size limit could be clamped to something smaller than 128M. Or tie it into the rlimit somehow, just like we do for mlock() stuff.

Quoted 8 lines

Yeah, even the queues are in pageable memory, it's just a ~256 byte structure per queue (the Memory Queue Descriptor) that describes the queue to hardware, plus a couple of pages for each process using HSA to hold things like doorbells. Current thinking is to limit # processes using HSA to ~256 and #queues per process to ~1024 by default in the initial code, although my guess is that we could take the #queues per process default limit even lower.

Quoted 7 lines

So my mistake. struct cik_mqd is actually 604 bytes, and it is allocated on 256 boundary.
I had in mind to reserve 64MB of gart by default, which translates to 512 queues per process, with 128 processes. Add 2 kernel module parameters, # of max-queues-per-process and # of max-processes (default is, as I said, 512 and 128) for better control of system admin.

So as i said somewhere else in this thread, this should not be reserved but use a special allocation. Any HSA GPU use virtual address space for userspace so only issue is for kernel side GTT.

What i would like is seeing radeon pinned GTT allocation at bottom of GTT space (ie all ring buffer and the ib pool buffer). Then have an allocator that allocate new queue from top of GTT address space and grow to the bottom.

Quoted 8 lines

It should not staticly reserved 64M or anything. When doing allocation it should move any ttm buffer that are in the region it want to allocate to a different location.

As this needs some work, i am not against reserving some small amount (couple MB) as a first stage but anything more would need a proper solution like the one i just described.

Quoted 7 lines

It's still a trade off. Even if we reserve a couple of megs it'll be wasted if we are not running HSA apps. And even today if we run a compute job using the current interfaces we could end up in the same case. So while I think it's definitely a good goal to come up with some solution for fragmentation, I don't think it should be a show-stopper right now.