protonscr

SPIRV-Tools linkage overhead

dxvkclosed enhancementbuild
doitsujin/dxvk#119 · opened 2018-03-02 by pchome · updated 2018-03-13 · 8 comments · github
2 matching comments, n / p to jump
Ppchome 2018-03-02 github

  1. Consider to move SpirvCodeBuffer::optimize() and SpirvCodeBuffer::validate() declarations either to dxgi or d3d11 modules. Since both dxgi and d3d11 depends on SpirvCodeBuffer you linked SPIRV-Tools objects into both dlls. This adds ~+2MB to both dlls while only d3d11 use this functionality.

    v21(pre  spirv-tools): d3d11.dll - 1.5MB, dxgi.dll - 1.3MB
v30(post spirv-tools): d3d11.dll - 3.6MB, dxgi.dll - 3.4MB

  2. FYI:

    • For only validate() functionality it's possible to link w/ only SPIRV-Tools-shared.dll. In case you'll decide to have an option.
    • It's possible (or even better) to link d3d11 with -ldxgi but not with dxgi_dep instead. At least on linux this removes dxgi.dll.so from "direct dependencies" (ldd) of d3d11.dll.so but keeps as "internal wine dependence" or so.
Ddoitsujin maintainer 2018-03-02 github

The optimizer will probably be removed again anyway because using it in practice is not a viable option. It slows down shader compilation by multiple orders of magnitude.

I'm aware that this isn't optimal, but 2MB is something I genuinely don't care about at the moment. The spirv tools were added mostly to help debug Nvidia issues, once those are fixed i might get back to this.

Ppchome 2018-03-02 github

It slows down shader compilation by multiple orders of magnitude.

To partially resolve this I changed code to work in pair with "shader read directory". So all once optimized shaders are stored there and are read from there as soon as requested again.
It's even gave some boost when loading games for the second time but still a bit stutters for new shaders.

https://github.com/pchome/dxvk/commit/a9d143cacd6b3cffd99896003da1073ca5321d00

Ppchome 2018-03-13 github

@doitsujin

The optimizer will probably be removed again anyway because using it in practice is not a viable option.

Yes, remove it. It was very useful before Nvidia-specific fixes lands in DXVK, but now it rather misleading people.

Also it's better remaining Nvidia compiler issues (if any) to be reported and/or described in wiki, but not silenced by the users.

p.s. Not related but can you please also remove remaining env::getEnvVar()s from d3d11_shader.cpp than? There is no need to request env variables every time but better to store them on "init level" somewhere. Something like cfg.env.shaderDumpPath.

?ghost 2018-03-13 github

@pchome well, at least now I get much less stuttering (when just starting to play some game) with SPIR-V because shader compilation seems to be slower with DXVK

Ppchome 2018-03-13 github

@Yardanico you can still get same result using DXVK_SHADER_DUMP_PATH than manually optimize shaders with spirv-opt command and place them into directory to be specified in DXVK_SHADER_READ_PATH

Ppchome 2018-03-13 github

@Yardanico commands was published several times in different issues, but here my script for dxvk_shader_dump and dxvk_shader_read directories from games root

#!/bin/sh

cd dxvk_shader_dump

for name in *.spv ; do
  [[ ! -f ../dxvk_shader_read/$name ]] && \
    spirv-opt \
        --legalize-hlsl \
         $name -o ../dxvk_shader_read/$name && echo $name
done

cd ..
Ppchome 2018-03-13 github

@Yardanico
AFAIK shaders are read from DXVK_SHADER_READ_PATH instead.

Or I misunderstand you.

well, at least now I get much less stuttering (when just starting to play some game) with SPIR-V because shader compilation seems to be slower with DXVK

If you get much less stuttering with built-in SPIRV-Tools than you can do the same manually. My answer was.

Ddoitsujin maintainer 2018-03-13 github

SPIR-V tools were removed entirely from DXVK in 25cae39cdbbe94e25b40a30e2a6f5dfe0aeac20a.

p.s. Not related but can you please also remove remaining env::getEnvVar()s from d3d11_shader.cpp than? There is no need to request env variables every time but better to store them on "init level" somewhere. Something like cfg.env.shaderDumpPath.

The whole configuration stuff needs some refactoring in general, I'm thinking of adding support for an (optional) configuration file to make testing these things on Windows a bit easier. Will be tackled sooner or later.

Launch options

DLLs