Dxvk: Suggestion: use winetricks insted of custom install script

[gasinvein]

Winetricks can handle many typical things by itself, like adding overrides, locating correct paths to system32 depending on wineprefix arch, etc.
Custom winetricks verb file would be pretty small and simple, like so:

w_metadata dxvk dlls \
    title="DXVK" \
    publisher="Philip Rebohle" \
    year="2018" \
    media="manual_download" \
    file1="dxgi.dll" \
    file2="d3d11.dll" \
    file3="d3d10.dll" \
    file4="d3d10_1.dll" \
    file5="d3d10core.dll" \
    installed_file1="$W_SYSTEM32_DLLS_WIN/dxgi.dll" \
    installed_file2="$W_SYSTEM32_DLLS_WIN/d3d11.dll" \
    installed_file3="$W_SYSTEM32_DLLS_WIN/d3d10.dll" \
    installed_file4="$W_SYSTEM32_DLLS_WIN/d3d10_1.dll" \
    installed_file5="$W_SYSTEM32_DLLS_WIN/d3d10core.dll" \
    homepage="https://github.com/doitsujin/dxvk"

load_dxvk()
{
    dxvk32_dir="/usr/lib/wine/dxvk"
    for f in "$file1" "$file2" "$file3" "$file4" "$file5"; do
        w_try ln -sf "$dxvk32_dir/$f" "$W_SYSTEM32_DLLS/$f"
    done

    if [ "$W_ARCH" = "win64" ]; then
        dxvk64_dir="/usr/lib64/wine/dxvk"
        for f in "$file1" "$file2" "$file3" "$file4" "$file5"; do
            w_try ln -sf "$dxvk64_dir/$f" "$W_SYSTEM64_DLLS/$f"
        done
    fi

    w_override_dlls native \
        dxgi \
        d3d11 \
        d3d10 \
        d3d10_1 \
        d3d10core
}

[doitsujin]

Could this be used by just executing winetricks setup_dxvk.verb?

In some ways this looks a lot cleaner than the current install script, so I wouldn't mind setting up a verb.

[gasinvein]

Yes.
Only obstacle is location of DXVK dlls. If they are installed in well-known location, this is not a problem.
Also, DXVK binaries could be downloaded, istead of using locally-installed ones.

[doitsujin]

We cannot require the user to install it to a specific location, but that shouldn't really be a big deal because the install path is known at build time.

I think it is also reasonable to break the current way of installing it and make users build it with the package-release script instead, which could then generate one setup file instead of two.

Is there a documentation for how exactly winetricks files work?

[gasinvein]

Also, two separate verbs (for 32 and 64 bit) could be used , each one grabbing dlls from it's directory (like setup_dxvk.sh currently doing).

Is there a documentation for how exactly winetricks files work?

I didn't find one, just examined winetricks script itself.

[doitsujin]

Also, two separate verbs (for 32 and 64 bit) could be used

That's actually something I would like to avoid since it makes the setup clumsy, and people often forget to set up the 32-bit files and complain that 32-bit apps don't work (#556).

Anyway, I'll play around with this a little, thanks for the suggestion!

[gasinvein]

Can meson set locations for both 32 and 64 bit dlls (in winetricks verb) at build time?

[Thaodan]

Whats the issue with packaging the dlls? Its not wrong to package dxvk and very easy once set up.

[Thaodan]

Just depend on 32bit on x86_64 if multiarch is enabled.

[doitsujin]

@gasinvein No, since these are separate builds.

Actually we don't even need to bake the locations into the verb, assuming that it also works with relative paths. We'd just have to make sure that the file structure is sane, something like this:

dxvk-0.70
\ dxvk.64
  \ d3d11.dll
  \ dxgi.dll
\ dxvk.32
  \ d3d11.dll
  \ dxgi.dll
\ setup-dxvk.verb

@Thaodan What do you mean? We're just discussing a way to make the setup a bit less annoying.

[Thaodan]

does meson support ifdefs?

something like #ifdef MULTIARCH
bla

end

[gasinvein]

@Thaodan packaging dlls is not a problem (I actually do it for myself), problem is that it is not enough: built dlls must be installed in given wine prefix in order to actually use them.

[Thaodan]

@Thaodan What do you mean? We're just discussing a way to make the setup a bit less annoying.

I meant that:

Also, DXVK binaries could be downloaded, istead of using locally-installed ones.

I think the setup_x86_64 script just needs an ifdef at compile time to make install 32bit if multiarch is enabled.
something like that:
https://github.com/Thaodan/usenew/blob/master/src/usenew.in.sh#L52

[doitsujin]

How does that relate to this discussion? I don't understand what you are trying to suggest and which problem you are actually trying to solve.

[Thaodan]

To require the 64bit setup script/verb to install the 32bit verb/script when multiarch is enabled.
Also the make the 32bit version at least an optdep of the 64bit version.

[gasinvein]

@doitsujin

Actually we don't even need to bake the locations into the verb, assuming that it also works with relative paths.

I guess it does, since verbs are just bash scripts with some helper vars and functions pre-defined.

[doitsujin]

@gasinvein How exactly do I have to invoke winetricks to make it use the custom verb? Just doing winetricks /path/to/file does not work, it just complains about the argument being invalid, but the usage instructions suggest exactly that.

[gasinvein]

@doitsujin file must be named exactly as name_of_the_verb.verb, e.g. dxvk.verb in our case.
Also, I figured out that full path to the verb file can be accessed as ${BASH_SOURCE[0]}, not sure if it is reliable, but works.

[d4rkf4b]

It already exist but bad version

[gasinvein]

@d4rkf4b interesting, I use packaged version of winetricks, which doesn't include dxvk
Anyway, I think this issue is still actual, as DXVK is updated way more frequent than winetrics.

[doitsujin]

winetricks has a dxvk verb, but it doesn't really help with setting up your own builds. I still like this approach to cleaning up the setup process.

[bobwya]

@d4rkf4b

It already exist but bad version

I've no idea what you mean by this??!!

The current release of winetricks (20180815) has all dxvk releases from 0.54 to 0.65 (I haven't tracked the legacy branch)... The dll files are stored per Wineprefix. I see little point symlinking small binary files like that. No doubt to some random place on your system - this is really fragile. It's bound to cause issues, when you have a lot of Wineprefix's.

With a selection of winetricks dxvk verbs you can automate updating as many Wineprefiix locations as you want, with ease. While leaving others at older release versions.

_KISS_

[gasinvein]

@bobwya this is still not suitable for local/packaged builds, and, I guess, also not suitable for winelib builds of dxvk, as it depends on libwine and probably would (#520) depend on native libvulkan.

To be clear: I suggested winetricks verb as a replacement for custom installer script and didn't mean "provide a winetricks package for one-click installation".

[pchome]

As an hack : packaging local builds and placing them in winetricks cache ($XDG_CACHE_HOME/winetricks/dxvk-git) directory by build script.

[doitsujin]

The new 0.70 release now ships with the verb. The script is still a thing if you build from source manually, and I'll have to work out a way to not mess up the development workflow too much.

[kmaterka]

When moving from setup script to winetricks verb one needs to remember to manually remove old dll overrides. Setup script creates dll overrides without asterisk, winetricks with, e.g. *dxgi.
After running:

./x32/setup_dxvk.sh reset -y
./x64/setup_dxvk.sh reset -y

there are overrides for both "dxgi" and "d3d11" set to "builtin". winetricks will not overwrite it as it creates dll overrides for "dxgi" and "d3d11".

Read me says:

When using an older version of DXVK, it may be necessary to uninstall it first using setup_dxvk.sh reset.

Which may be misleading. It took me 1 hour to realize what is wrong, but I'm not especially smart on Mondays :)

Adiitionally, in the verb file in line 32, there is a statement that does nothing:
dxvk64_dir="/usr/lib64/wine/dxvk"

[pchome]

Noticed another bug while using winetricks verb:
cp command can rewrite symlink source, if destination ($W_SYSTEM32_DLLS/$f) already exist as a symlink.

e.g.

• previously I used symlinks manually set from /path/to/dxvk/dxvk-[version]/x32/... to /path/to/wineprefix/...
• different WINE prefixes has different versions due to usage/update time
• I started to install DXVK systemwide and test setup script/verb on several prefixes
• and now my /path/to/dxvk/dxvk-[version]/... path full of the same version dlls from system path

fixed using cp --remove-destination ... in verb variant I'm currently testing.

_Initial ln -sf ... command (from first comment) shouldn't have such issues._

[gasinvein]

I think dlls should be symlinked, not copied.
As this verb is used for local builds, dlls are already present somwhere on users's PC. After rebuilding/updateing DXVK, one would want to use that DXVK in their prefixes. In such case, copying dlls just adds unnecessary step.

[pchome]

Disadvantage is that dll directory can be removed.
But symlinks really helpful with git builds, where you should update files every time you rebuild DXVK.

Maybe I'll pick middle solution -- cp for tagged versions and ln for git version -- for myself.

[tingvarsson]

An advantage for having them symlinked is for all packages that install the dlls in a system location, and update them in that specific location.
E.g. aur package dxvk-bin