diff options
author | Laszlo Agocs <laszlo.agocs@qt.io> | 2021-09-15 14:07:15 +0200 |
---|---|---|
committer | Laszlo Agocs <laszlo.agocs@qt.io> | 2021-09-22 20:39:52 +0200 |
commit | 5e3de6aa6083f0cf312e60dc4fc9a7d999bc6c90 (patch) | |
tree | e3d9d4038cd150ec5e5bb9b487cf6e86d3c440d1 /src/quick/scenegraph/qsgthreadedrenderloop.cpp | |
parent | 6f36faf96b488330f2388bdc8728d843f14c38f9 (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.cpp | 14 |
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; |