Gfx: Vulkan debug layer errors in quad and colour-uniforms examples

[Herschel]

cargo run --bin=quad --features=vulkan and cargo run --bin=colour-uniforms --features=vulkan on the master branch produce spew from the Vulkan validation layer:

VALIDATION [VUID-vkDestroyFramebuffer-framebuffer-00892 (0)] : Cannot call vkDestroyFramebuffer on VkFramebuffer 0x14e1d60000000033[] that is currently in use by a command buffer. The Vulkan spec states: All submitted commands that refer to framebuffer must have completed execution (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-vkDestroyFramebuffer-framebuffer-00892)

OS: Windows 10 Home 64-bit
GPU: Geforce GTX 1060
LunarG Vulkan SDK 1.1.121.0

[kvark]

Found an interesting link for our info - https://github.com/KhronosGroup/Vulkan-Docs/issues/117#issuecomment-206540937

[kvark]

It we have to change the way the fence operates on the frame, we could fence the artificial submission we do at present_surface and wait for it before re-using the swapchain image and destroying the framebuffer.

[kvark]

Upon further investigation, the quad validation error appears to be a bug in the validation layer itself - https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/12 , so it's harmless.
colour-uniform uses an entirely different swapchain model, needs to be looked at.

[Herschel]

These are the validation errors given by colour-uniform:

[2019-09-14T17:31:08Z ERROR gfx_backend_vulkan]
VALIDATION [VUID-vkEndCommandBuffer-commandBuffer-00060 (0)] : vkEndCommandBuffer(): It is invalid to issue this call inside an active VkRenderPass 0x18[]. The Vulkan spec states: If commandBuffer is a primary command buffer, there must not be an active render pass instance (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-vkEndCommandBuffer-commandBuffer-00060)
object info: (type: COMMAND_BUFFER, hndl: 2946642394896)

[2019-09-14T17:31:08Z ERROR gfx_backend_vulkan]
VALIDATION [VUID-VkPresentInfoKHR-pImageIndices-01296 (0)] : Images passed to present must be in layout VK_IMAGE_LAYOUT_PRESENT_SRC_KHR or VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR but is in VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL. The Vulkan spec states: Each element of pImageIndices must be the index of a presentable image acquired from the swapchain specified by the corresponding element of the pSwapchains array, and the presented image subresource must be in the VK_IMAGE_LAYOUT_PRESENT_SRC_KHR layout at the time the operation is executed on a VkDevice (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-VkPresentInfoKHR-pImageIndices-01296)
object info: (type: QUEUE, hndl: 2946638718992)

[kvark]

Oh, now I realize how the other error was caused by the same silly refactoring mistake. Thanks for confirmation!

On Sep 14, 2019, at 21:15, bors[bot] [e-mail] wrote:

Closed #3015 via #3017.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[kvark]

This is fixed for good by #3571