Re: [PATCH 0/8] AMDGPU usermode queues

["Christian König" <ckoenig.leichtzumerken@gmail.com>]

Am 06.02.23 um 01:52 schrieb Dave Airlie:
> On Sat, 4 Feb 2023 at 07:54, Shashank Sharma <shashank.sharma@amd.com> wrote:
>> From: Shashank Sharma <contactshashanksharma@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.
> So I just have one question about forward progress here, let's call it
> the 51% of VRAM problem.
>
> You have two apps they both have working sets that allocate > 51% of VRAM.

Marek and I have been working on this quite extensively.

> Application (a) has the VRAM and mapping for the user queues and is
> submitting work
> Application (b) wants to submit work, it has no queue mapping as it
> was previously evicted, does (b) have to call an ioctl to get it's
> mapping back?

Long story short: No, but that's a bit more complicated to explain.

> When (b) calls the ioctl (a) loses it mapping. Control returns to (b),
> but before it submits any work on the ring mapping it has, (a) gets
> control and notices it has no queues, so calls the ioctl, and (b)
> loses it mapping, and around and around they go never making forward
> progress.
>
> What's the exit strategy for something like that, fall back to kernel
> submit so you can get a memory objects validated and submit some work?

First of all the fw makes sure that processes can only be evicted after 
they used up their time slice. So when you have two processes fighting 
over a shared resource (can be memory, locks or whatever) they will 
always get until the end of their time slice before they are pushed away 
from the hw.

Then when a process is evicted we take a look at what the process has 
already scheduled as work on the hw. If the process isn't idle we start 
a delayed work item to get it going again (similar to what the KFD is 
doing at the moment). When the process is idle we unmap the doorbell 
page(s) from the CPU and wait for the page fault which signals that the 
process wants to submit something again.

And the last component is a static resource management which distributes 
the available resources equally between the different active processes 
fighting over them. Activity of a process is determined by the periodic 
interrupts send by the hw for running processes.

I call the memory management algorithm based on this Robin Hood 
(https://drive.google.com/file/d/1vIrX37c3B2IgWFtZ2UpeKxh0-YMlV6NU/view) 
and simulated that a bit in some spread sheets, but it isn't fully 
implemented yet. I'm working on this for a couple of years now and 
slowly pushing DRM/TTM into the direction we need for this to work.

Christian.

>
> Dave.