Semaphore must not have any pending operations
hecrj opened this issue · 7 comments
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.
This is almost certainly #5559
@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:
Here is 0.19 with the same example, for comparison:
Same behavior with the cube example of the repository:
v0.20
v0.19
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.
This was closed as a dupe of #5559