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
