On Mon, Feb 6, 2023 at 10:39 AM Michel Dänzer <michel.daenzer@xxxxxxxxxxx> wrote: > > 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. Right, this is just what we have been using to bring up the feature so far. Alex > > 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 >
