Fix leak of the eager exportable VkSemaphore.
Exporting an exportable VkSemaphore doesn't implicitly destroy the VkSemaphore object. So instead of Detach()ing the VkSemaphore when it is first consumed, just let it go out of the scope and be destroyed with RAII. This also fixes the RAII by not destroying the VkSemaphore immediately and instead wait until it becomes unused. Found by running dawn_end2end_tests with the VVLs. Bug: chromium:1258986 Change-Id: I858839b3094eee0f575c07a8f18504680afb53e3 Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/103024 Kokoro: Kokoro <noreply+kokoro@google.com> Reviewed-by: Loko Kung <lokokung@google.com> Commit-Queue: Corentin Wallez <cwallez@chromium.org> Reviewed-by: Austin Eng <enga@chromium.org>
This commit is contained in:
parent
1d100e4270
commit
eebb7d5e52
|
@ -57,17 +57,11 @@ class ScopedSignalSemaphore : public NonMovable {
|
|||
: mDevice(device), mSemaphore(semaphore) {}
|
||||
~ScopedSignalSemaphore() {
|
||||
if (mSemaphore != VK_NULL_HANDLE) {
|
||||
ASSERT(mDevice);
|
||||
mDevice->fn.DestroySemaphore(mDevice->GetVkDevice(), mSemaphore, nullptr);
|
||||
mDevice->GetFencedDeleter()->DeleteWhenUnused(mSemaphore);
|
||||
}
|
||||
}
|
||||
|
||||
VkSemaphore Get() { return mSemaphore; }
|
||||
VkSemaphore Detach() {
|
||||
VkSemaphore semaphore = mSemaphore;
|
||||
mSemaphore = VK_NULL_HANDLE;
|
||||
return semaphore;
|
||||
}
|
||||
VkSemaphore* InitializeInto() { return &mSemaphore; }
|
||||
|
||||
private:
|
||||
|
@ -357,8 +351,7 @@ MaybeError Device::SubmitPendingCommands() {
|
|||
ExternalSemaphoreHandle semaphoreHandle;
|
||||
DAWN_TRY_ASSIGN(semaphoreHandle,
|
||||
mExternalSemaphoreService->ExportSemaphore(scopedSignalSemaphore.Get()));
|
||||
// The ownership of signal semaphore has been transferred, we no longer need to track it.
|
||||
scopedSignalSemaphore.Detach();
|
||||
|
||||
// Update all external textures, eagerly transitioned in the submit, with the exported
|
||||
// handle, and the duplicated handles.
|
||||
bool first = true;
|
||||
|
|
Loading…
Reference in New Issue