On 09/01/2025 15:08, Michel Dänzer wrote:
On 2025-01-03 13:31, Christian König wrote:
Am 03.01.25 um 13:02 schrieb Tvrtko Ursulin:
One big question is whether round-robin can really be removed. Does
anyone use
it, rely on it, or what are even use cases where it is much better
than FIFO.
So AFAICS Round Robin is not used anymore by anyone. And my
understanding indeed is, too, that there is not really any use-case
where one would like anything except for FIFO.
Looking at 977d97f18b5b ("drm/scheduler: Set the FIFO scheduling policy
as the default"), it seems to me that RR just was easy to implement and
it had the disadvantage of systems under high load cause the oldest job
to be starved to death, which is why FIFO was introduced.
So my guess would be that RR just is a relict.
If we agree on that, then we could remove RR in any case, and the
subsequent question would be whether FIFO should be replaced with
deadline (or: if there should be FIFO *and* deadline?), wouldn't it?
I am unsure about RR but I agree what is the second part of the question.
Well we came up with FIFO because we found that RR performed quite badly when you have a huge number of submitting applications.
E.g. one of our cloud test cases ran 100 instances of a single game and the worst response time improved massively by switching from RR to FIFO.
Different priorities on the other hand were originally invented to make sure the kernel has precedence over userspace. But later we also exposed the priorities to userspace which results in the problem that higher priority queues can starve low priority ones.
FWIW, that can't explain why RR worked better in the scenario I described in https://gitlab.freedesktop.org/drm/amd/-/issues/2516#note_2119750, Xwayland uses normal GPU scheduling priority, just like the game.
That's the other reason why I said that RR should probably be removed and FIFO changed in a way that the priority is basically just a bonus to the score used for sorting the FIFO. I haven't taken a deeper look yet, but I think that this is more or less what this patch set here does.
FWIW, people are saying RR works better than FIFO for some gaming scenarios even with current Xwayland, which shouldn't do any GPU copies for presentation of fullscreen windows. There seem to be other interactions which work better with RR than FIFO from the user PoV. If RR is to be removed, I'd recommend making sure deadline works at least as well as RR for those.
What FIFO is still missing compared to RR is some sort of fairness between queues. E.g. a queues which hasn't submitted something in a while might get a bonus for their submissions compared to a queue which submits stuff all the time (or something like that).
The lack of that could indeed explain the scenario above, if the game submits its GPU job for frame n+1 before Xwayland submits its GPU job for presenting frame n.
I would be keen to experiment with this. There is that last patch in v2
of my series which scales the deadlines based on queue depth. So for a
client which submits two frames it could be enough (in principle, not
the actually posted version) to push out the deadline at qd=2 so a
client which never breaks qd=1 can reliably overtake it.
What would really be great if you could suggest me as easy to set up as
possible test case with objective measuring criteria. And it would have
to run on AMD. Quake II RTX under XWayland as the GitLab issue suggest
or there is more to it? Does it has to be GNOME? Any way to run it
programmatically and get a performance number out?
Regards,
Tvrtko
