From 711c55b63226c30532b39ec8d5191330512eb2e0 Mon Sep 17 00:00:00 2001 From: Laszlo Agocs Date: Mon, 1 Nov 2021 14:41:18 +0100 Subject: 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 --- src/gui/rhi/qrhivulkan.cpp | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) (limited to 'src/gui/rhi') 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(); -- cgit v1.2.3