Skip to content

Vulkan: Don't wait for vkAcquireNextImage fence on non-Windows targets#9486

Open
cohaereo wants to merge 1 commit intogfx-rs:trunkfrom
cohaereo:skip-fence-wait-on-non-windows
Open

Vulkan: Don't wait for vkAcquireNextImage fence on non-Windows targets#9486
cohaereo wants to merge 1 commit intogfx-rs:trunkfrom
cohaereo:skip-fence-wait-on-non-windows

Conversation

@cohaereo
Copy link
Copy Markdown

@cohaereo cohaereo commented May 2, 2026

Connections
Related issue #8310

Original implementation #8420

Description
The fence wait was originally added to improve frame pacing on Windows, and should have effectively been a no-op on other platforms. However, on specifically Linux NVIDIA drivers, this causes frequent ~10ms stutters, resulting in major performance degradation.

This PR removes the fence wait on non-Windows targets altogether, improving frame pacing and overall performance for those targets.

Testing
Manually tested

Squash or Rebase?

Rebase

Checklist

  • I self-reviewed and fully understand this PR.
  • WebGPU implementations built with wgpu may be affected behaviorally.
  • Validation and feature gates are in place to confine behavioral changes.
  • Tests demonstrate the validation and altered logic works.
  • CHANGELOG.md entries for the user-facing effects of this change are present.
  • The PR is minimal, and doesn't make sense to land as multiple PRs.
  • Commits are logically scoped and individually reviewable.
  • The PR description has enough context to understand the motivation and solution implemented.

@inner-daemons
Copy link
Copy Markdown
Collaborator

@cohaereo Do you have benchmarks or anything to prove that this really is beneficial? I don't think this was a problem we were aware existed.

@cohaereo
Copy link
Copy Markdown
Author

cohaereo commented May 6, 2026

I've benchmarked this using mangohud in my own application as well as a few of the wgpu examples:
image
image

For the WGPU example i had to disable pre_present_notify to prevent Wayland from throttling the redraw requests to VSync, as the issue isn't really visible in a simple benchmark when VSync is enabled, with nor without the patch:
image

The occasional 10ms fence spikes appear far less often on vsync than at high framerates, but they can still be noticeable in interactive applications like a game engine.

Additionally, the fix has been tested on other Linux systems with AMD/Adreno GPUs, and I couldn't measure any difference there:
adreno

I don't think this was a problem we were aware existed.

According to @cwfitzgerald:

cwfitzgerald — 02/05/2026, 21:22
This should have been basically a no-op on other platforms, but we have had reports about this being worse on various flavors of Linux, so we'd accept a PR limiting it to Windows

@cwfitzgerald cwfitzgerald self-assigned this May 6, 2026
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