| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Also includes stripping the shaders properly. While we do not have debug
information, we do have OpName and similar that describe the variable and
block member names. This is unnecessary in the final SPIR-V binary, and further
reduces the size somewhat.
To create debuggable shaders (for SPIR-V and D3D) with full source information,
one needs to regenerate the relevant ones with -g instead of -O.
Change-Id: I3b855ee4e9afe393cd460407c1a807d6c9c5e6c2
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the -c argument when invoking qsb. The scripts are batch files
already so they imply being run on Windows. With a standard VS prompt
one gets fxc in the PATH too so we can let qsb invoke it.
The result is that the built-in materials' qsb files do not contain HLSL
source code anymore, rather they have the intermediate format with
bytecode (conceptually this is like SPIR-V). So at run time there are
no calls to d3dCompile() anymore when these shaders are involved.
What does this mean in practice? With a few select examples:
shapes, opening the Gallery view - before: 80 ms spent on HLSL source
compilation - after: 0 ms.
imageparticle, opening the first 3 views - before: 166 ms spent on HLSL
source compilation - after: 0 ms
shadereffects - before: 77 ms spent on HLSL source compilation - after:
29 ms (because this has custom shaders that still ship HLSL source)
Long term this can hopefully be folded into qsb's to-be-implemented build
system integration, so that it can automatically invoke the appropriate
shader compiler on Windows and macOS. But for now we just do it manually
and check in the regenerated .qsb files.
Fixes: QTBUG-84268
Change-Id: Ibe2f80f99b3e52d5eb5eb808ea103cc766d22c04
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
| |
|
|
|
| |
Change-Id: Ic1a1f5ff49c34d72495bc74083f37db118c935c1
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
The generated GLSL code for version 150 is now slightly different (we now
disable the unnecessary GL_ARB_shading_language_420pack to prevent
failures on older OpenGL implementations and core profile contexts).
Task-number: QTBUG-80690
Change-Id: I4c6242284c1239af9f12bd2fdac3c33707ac88e7
Reviewed-by: Johan Helsing <johan.helsing@qt.io>
|
|
|
Opt in via environment variables:
QSG_RHI=1 -> enable using QRhi instead of GL
QSG_RHI_BACKEND -> set to vulkan, metal, d3d11, gl to override the default
(the default is d3d11 on Windows, metal on Mac, gl elsewhere)
Or force a given rhi backend via the existing
QQuickWindow::setSceneGraphBackend().
Otherwise the default behavior is the same as before, the rhi code path
is never active by default.
-no-opengl builds are supported in the sense that they work and default
to the software backend. However, the rhi code path cannot currently be
used in such builds, even though QRhi from qtbase is fully functional
with Vulkan, D3D, or Metal even when qtbase was configured with
-no-opengl. This cannot be utilized by Quick atm due to OpenGL usage
being all over the place in the sources corresponding to the default
backend, and those host the rhi code path as well. This will be cleaned up
hopefully in Qt 6, with the removal all direct OpenGL usage.
Other env.vars.:
QSG_RHI_DEBUG_LAYER=1 -> enable D3D debug or Vulkan validation layer
(assuming the system is set up for this)
QSG_RHI_SHADEREFFECT_DEBUG=1 -> print stuff from ShaderEffect
QSG_SAMPLES=1,2,4,... -> MSAA sample count (but QSurfaceFormat works too)
QT_D3D_ADAPTER_INDEX=0,1,... -> D3D adapter index
QT_VK_PHYSICAL_DEVICE_INDEX=0,1,... -> Vulkan physical device index
QSG_RHI_UINT32_INDEX=1 -> always use uint index data (both
merged/unmerged, convert when needed - with some rhi backends this is
implicit)
QSG_RENDER_LOOP -> to override the render loop as usual. The default
with RHI is threaded for Metal, threaded for Vulkan on Windows, basic
for Vulkan on Linux and Android (to be checked later), while the existing
rules apply for OpenGL.
Not supported when running with QRhi:
- particles
- compressed atlases (though this is transparent to the apps)
- QSGRenderNode
- QQuickRenderControl
- QQuickFramebufferObject
- certain QQuickWindow functionality that depends directly on OpenGL
- anisotropic filtering for textures
- native text may lack some gamma correction
- QSGEngine applicability unclear
- some QML profiler logs may be incorrect or irrelevant
Change-Id: I7822e99ad79e342e4166275da6e9e66498d76521
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
