[RFC 00/14] Deadline scheduler and other ideas

[Michel Dänzer]

On 2025-01-15 14:38, Tvrtko Ursulin wrote:
> On 13/01/2025 15:29, Michel Dänzer wrote:
>> On 2025-01-13 12:40, Tvrtko Ursulin wrote:
>>> On 10/01/2025 09:14, Michel Dänzer wrote:
>>>> On 2025-01-09 17:55, Tvrtko Ursulin wrote:
>>>>> On 09/01/2025 15:08, Michel Dänzer wrote:
>>>>>> On 2025-01-03 13:31, Christian König wrote:
>>>>>>
>>>>>>> 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?
>>>>
>>>> Don't think it has to be.
>>>>
>>>>> Any way to run it programmatically and get a performance number out?
>>>>
>>>> This could be tricky, since the game itself reports the same frame rate in both cases. You'd have to compare the frame times in the compositor instead.
>>>
>>> So missed frames in the compositor?
>>
>> Rather in Xwayland, the compositor is where it's visible to the user.
> 
> How would you suggest to instrument this, or what debug/logs to enable to see it?
>>>> Also, the issue might no longer be reproducible in this particular scenario with current Xwayland, because it should no longer do any GPU copies for presentation but just forward the client buffers to the compositor.
>>> Do you have an idea how could we find out more about that what you said: "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"?
>>
>> Other than asking affected users for more information, not offhand.
> 
> Could you find out more?

Sorry, I don't have any particular personal interest or stake in this. I'm just pointing out that "FIFO is better than RR" isn't universally true.

Reaching out to affected users on https://gitlab.freedesktop.org/drm/amd/-/issues/2516 would seem like a possible start.


> I currently don't have an idea how, with direct scanout ie. single rendering client, FIFO vs RR would make a difference.

I saw one user mentioning they have "many background tasks", maybe some of those are using the GPU as well.


> Btw what is the situation with context priority and compositors? Are they requesting high or sticking with the defaults?

Requesting high. (Not that it makes much difference in practice if higher-priority jobs can't preempt lower-priority ones already in flight, as is the case with amdgpu without user-mode queues)


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast