aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/scenegraph/qsgthreadedrenderloop.cpp
diff options
context:
space:
mode:
authorLaszlo Agocs <laszlo.agocs@qt.io>2021-09-15 14:07:15 +0200
committerLaszlo Agocs <laszlo.agocs@qt.io>2021-09-22 20:39:52 +0200
commit5e3de6aa6083f0cf312e60dc4fc9a7d999bc6c90 (patch)
treee3d9d4038cd150ec5e5bb9b487cf6e86d3c440d1 /src/quick/scenegraph/qsgthreadedrenderloop.cpp
parent6f36faf96b488330f2388bdc8728d843f14c38f9 (diff)
Get rid of renderpass descriptor objects from the pipeline cache keys
Follow what we did to the srb: instead of storing an object reference, store an opaque blob to test for compatibility. This works even if the object is destroyed in the meantime. Thus, the annoying and error-prone invalidatePipelineCacheDependency() goes away, finally. All this works because creating a QRhiGraphicsPipeline with a given QRhiRenderPassDescriptor only needs the renderpass object for building (as in create()). Afterwards the object can be destroyed, even. The pipeline is still usable with any render targets that have a _compatible_ rp descriptor. Therefore, it is ideal if there is a way to test for this compatibility without having to have the original object around for ever. Relies on enablers (most importantly, QRhiRenderPassDescriptor::serializedFormat()) added to QRhi in qtbase. While not necessarily obvious, the real benefit here is significant performance gains in certain situations: consider rendering a scene to a given render target, then to another one, then yet another one, for example via QQuickRenderControl. We no longer have to do aggressive purging of the pipelines just because a QRhiRenderPassDescriptor some of the recently created pipelines may be associated with is going to disappear. Rather, everything can stay as-is, there are no crashes due to dangling pointers in the pipeline cache keys. The majority of cases involve highly compatible render targets (e.g. rendering into textures of the same format), so reuse is highly beneficial. Pick-to: 6.2 Change-Id: I8ad4bfcb3c7e66c7364c91a749e2a2e6837b4f1a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Diffstat (limited to 'src/quick/scenegraph/qsgthreadedrenderloop.cpp')
-rw-r--r--src/quick/scenegraph/qsgthreadedrenderloop.cpp14
1 files changed, 0 insertions, 14 deletions
diff --git a/src/quick/scenegraph/qsgthreadedrenderloop.cpp b/src/quick/scenegraph/qsgthreadedrenderloop.cpp
index d7502054df..f6df6566aa 100644
--- a/src/quick/scenegraph/qsgthreadedrenderloop.cpp
+++ b/src/quick/scenegraph/qsgthreadedrenderloop.cpp
@@ -1197,20 +1197,6 @@ void QSGThreadedRenderLoop::windowDestroyed(QQuickWindow *window)
void QSGThreadedRenderLoop::releaseSwapchain(QQuickWindow *window)
{
QQuickWindowPrivate *wd = QQuickWindowPrivate::get(window);
-
- // Counterintuitive, because this is not needed under normal circumstances
- // due to the render loop using a dedicated rendercontext per thread, so
- // per window. Problem is, there are cases like calling destroy(); show();
- // on the QQuickWindow. (and we get here on SurfaceAboutToBeDestroyed, i.e.
- // from destroy())
- //
- // That means recreating the native window and all the related graphics
- // infrastructure, but the rendercontext stays around. So still have to
- // notify the renderer to invalidate the relevant objects in the caches.
- //
- if (wd->renderer)
- wd->renderer->invalidatePipelineCacheDependency(wd->rpDescForSwapchain);
-
delete wd->rpDescForSwapchain;
wd->rpDescForSwapchain = nullptr;
delete wd->swapchain;