diff options
author | Laszlo Agocs <laszlo.agocs@qt.io> | 2020-05-25 18:31:39 +0200 |
---|---|---|
committer | Laszlo Agocs <laszlo.agocs@qt.io> | 2020-05-26 13:49:52 +0200 |
commit | fe42d2ea631b82974dbccbe65c6f039b837c9150 (patch) | |
tree | 0e4b7d94d169693acac72d7739744e304b0abd77 /src/qmlworkerscript | |
parent | 90e645c7ac1d754efa90fa7be6555baa33f545e6 (diff) |
Store DXBC instead of HLSL source in the qsb files
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>
Diffstat (limited to 'src/qmlworkerscript')
0 files changed, 0 insertions, 0 deletions