Present-to-present time, especially while we wait for VK_EXT_present_timing to become adopted, can only be indirectly measured. This makes just-in-time rendering unnecessarily hard. High-accuracy event timings can only be made for rendering, not presentation. The missed latches can be seen by phase doubling. Waiting on the last frame to finish displaying requires use of a fence on a separate timing thread. The timings provided by this and by VK_KHR_present_wait are muddied with OS scheduler latency. Spin-locking the waits with zero timeouts should be a thing, but does not seem to be guaranteed. The compositor also seems to inject scheduler jitter.

After all that, people can talk about averaging methods, but there's a lot to be done before what this blog is talking about is even available.

The reason solving just-in-time rendering is important is because queue priority is not actually supported by most drivers. Some extensions can give us global priority for the process, not real priority for queues. The right way then to avoid workload A from causing workload B to miss a latch is to put workload A into the idle time that would exist from running B just in time. This is itself a luxury based on the fact that workload B is lightweight enough that its own uncertainty can only rarely exceed the latch deadline.

At least on VRR displays, making B a bit late has much less dire consequences, but driving refresh from the application needs exclusive access to the display, and not all compositors want to provide this.

Please do reach out if it seems like I'm only still catching up. I'm sure someone knows a decent way to get sub-millisecond just-in-time rendering accuracy without watching the phase suddenly double on FRR. Ping https://github.com/positron-solutions/mutate and we can get in touch.