Triple buffering
At the moment, kwin_wayland
always uses double-buffering. It works great for our needs - avoid tearing and keep latency at reasonable levels. However, this is not optimal for low-end hardware, e.g. non-gaming laptops. For that kind of hardware, kwin_wayland
should fallback to triple buffering to keep frame rate at the same level as kwin_x11
.
kwin_x11
has a heuristic that forces triple buffering operation mode when it discovers an intel gpu. If it's an amd gpu, kwin_x11
will use double-buffering. This lets us to have both: optimize latency when running with more powerful hardware and have more smoother animations when running on a laptop.
State of the things
X11
Mesa has an internal queue of buffers that KWin has rendered to. Some time before vblank, one buffer gets taken out of the queue for presentation, and the buffer used for presentation before becomes available again for KWin to render with. So this increases latency by n frames (probably one or two), but it also gives the GPU more time to finish rendering.
Wayland
-
kwin_wayland
: always uses double-buffering -
mutter
: always uses double-buffering, but there's wip patch to add support for triple buffering https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441 -
wlroots
-based compositors: use double-buffering too
KMS API considerations
At the moment, once a page flip is scheduled, the compositor cannot schedule another one or replace existing one.
FIFO
mode can be implemented with the existing API in the userspace by making the compositor queue pending updates and dequeue them in the page flip handler.
MAILBOX
mode can be implemented by amending previous atomic commit. There are two problems with this solution: the necessary API is not present yet and MAILBOX can't be properly implemented in the userspace. For example, what if the compositor decides to amend an atomic commit when vblank happens? Buffer switching must happen in the vblank handler in the driver.
In both cases, the compositor would need some careful state tracking changes, particularly when using output layers or moving the cursor.
The compositor side can be simplified and made less error prone by specifying the presentation mode to the DRM driver and letting it to take care of FIFO
or MAILBOX
presentation mode.
zzag: The definitive position of the DRM developers on this matter is unknown to us yet. We need to ask them what they think about it.
Other potential ways to improve smoothness of animations on Wayland
Besides employing triple buffering, it's also worth considering introducing a special animation mode during which GPU's core and memory clock frequencies are boosted.
zzag: Needs somebody to do proper research in this area. Particularly, power usage and whether it actually helps to solve the problem.