Draft: alternative present-timing protocol
- Jul 27, 2021
-
-
Sebastian Wick authored
Signed-off-by:
Sebastian Wick <sebastian@sebastianwick.net>
d02e6d99
-
Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Equinix is shutting down its operations with us on April 30, 2025. They have graciously supported us for almost 5 years, but all good things come to an end.
Given the time frame, it's going to be hard to make a smooth transition of the cluster to somewhere else (TBD). Please expect in the next months some hiccups in the service and probably at least a full week of downtime to transfer gitlab to a different place.
All help is appreciated.
This is another attempt at making presentations work well. The previous one by @afrantzis sits at !45 which is modeled after the WIP VK_EXT_present_timing Vulkan extension. The extension in its current form however results in stutter and high latency for cases where the buffer readiness deadline is earlier than the presentation (IOW in composited cases).
This protocol explicitly communicates the refresh cycle including the buffer readiness deadline, the presentation time and the time the presentation becomes visible.
It also takes a lesson from the surface suspension protocol !99 (closed) and explicitly communicates the lack of a refresh cycle.
The ideal and optional presentation times were removed because they are redundant with the refresh cycle known.
It allows presentation hints to be set with the first user being a tearing hint to let applications opt into tearing content updates (effectively pulling in !65 (merged)).
It makes the presentation-time protocol redundant. Instead of splitting feedback between the two protocol I've chosen to pull in all the information available from presentation-time.
VRR mode is accounted for. There is two cases, the first one is when the VRR mode is controlled by another entity and the surface just has to adapt to the variable refresh cycle which works without any VRR specific information. The second case is when the surface is controlling the VRR by setting the target present time and the refresh becomes a range which again is explicitly communicated.
There is a few issues with the protocol that I know of right now:
All feedback welcome, especially about the refresh cycle idea.
Signed-off-by:
Sebastian Wick <sebastian@sebastianwick.net>