AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

rhi: vk: fix offscreen frame command completion wait

Browse Source 
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>
This commit is contained in:
Laszlo Agocs 2021-11-01 14:41:18 +01:00
parent ad2143b8d2
commit 711c55b632
1 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
src/gui/rhi/qrhivulkan.cpp
View File

@ -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();