aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/scenegraph/qsgthreadedrenderloop.cpp
diff options
context:
space:
mode:
authorLaszlo Agocs <laszlo.agocs@qt.io>2022-09-12 16:46:24 +0200
committerLaszlo Agocs <laszlo.agocs@qt.io>2022-09-16 09:19:49 +0200
commit0305c53943f4d0e05809afe96a547fc514427e97 (patch)
tree359f5294d848c3b95ef791295f801455b7b30a5f /src/quick/scenegraph/qsgthreadedrenderloop.cpp
parent10d42ecebc2d8861e795f070887a742f1f8476e0 (diff)
Make the pipeline cache real and move some settings to QGraphicsConfig
The settings that were previously only controllable via environment variables get now a counterpart in QQuickGraphicsConfiguration. The env.vars. stay since most of them are fully documented so must continue to function as before. Now they just have a way to enable the same from C++, on a per-QQuickWindow basis (if being per-QQuickWindow is applicable, that is) Most importantly, productize and document the pipeline cache save/load feature. This now has support both for specifying a custom filename for saving to or loading from, and in case nothing is set explicitly it has an automatic solution similar to the Qt 5 era GL program binary cache, under the standard CacheLocation of the system. And it works for all the graphics APIs, storing whatever the QRhi returns as the "pipeline cache" blob. With the default threaded loop the new cache control APIs are a grand improvement: instead of having only the global environment variables (QSG_RHI_PIPELINE_CACHE_SAVE/LOAD), one can now control per-QQuickWindow from C++ where the pipeline cache is stored. This allows sophisticated applications to support caching shaders/pipelines for multiple windows in a sane way (i.e. with different cache files, this way no conflicts and overwriting of each others caches happen). It also allows pre-seeding (deploying the cache file to another device, thus accelerating the very first run of the application already) in a simple way: run with saving the cache contents to whatever file is desired (even better, loading can still happen from the standard cache location, so it is not necessary to start revisiting all views and states to get pipelines/shaders compiled if the application was used before), then ship the file and load explicitly from that. (the usual caveats apply: the cache is ignored if the GPU or driver version do not match; the exception being data from D3D11 as that is freely reusable between PCs) It turns out that having a nice API design is not ideal for the 'basic' render loop, but there is nothing we can do about it. While we now have a way to control the pipeline cache storage per-QQuickWindow, it won't actually work on a per-window basis with the basic loop because that uses the same QRhi for all windows, and so the API structure falls apart: having per-window settings that affect the underlying QRhi is actually futile. (but given that QRhi is not public there is no other choice really and for 'threaded' we still want a proper per-window solution) This could be addressed in the future by converting the basic loop to also use dedicated QRhis for everything (which may involve some caveats). For now it is documented that the basic loop will only take one window's settings into account when it comes to the cache. Note that there is no support for QQuickWidget. As the architecture is totally different, with the QRhi infrastructure controlled by widgets and the backingstore, that is out of the scope of Qt Quick to solve. The biggest change is the automatic pipline cache which is on by default, as long as no explicit filenames are given (it can be disabled in some other ways as well (env.vars/app.attribute), but this should rarely be needed in practice) This is expected to give a boost to all applications on all platforms, although the gains will be small on systems where the drivers employ their own persistent caches (which is quite common these days, esp. on Windows and macOS). Nonetheless there will still be small improvements, with milliseconds shaved off of the total time spent on compute/graphics pipeline creation during the lifetime of a QQuickWindow. Big improvements are expected to be visible with D3D and Qt Quick 3D: the cache stores the DX bytecode (Quick 3D's run time material shader building causes HLSL code to be compiled at runtime) so apps using View3D are expected to benefit a lot from this. Task-number: QTBUG-103802 Task-number: QTBUG-106545 Change-Id: I01269424784b02114b88c4a712cf64512ff68ed7 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Diffstat (limited to 'src/quick/scenegraph/qsgthreadedrenderloop.cpp')
-rw-r--r--src/quick/scenegraph/qsgthreadedrenderloop.cpp7
1 files changed, 4 insertions, 3 deletions
diff --git a/src/quick/scenegraph/qsgthreadedrenderloop.cpp b/src/quick/scenegraph/qsgthreadedrenderloop.cpp
index c75d969186..e9ea6c9d3b 100644
--- a/src/quick/scenegraph/qsgthreadedrenderloop.cpp
+++ b/src/quick/scenegraph/qsgthreadedrenderloop.cpp
@@ -507,7 +507,7 @@ void QSGRenderThread::invalidateGraphics(QQuickWindow *window, bool inDestructor
}
}
if (ownRhi)
- QSGRhiSupport::instance()->destroyRhi(rhi);
+ QSGRhiSupport::instance()->destroyRhi(rhi, dd->graphicsConfig);
rhi = nullptr;
qCDebug(QSG_LOG_RENDERLOOP, QSG_RT_PAD, "- QRhi destroyed");
} else {
@@ -584,12 +584,13 @@ void QSGRenderThread::handleDeviceLoss()
return;
qWarning("Graphics device lost, cleaning up scenegraph and releasing RHI");
- QQuickWindowPrivate::get(window)->cleanupNodesOnShutdown();
+ QQuickWindowPrivate *wd = QQuickWindowPrivate::get(window);
+ wd->cleanupNodesOnShutdown();
sgrc->invalidate();
wm->releaseSwapchain(window);
rhiDeviceLost = true;
if (ownRhi)
- QSGRhiSupport::instance()->destroyRhi(rhi);
+ QSGRhiSupport::instance()->destroyRhi(rhi, {});
rhi = nullptr;
}