Skip to content

Conversation

@HansKristian-Work
Copy link
Owner

No description provided.

Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Also demonstrate present interval > 1.

Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Benign, but it is invalid.

Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
@mbriar
Copy link

mbriar commented Dec 12, 2025

Will this eventually allow to implement SyncInterval > 1 with proper frame pacing? I believe right now it would use a framelimiter that won't vsync window reliably? It looks like it would require presentAtAbsoluteTimeSupported or presentAtRelativeTimeSupported, so from the current state of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38770 that means x11/xwayland or a wayland compositor with commit_timing support, is that correct?

@HansKristian-Work
Copy link
Owner Author

HansKristian-Work commented Dec 12, 2025

That is the point of this, yes. It's already working on Mesa MR and NV vulkan beta drivers. But won't work in Proton until winevulkan adds proper support for EXT_present_timing.

@HansKristian-Work HansKristian-Work force-pushed the present-timing branch 5 times, most recently from 9079f4f to bfd85d3 Compare December 12, 2025 16:23
… their newest iteration.

Use present_id2/wait2 when available and KHR_swapchain_maintenance1.
Get rid of legacy path where we block on CPU progress in ::Present().
It's completely irrelevant these days since all relevant
platforms support KHR_present_wait(2) just fine.

Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants