rhi: vk: fix offscreen frame command completion wait

Remove the if-there-is-more-than-one-swapchain condition. Surely in a
(onscreen) 0, (onscreen) 1, (offscreen) 0 frame sequence the wait is
essential when starting the offscreen frame. Otherwise we may be
deferred-releasing resources from the still active onscreen #0 frame.

The problem is only apparent with certain frame slot change sequences.
For instance (onscreen) 0, (offscreen) 1, (onscreen) 0 would not show
any problems.

Pick-to: 6.2
Change-Id: I705a0a3ab0b4bc9e4dc2b1c6ff60025d04c739b3
Reviewed-by: Andy Nichols <andy.nichols@qt.io>

1 files changed, 11 insertions, 11 deletions

diff --git a/src/gui/rhi/qrhivulkan.cpp b/src/gui/rhi/qrhivulkan.cpp
index 0bd3e6e95d..c0d5ab1c07 100644
--- a/src/gui/rhi/qrhivulkan.cpp
+++ b/src/gui/rhi/qrhivulkan.cpp
@@ -1932,8 +1932,8 @@ void QRhiVulkan::prepareNewFrame(QRhiCommandBuffer *cb)
     //
     // With multiple swapchains on the same QRhi things get more convoluted
     // (and currentFrameSlot strictly alternating is not true anymore) but
-    // beginNonWrapperFrame() solves that by blocking as necessary so the rest
-    // here is safe regardless.
+    // begin(Offscreen)Frame() blocks anyway waiting for its current frame
+    // slot's previous commands to complete so this here is safe regardless.
 
     executeDeferredReleases();
 
@@ -2044,17 +2044,17 @@ void QRhiVulkan::waitCommandCompletion(int frameSlot)
 QRhi::FrameOpResult QRhiVulkan::beginOffscreenFrame(QRhiCommandBuffer **cb, QRhi::BeginFrameFlags)
 {
     // Switch to the next slot manually. Swapchains do not know about this
-    // which is good. So for example a - unusual but possible - onscreen,
-    // onscreen, offscreen, onscreen, onscreen, onscreen sequence of
-    // begin/endFrame leads to 0, 1, 0, 0, 1, 0. This works because the
-    // offscreen frame is synchronous in the sense that we wait for execution
-    // to complete in endFrame, and so no resources used in that frame are busy
+    // which is good. So for example an onscreen, onscreen, offscreen,
+    // onscreen, onscreen, onscreen sequence of frames leads to 0, 1, 0, 0, 1,
+    // 0. (no strict alternation anymore) But this is not different from what
+    // happens when multiple swapchains are involved. Offscreen frames are
+    // synchronous anyway in the sense that they wait for execution to complete
+    // in endOffscreenFrame, so no resources used in that frame are busy
     // anymore in the next frame.
+
     currentFrameSlot = (currentFrameSlot + 1) % QVK_FRAMES_IN_FLIGHT;
-    // except that this gets complicated with multiple swapchains so make sure
-    // any pending commands have finished for the frame slot we are going to use
-    if (swapchains.count() > 1)
-        waitCommandCompletion(currentFrameSlot);
+
+    waitCommandCompletion(currentFrameSlot);
 
     ensureCommandPoolForNewFrame();