Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Semaphore must not have any pending operations #5644

Closed
hecrj opened this issue May 1, 2024 · 7 comments
Closed

Semaphore must not have any pending operations #5644

hecrj opened this issue May 1, 2024 · 7 comments

Comments

@hecrj
Copy link
Contributor

hecrj commented May 1, 2024

Description
I have updated iced to use the latest release (see iced-rs/iced#2417). While 0.19 works perfectly fine, 0.20 is very sluggish and I seem to be constantly hitting a validation error:

2024-05-01T14:25:29.145657Z ERROR wgpu_hal::vulkan::instance: VALIDATION [VUID-vkAcquireNextImageKHR-semaphore-01779 (0x5717e75b)]
        Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0x4fac1c0000000032, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR():  Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)
2024-05-01T14:25:29.145682Z ERROR wgpu_hal::vulkan::instance:   objects: (type: SEMAPHORE, hndl: 0x4fac1c0000000032, name: ?)

The upgrade was straightforward—it only involved adding default compilation_options everywhere, so not quite sure what's up.

Repro steps
Most examples of the iced repository (like the tour) in the wgpu-0.20 branch have the issue.

Expected vs observed behavior
It should work well like 0.19 and not produce validation errors.

Extra materials
Validation log pasted in description.

Platform
Arch Linux, X11, NVIDIA RTX 4090, proprietary drivers.

@cwfitzgerald
Copy link
Member

This is almost certainly #5559

@cwfitzgerald cwfitzgerald closed this as not planned Won't fix, can't repro, duplicate, stale May 1, 2024
@hecrj
Copy link
Contributor Author

hecrj commented May 6, 2024

@cwfitzgerald Was this introduced in 0.20? 0.19 does not have the issue I reported.

I ran cargo flamegraph with one of the examples and noticed that almost all of the time is now spent in Surface::present:

flamegraph

@hecrj
Copy link
Contributor Author

hecrj commented May 6, 2024

Here is 0.19 with the same example, for comparison:

flamegraph

@hecrj
Copy link
Contributor Author

hecrj commented May 6, 2024

Same behavior with the cube example of the repository:

v0.20

flamegraph

v0.19

flamegraph

@cwfitzgerald
Copy link
Member

I'm honestly not sure when synchronization changed, I just noticed it's very wrong on trunk a bit ago. It seems to be causing problems, so I'll try and fix this.

@jimblandy jimblandy reopened this May 6, 2024
@cwfitzgerald
Copy link
Member

This was closed as a dupe of #5559

@cwfitzgerald cwfitzgerald closed this as not planned Won't fix, can't repro, duplicate, stale May 6, 2024
@cwfitzgerald
Copy link
Member

@hecrj Can you try #5681 to see if this fixes your issue?

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

No branches or pull requests

3 participants