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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 🐸✨





[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux