Vulkan: Free recording context semaphores on destroy.

Previously the code ASSERTed that the semaphores didn't exist on
destroy, but that's not necessarily the case. Handle destruction more
correctly.

Bug: dawn:269

Change-Id: If123e0e20b4ee157c70a1b8cc2f3b20a9473f55e
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/17963
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
This commit is contained in:
Corentin Wallez 2020-03-27 16:48:39 +00:00 committed by Commit Bot service account
parent e784d8d0dc
commit ffd94da5f1
1 changed files with 10 additions and 6 deletions

View File

@ -777,6 +777,16 @@ namespace dawn_native { namespace vulkan {
mRecordingContext.used = false;
fn.DestroyCommandPool(mVkDevice, mRecordingContext.commandPool, nullptr);
for (VkSemaphore semaphore : mRecordingContext.waitSemaphores) {
fn.DestroySemaphore(mVkDevice, semaphore, nullptr);
}
mRecordingContext.waitSemaphores.clear();
for (VkSemaphore semaphore : mRecordingContext.signalSemaphores) {
fn.DestroySemaphore(mVkDevice, semaphore, nullptr);
}
mRecordingContext.signalSemaphores.clear();
// Some operations might have been started since the last submit and waiting
// on a serial that doesn't have a corresponding fence enqueued. Force all
// operations to look as if they were completed (because they were).
@ -791,12 +801,6 @@ namespace dawn_native { namespace vulkan {
}
mUnusedCommands.clear();
// TODO(jiajie.hu@intel.com): In rare cases, a DAWN_TRY() failure may leave semaphores
// untagged for deletion. But for most of the time when everything goes well, these
// assertions can be helpful in catching bugs.
ASSERT(mRecordingContext.waitSemaphores.empty());
ASSERT(mRecordingContext.signalSemaphores.empty());
for (VkFence fence : mUnusedFences) {
fn.DestroyFence(mVkDevice, fence, nullptr);
}