gfx-rs / wgpu

A cross-platform, safe, pure-Rust graphics API.
https://wgpu.rs
Apache License 2.0
12.4k stars 908 forks source link

Vulkan validation error: semaphore must not have any pending operations when calling `Surface::get_current_texture` #5906

Closed ten3roberts closed 3 months ago

ten3roberts commented 3 months ago

Description Semaphore must not have any pending operations is triggered by the vulkan validations when acquiring the next surface texture.

I have not been able to find a minimal reproduction of this issue, and this issue started appearing when the rendering got more complex; most specifically taking more time per frame.

If I further increase the time taken in the shader (skybox convolution shader), the device becomes lost.

The following commit experiences the error: https://github.com/ten3roberts/ivy/pull/7/commits/5ae30c1299272172e9a3949efe9607e39589c960

Removing the time intensive skybox convolving code removes the validation error, so it is likely time-dependent.

Expected vs observed behavior Validation errors should not error on invalid semaphore usage

Extra materials

 INFO get next surface texture
 INFO present
 INFO get next surface texture
 INFO present
 INFO get next surface texture
 INFO present
 INFO get next surface texture
 INFO present
 INFO get next surface texture
ERROR VALIDATION [VUID-vkAcquireNextImageKHR-semaphore-01779 (0x5717e75b)]
        Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0xd000000000d, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNex
tImageKHR():  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)
ERROR   objects: (type: SEMAPHORE, hndl: 0xd000000000d, name: ?)
 INFO present
 INFO get next surface texture
ERROR VALIDATION [VUID-vkAcquireNextImageKHR-semaphore-01779 (0x5717e75b)]
        Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0xe000000000e, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNex
tImageKHR():  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)
ERROR   objects: (type: SEMAPHORE, hndl: 0xe000000000e, name: ?)
 INFO present
 INFO get next surface texture
ERROR VALIDATION [VUID-vkAcquireNextImageKHR-semaphore-01779 (0x5717e75b)]
        Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0xf000000000f, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNex
tImageKHR():  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)
ERROR   objects: (type: SEMAPHORE, hndl: 0xf000000000f, name: ?)

Platforms

  1. Linux; nvidia 550 (validation error; device lost if increase complexity even more)
  2. HP Probook, Intel integrated graphics (device lost)
ten3roberts commented 3 months ago

I have tried submitting the heavy work on the same queue prior to getting the first image, and within a get_current_texture/present pair, and the same result is observed.

The issue is fixed and no validations errors are observed if I comment out the draw command for the compute heavy/time heavy convolution code on both my 2 devices I tried.

Is it incorrect to create textures while recording an encoder, or is that ok behavior?

cwfitzgerald commented 3 months ago

Thanks for filling! Updating wgpu to 0.20.1 or newer should fix this.

ten3roberts commented 3 months ago

Thanks for filling! Updating wgpu to 0.20.1 or newer should fix this.

Thanks for the reply. I recall trying that, as well as https://github.com/gfx-rs/wgpu/pull/5681 separately, but same thing

I'll try again later and let you know what I see :)