Skip to content

Tearing updates protocol

Xaver Hugl requested to merge Zamundaaa/wayland-protocols:tearing-updates into main

This protocol is meant to be used by drivers to be able to hint to the compositor if and when it should employ asynchronous page flips for presentation. To achieve this there are two presentation modes:

  • VSync: The latest available frame from the client gets presented with VSync, tearing cannot be observed. Fitting client-side presentation modes are mailbox and FIFO. Screenshot_20210321_141410

  • Async: Frames from the client are presented with asynchronous page flips as soon as possible after commit, tearing can be observed. A fitting client-side presentation mode is immediate. Screenshot_20210321_141435

To make sure we're all on the same page, here is a summary as to what exactly asynchronous page flips do and why they matter:

Most, if not all modern displays update their pixels in rows, from left to right and top to bottom, and do that in a fixed time-frame. A 60Hz monitor for example will take about 16.67ms to update the whole screen, including the time the screen takes to switch back to the top (which is called the vblank interval). A GPU can synchronize with that updating to make sure only one whole image gets shown per update cycle: The image only gets changed at the vblank interval.

With asynchronous page flips we don't do that synchronisation; once a new image from the application comes in the image that is getting sent to the display gets immediately updated. This will cause visual breakages called tearing: at one or multiple rows in the display the image abruptly changes (here is a simulated example image).

While that is undesired for desktop usage, it does have two benefits, almost exclusively for games:

  • asynchronous page flips remove stutter. With VSync
    • if the application provides frames slower than the refresh rate of the display then it is possible to get repeated frames:
      • application frames: 1 2 3 4 5 6 7
      • display frames: | | | | | | | | |
      • what you see: |1 |1 |2 |3 |4 |5 |6 |6 |
    • or if the application provides frames faster than the refresh rate then you can get skipped frames:
      • application frames: 1 2 3 4 5 6 7 8 9 10 11
      • display frames: | | | | | | | | |
      • what you see: |1 |2 |3 |5 |6 |7 |9 |10 |
  • asynchronous page flips reduce latency. This comes from two factors:
    • in order to prevent stutter, compositors submit frames some time before vblank; It estimates the time it needs to get the application frame to a state where it can be scanned out (be it importing with gbm to scan it out directly or compositing) and adds a safety margin to it. I don't know how other compositors handle it but with KWin the lowest possible compositor introduced latency is currently 4.6ms on a 60Hz monitor and 3.7ms on a 144Hz monitor
    • As the image is only changed at vblank with vertical synchronisation there is an inherent latency, depending on where the content on the display is. As an example with an ego shooter the user mostly cares about the content at a height of about the middle of the display: In the worst case of a user input happening either while the last frame before vblank is rendered or right after vblank will have an inherent latency of about 25ms, with tearing updates that gets reduced to about 8ms. Here is an illustration of such a scenario: https://i.imgur.com/zN2D4ir.png

Do note that while all of that can be vastly improved with VRR and high refresh rate monitors, adoption of those is neither always possible because of financial restraints or other reasons, nor does it completely solve the latency introduced.

Edited by Xaver Hugl

Merge request reports