The AMDGPU Linux kernel driver will see a new interface that allows user-space to introduce assignments to the GPU coding that qualified users will simultaneously implement across numerous engines.
AMDGPU Linux kernel driver opens capability for multiple users to add and edit any work on GPUs across varying engines at the same time
Christian König, a longtime AMD open-source Linux driver developer, dispatched the new "gang submission" interface patch series earlier this week for the platform's AMDGPU Direct Rendering Manager driver. The submission for the AMD Radeon command stream (CS) ensures that the work will be conducted on various engines simultaneously.
Allows submitting jobs as gang which needs to run on multiple engines at the same time. All members of the gang get the same implicit, explicit and VM dependencies. So no gang member will start running until everything else is ready. The last job is considered the gang leader (usually a submission to the GFX ring) and used for signaling output dependencies.
The Direct Rendering Manager (DRM) is a subsystem of the Linux kernel accountable for interfacing with GPUs of contemporary graphics cards. DRM was initially developed as the kernel-space component of the X Server Direct Rendering Infrastructure but now is used by other graphic stack options such as Wayland. DRM exposes an API that user-space applications can use to send commands and information to the GPU and complete operations such as customizing the mode setting of the graphical display.
König added this note to the details for the new patch series.
[T]his patch set implements the the requirement for so called gang submissions in the CS interface.
A gang submission guarantees that multiple IBs can run on different engines at the same time. This is implemented by keeping a global per-device gang around represented by a dma_fence which signals as soon as all jobs in a gang are pushed to the hardware. The effect is that as long as members of a gang are waiting to be submitted no other gang can start pushing jobs to the hardware and so deadlocks are effectively prevented. The whole set is based on top of my dma_resv_usage work and a few patches merged over from amd-staging-drm-next, so it won't easily apply anywhere.
Please review and comment,
It's certainly a busy time of the year for the AMD Radeon Linux driver developers working on new hardware support while continuing to tack on new driver features and optimizations for existing hardware platforms.