From 02dc821ced6d786af712fcacd13462210bb34009 Mon Sep 17 00:00:00 2001 From: Jason Ekstrand Date: Fri, 12 Nov 2021 04:12:50 -0600 Subject: [PATCH] Don't end command buffers before resetting them (#969) This isn't necessary. The Vulkan spec has only one restriction on the state of a command buffer when vkResetCommandBuffer is called: "commandBuffer must not be in the pending state" So as long as it's not currently waiting to be executed on the GPU, we can reset it. By contrast, vkEndCommandBuffer is tightly restricted and can only be called when a command buffer is in the recording state which it's not guaranteed to be when the guard is destroyed. This fixes a crash that happens in certain Amber-based Vulkan CTS tests after a VK_ERROR_DEVICE_LOST because Amber is calling vkEndCommandBuffer on command buffers that were never begun. --- src/vulkan/command_buffer.cc | 1 - 1 file changed, 1 deletion(-) diff --git a/src/vulkan/command_buffer.cc b/src/vulkan/command_buffer.cc index 2843667eb..765ef94f3 100644 --- a/src/vulkan/command_buffer.cc +++ b/src/vulkan/command_buffer.cc @@ -108,7 +108,6 @@ Result CommandBuffer::SubmitAndReset(uint32_t timeout_ms) { void CommandBuffer::Reset() { if (guarded_) { - device_->GetPtrs()->vkEndCommandBuffer(command_); device_->GetPtrs()->vkResetCommandBuffer(command_, 0); guarded_ = false; }