Hi! On 2023-04-04 04:50, Christian König wrote: > 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)
There seems to be a dependency here. Is it possible to express this dependency so that this work is done on vblank, then whoever needs this, can latch onto vblank and get scheduled and completed before the vblank? The problem generally is "We need to do some work B in order to satisfy some condition in work A. Let's raise the ``priority'' of work B so that if A needs it, when it needs it, it is ready." Or something to that effect. The system would be much more responsive and run optimally, if such dependencies are expressed directly, as opposed to trying to game the scheduler and add more and more priorities, one on top of the other, every so often. It's okay to have priorities when tasks are independent and unrelated. But when they do depend on each other directly, or indirectly (as in when memory allocation or freeing is concerned), thus creating priority inversion, then the best scheduler is the fair, oldest-ready-first scheduling, which is the default GPU scheduler in DRM at the moment (for the last few months). >> 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. Are there no dependencies between them? I mean if they're independent, we already have run queues with different priorities. But if they're dependent, perhaps we can express this explicitly so that we don't starve other tasks/queues... Regards, Luben > > 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 🐸✨ >> >
