Commit 55840e902470f95fe0f7d81fcf485abf16bf71a4
2021-12-03T15:24:00
Vulkan: Fix deferred flush vs UtilsVk Take the following scenario: 1. Draw 2. Flush (this is deferred) 3. Get image view (this is retain()ed) 4. Pass view to a draw-based UtilsVk function 5. Flush 6. Delete image view At step 4, UtilsVk may start a new render pass and use the image view from step 3. Since the flush at step 2 is deferred, it will be performed at this step, and so the serial of the image view is set to the previous submission. When step 4 uses this view, it doesn't retain it. Step 5 submits the new command buffer using this image view. At step 6, if the previous submission has finished, it will destroy the view immediately even though it's in use by the new submission. One solution could have been to make sure render pass closure originating from UtilsVk doesn't incur a flush. However, due to the current design where the render pass is immediately recorded in RendererVk's primary command buffer, it's possible that an unrelated context would perform the flush anyway. This change makes sure instead that the render pass is closed before any views are allocated/retained to be used by UtilsVk. Bug: chromium:1272266 Change-Id: I5bdefb34e03c368511c4c174cf7965fda158d2b8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3315976 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>