YaLTeR commented 4 years ago

4588 introduced the ability to set up constant repaint delays for outputs and views in order to reduce visual latency. However, setting them up is a little involved, and we can do better, automatically.

It's important to note that the minimal time between a DRM commit and vblank varies based on the damaged region and possibly other things.

The safe simple first idea to try for the automatic adjustment is: start with 1 millisecond max_render_time for outputs, then if a frame was dropped increment it by 1 (with a threshold past which it's just turned off). The main downside is that this method cannot reduce the latency back down when the damaged region reduces (for example, when quitting out of a full-screen game back to calm desktop usage).

Another idea is to somehow measure how much time it takes from starting compositing to presentation and use that to compute max_render_time. Not sure how and if that would work.

For views, similar strategies could be explored. It's actually possible to do even better than the constant delays here as max_render_time can only be set on a per-view granularity (for configuration convenience), but automatic adjustment can work on a per-surface granularity (where it should be).

emersion commented 3 years ago

Ref https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1620

YaLTeR commented 3 years ago

For the reference, I implemented this in Mutter at https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1620. See the MR for detailed explanations, but the gist is that I estimate:

The minimum time from DRM buffer swap to successful flip (an estimate hopefully generic enough to take into account e.g. varying GPU workload).
The maximum time from start of compositing to buffer swap.
(for per-surface max_render_time) The maximum time from frame callback to surface committing a new buffer.

So far in my tests it works reasonably well even for heavier workloads in mutter / gnome-shell. Note that in mutter the surface delays are per-surface rather than per-view as in sway (a limitation of manual configuration rather than wlroots).

Ref https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1620

You beat me to it. :)

emersion commented 3 years ago

Ref https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_timer_query.txt

swaywm / sway

Automatic adjustment of repaint delays #4734

4588 introduced the ability to set up constant repaint delays for outputs and views in order to reduce visual latency. However, setting them up is a little involved, and we can do better, automatically.