On 2/3/23 22:54, Shashank Sharma wrote: > From: Shashank Sharma <contactshashanksharma@xxxxxxxxx> > > This patch series introduces AMDGPU usermode graphics queues. > User queues is a method of GPU workload submission into the graphics > hardware without any interaction with kernel/DRM schedulers. In this > method, a userspace graphics application can create its own workqueue > and submit it directly in the GPU HW. > > The general idea of how this is supposed to work: > - The application creates the following GPU objetcs: > - A queue object to hold the workload packets. > - A read pointer object. > - A write pointer object. > - A doorbell page. > - Kernel picks any 32-bit offset in the doorbell page for this queue. > - The application uses the usermode_queue_create IOCTL introduced in > this patch, by passing the the GPU addresses of these objects (read > ptr, write ptr, queue base address and doorbell address) > - The kernel creates the queue and maps it in the HW. > - The application can start submitting the data in the queue as soon as > the kernel IOCTL returns. > - Once the data is filled in the queue, the app must write the number of > dwords in the doorbell offset, and the GPU will start fetching the data. > > libDRM changes for this series and a sample DRM test program can be found > in the MESA merge request here: > https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/287 I hope everyone's clear these libdrm_amdgpu changes won't be sufficient uAPI validation to allow the kernel bits to be merged upstream. This will require an implementation in the Mesa radeonsi / RADV driver, ideally with working implicit synchronization for BOs shared via dma-buf. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
