On Mon, Feb 6, 2023 at 10:39 AM Michel Dänzer <michel.daen...@mailbox.org> wrote: > > On 2/3/23 22:54, Shashank Sharma wrote: > > From: Shashank Sharma <contactshashanksha...@gmail.com> > > > > 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 >
