[RFC PATCH 0/4] uapi, drm: Add and implement RLIMIT_GPUPRIO

[Christian König]

Adding a bunch of people who have been involved in this before.

Am 03.04.23 um 22:15 schrieb Joshua Ashton:
> On 4/3/23 20:54, Christian König wrote:
>> Am 03.04.23 um 21:40 schrieb Joshua Ashton:
>>> [SNIP]
>>> Anyway, please let me know what you think!
>>> Definitely open to any feedback and advice you may have. :D
>>
>> Well the basic problem is that higher priority queues can be used to 
>> starve low priority queues.
>>
>> This starvation in turn is very very bad for memory management since 
>> the dma_fence's the GPU scheduler deals with have very strong 
>> restrictions.
>>
>> Even exposing this under CAP_SYS_NICE is questionable, so we will 
>> most likely have to NAK this.
>
> This is already exposed with CAP_SYS_NICE and is relied on by SteamVR 
> for async reprojection and Gamescope's composite path on Steam Deck.

Yeah, I know I was the one who designed that :)

>
> Having a high priority async compute queue is really really important 
> and advantageous for these tasks.
>
> The majority of usecases for something like this is going to be a 
> compositor which does some really tiny amount of work per-frame but is 
> incredibly latency dependent (as it depends on latching onto buffers 
> just before vblank to do it's work)
>
> Starving and surpassing work on other queues is kind of the entire 
> point. Gamescope and SteamVR do it on ACE as well so GFX work can run 
> alongside it.

Yes, unfortunately exactly that.

The problem is that our memory management is designed around the idea 
that submissions to the hardware are guaranteed to finish at some point 
in the future.

When we now have a functionality which allows to extend the amount of 
time some work needs to finish on the hardware infinitely, then we have 
a major problem at hand.

What we could do is to make the GPU scheduler more clever and make sure 
that while higher priority submissions get precedence and can even 
preempt low priority submissions we still guarantee some forward 
progress for everybody.

Luben has been looking into a similar problem AMD internally as well, 
maybe he has some idea here but I doubt that the solution will be simple.

Regards,
Christian.

>
> - Joshie 🐸✨
>