From ed2bb692f7f3dd94a6e6b76ce30179f15d0825d2 Mon Sep 17 00:00:00 2001 From: Derek Foreman Date: Wed, 13 Nov 2024 13:12:56 -0600 Subject: [PATCH] vulkan/wsi/wayland: Fix time calculation When occluded, the current math always rounds down to 0 cycles and leads to improperly throttled frame delivery. Improve the comment, and use a formula that leads to generating future times even when occluded. Also remove some dead code, as we can never get here with a period of 0. Signed-off-by: Derek Foreman Fixes: c26ab1aee1dd ("vulkan/wsi/wayland: Pace frames with commit-timing-v1") Part-of: --- src/vulkan/wsi/wsi_common_wayland.c | 33 +++++++++++++++++++++-------- 1 file changed, 24 insertions(+), 9 deletions(-) diff --git a/src/vulkan/wsi/wsi_common_wayland.c b/src/vulkan/wsi/wsi_common_wayland.c index b317e4ca2e6..b51b17db7f1 100644 --- a/src/vulkan/wsi/wsi_common_wayland.c +++ b/src/vulkan/wsi/wsi_common_wayland.c @@ -279,9 +279,6 @@ next_phase_locked_time(uint64_t base, uint64_t period, uint64_t from) if (base == 0) return from; - if (period == 0) - period = 16666666; - /* If our time base is in the future (which can happen when using * presentation feedback events), target the next possible * presentation time. @@ -289,13 +286,31 @@ next_phase_locked_time(uint64_t base, uint64_t period, uint64_t from) if (base >= from) return base + period; - /* Round up our cycle count so imprecision in feedback times doesn't - * lead to a time just after a refresh and a time just before the - * following refresh producing the same cycle count. + /* The presentation time extension recommends that the compositor + * use a clock with "precision of one millisecond or better", + * so we shouldn't rely on these times being perfectly precise. + * + * Additionally, some compositors round off feedback times + * internally, (eg: to microsecond precision), so our times can + * have some jitter in either direction. + * + * We need to be especially careful not to miss an opportunity + * to display by calculating a cycle too far into the future. + * This will cause delays in frame presentation. + * + * If we choose a cycle too soon, fifo barrier will still keep + * the pace properly, except in the case of occluded surfaces - + * but occluded surfaces don't move their base time in response + * to presentation events, so there is no jitter and the math + * is more forgiving. That case just needs to monotonically + * increase. + * + * We fairly arbitrarily use period / 4 here to try to stay + * well away from rounding up too far, but to also avoid + * scheduling too soon if the time values are imprecise. */ - cycles = (from - base + period - 1) / period; - target = base + cycles * period; - + cycles = (from - base + period / 4) / period; + target = base + (cycles + 1) * period; return target; }