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?
I currently don't have an idea how, with direct scanout ie. single
rendering client, FIFO vs RR would make a difference.
For scenarios where copying is involved, experimenting/tweaking the
frontend/DRM scheduler is not trivial. In the sense that for some
approaches involving looking at the submission queue depth, such I
mentioned before, it would require non-trivial refactoring. Which does
not seem to be popular. And the resulting change in behaviour would be
driver dependant too.
Btw what is the situation with context priority and compositors? Are
they requesting high or sticking with the defaults?
Regards,
Tvrtko
