diff options
| author | Jason Ekstrand <jason@jlekstrand.net> | 2021-11-12 04:12:50 -0600 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2021-11-12 10:12:50 +0000 |
| commit | 02dc821ced6d786af712fcacd13462210bb34009 (patch) | |
| tree | 94ae8dd01ecd092e08ea7dfd4ebda7c48f5b061f | |
| parent | 209d92e2c27a333e723d24497e8c7a07b2f2eb39 (diff) | |
| download | amber-02dc821ced6d786af712fcacd13462210bb34009.tar.gz | |
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.
| -rw-r--r-- | src/vulkan/command_buffer.cc | 1 |
1 files changed, 0 insertions, 1 deletions
diff --git a/src/vulkan/command_buffer.cc b/src/vulkan/command_buffer.cc index 2843667..765ef94 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; } |