protonscr

No .so / .dll selection in setup_dxvk.sh?

dxvkclosed
doitsujin/dxvk#1048 · opened 2019-05-09 by shmerl · updated 2019-05-09 · 6 comments · github
1 matching comments, n / p to jump
Sshmerl 2019-05-09 github

I guess I missed this, since I was using an older script until now, but the new one has no way to control whether to use .so or .dll as a source. It just gives preference to .so by default and falls back to .dll if .so is not present. I remember there was winelib variable for that. Did you remove it for some reason?

Ddoitsujin maintainer 2019-05-09 github

What exactly is the issue here? setup_dxvk.sh just sets up whatever you built; if you have a winelib build then it's going to use .so, if you have a mingw build then it's going to use .dll.

Sshmerl 2019-05-09 github

I usually build both just in case, to be able to test if there is any performance difference. So it can be useful for the script to install either of them (in the past it was for sure able to). For now I just modify it manually if needed.

Something like this can work

if $dxvk_winelib; then
  # .so logic
else
  # dll logic
fi

Set dxkv_winelib=true or dxkv_winelib=false when running.

You can combine it with some detection of if only one is present and variable is unset, and then use that and use for example one by default if both are present and variable is not set.

Ddoitsujin maintainer 2019-05-09 github

You can do that by using separate build directories; that's the intended way to do something like this. Basically do

package-release.sh build.dll . --dev-build
package-release.sh build.so . --dev-build --winelib

and use the respective scripts in the resulting build.* directories.

Sshmerl 2019-05-09 github

I already build in separate directories (and anyway in VM), but I deploy all in one location for neatness. I.e. my dxvk installation looks like this:

./bin
./bin/setup_dxvk.sh
./lib32
./lib32/dxgi.dll
./lib32/d3d11.dll
./lib32/d3d10core.dll
./lib32/d3d10.dll
./lib32/d3d10_1.dll
./lib32/dxgi.dll.so
./lib32/d3d11.dll.so
./lib32/d3d10core.dll.so
./lib32/d3d10.dll.so
./lib32/d3d10_1.dll.so
./lib64
./lib64/dxgi.dll
./lib64/d3d11.dll
./lib64/d3d10core.dll
./lib64/d3d10.dll
./lib64/d3d10_1.dll
./lib64/dxgi.dll.so
./lib64/d3d11.dll.so
./lib64/d3d10core.dll.so
./lib64/d3d10.dll.so
./lib64/d3d10_1.dll.so
Ddoitsujin maintainer 2019-05-09 github

If you really need that sort of structure, you can still use your own scripts, I don't intend to support every "creative" use case that people might come up with. setup-dxvk.sh is just meant to be an easy-to-use tool for end users to set things up.

Sshmerl 2019-05-09 github

No problem. It was supported though in some way before, but it's not critical. Writing a custom script isn't hard.

DLLs