diff options
author | Laszlo Agocs <laszlo.agocs@qt.io> | 2022-09-12 16:46:24 +0200 |
---|---|---|
committer | Laszlo Agocs <laszlo.agocs@qt.io> | 2022-09-16 09:19:49 +0200 |
commit | 0305c53943f4d0e05809afe96a547fc514427e97 (patch) | |
tree | 359f5294d848c3b95ef791295f801455b7b30a5f /src/quick/scenegraph/qsgthreadedrenderloop.cpp | |
parent | 10d42ecebc2d8861e795f070887a742f1f8476e0 (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.cpp | 7 |
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; } |