Vulkan CommandBuffer in use after vkDeviceWait Idle-CodePudding

During initialization of my program I want to use some single time command buffers for image layout transitions and acceleration structure building etc.

However, I can't seem to free the command buffer once it's finished.

VkCommandBuffer AppContext::singleTimeCommandBuffer() const {
    VkCommandBuffer ret;
    auto allocInfo = vks::initializers::commandBufferAllocateInfo(vkCommandPool, VK_COMMAND_BUFFER_LEVEL_PRIMARY, 1);
    vkCheck(vkAllocateCommandBuffers(vkDevice, &allocInfo, &ret));
    auto beginInfo = vks::initializers::commandBufferBeginInfo();
    beginInfo.flags = VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT;
    vkCheck(vkBeginCommandBuffer(ret, &beginInfo));
    return ret;
}

void AppContext::endSingleTimeCommands(VkCommandBuffer cmdBuffer) const {
    vkCheck(vkEndCommandBuffer(cmdBuffer));
    auto submitInfo = vks::initializers::submitInfo(&cmdBuffer);
    vkQueueSubmit(queues.graphics, 1, &submitInfo, VK_NULL_HANDLE);

    vkQueueWaitIdle(queues.graphics);
    // Overkill, I know
    vkDeviceWaitIdle(vkDevice);
    vkFreeCommandBuffers(vkDevice, vkCommandPool, 1, &cmdBuffer);
}

Which produces the following validation error:

VUID-vkFreeCommandBuffers-pCommandBuffers-00047(ERROR / SPEC): msgNum: 448332540 - Validation Error: [ VUID-vkFreeCommandBuffers-pCommandBuffers-00047 ] Object 0: handle = 0x5586acaeff78, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x1ab902fc | Attempt to free VkCommandBuffer 0x5586acaeff78[] which is in use. The Vulkan spec states: All elements of pCommandBuffers must not be in the pending state (https://vulkan.lunarg.com/doc/view/1.2.182.0/linux/1.2-extensions/vkspec.html#VUID-vkFreeCommandBuffers-pCommandBuffers-00047)
    Objects: 1
        [0] 0x5586acaeff78, type: 6, name: NULL

I don't see how this makes sense since the VkQueueWaitIdle as well as the vkDeviceWaitIdle should ensure the command buffer to not be in the pending state. Am I misunderstanding the Vulkan specs or might I have stumbled upon a bug in the video driver, or perhaps the validation layer?

CodePudding user response：

You aren't checking the return values of vkQueueSubmit(), vkQueueWaitIdle() or vkDeviceWaitIdle(). Are any of them failing? That could cause this error.