Package Details: dxvk-bin 2.6-1

Git Clone URL: https://aur.archlinux.org/dxvk-bin.git (read-only, click to copy)
Package Base: dxvk-bin
Description: A Vulkan-based compatibility layer for Direct3D 9/10/11 which allows running 3D applications on Linux using Wine (Windows DLL binary files)
Upstream URL: https://github.com/doitsujin/dxvk
Keywords: dxvk
Licenses: zlib/libpng
Conflicts: d9vk, dxvk
Provides: d9vk, dxvk
Submitter: ssorgatem
Maintainer: ssorgatem (kekonn)
Last Packager: ssorgatem
Votes: 229
Popularity: 1.48
First Submitted: 2018-03-02 07:39 (UTC)
Last Updated: 2025-03-14 09:25 (UTC)

Pinned Comments

ssorgatem commented on 2018-03-27 06:47 (UTC) (edited on 2019-02-26 12:20 (UTC) by ssorgatem)

To enable DXVK in a wineprefix, do the following (with the WINEPREFIX variable properly set):

setup_dxvk install

In order to uninstall DXVK from a wineprefix:

setup_dxvk uninstall

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 .. 16 Next › Last »

ssorgatem commented on 2023-01-26 08:53 (UTC)

@loathignkernel using the static link for the file before that commit or just a patch reverting that commit only allows us to use the script unmodified. The moment a change needs to be done to it (which will eventually come) we'd need to drop that and at the very least include the file itself as a source file. So between reverting the commit and providing our own file, only the latter is future-proof.

But it leads to code duplication between the several DXVK packages. If several packages share some files, I don't see how making a separate package of them to remove duplication is any "pollution". There's plenty of "-common" packages in the official repos and in the AUR that are exactly that.

loathingkernel commented on 2023-01-25 18:52 (UTC) (edited on 2023-01-25 18:53 (UTC) by loathingkernel)

@kekonn From the moment you are packaging a project in a way that upstream doesn't do it themselves, like here for example (you are putting it in a system-wide directory, upstream doesn't mention anything about packaging it this way) you already contradict your statement. As packagers we are obligated to an opinion on how we are going to package. Even in the official repos packages are patched beyond what upstream does, their build options change, the libraries they are linked to change. Putting it in a separate package is pollution.

kekonn commented on 2023-01-25 18:33 (UTC)

Personally I think opinions belong upstream and a package should be nothing more than an install/build script. So I am all for putting this in a separate package.

kIERO commented on 2023-01-25 15:23 (UTC)

Thanks for the fix!

loathingkernel commented on 2023-01-25 11:55 (UTC) (edited on 2023-01-25 11:57 (UTC) by loathingkernel)

@rfried

Unless someone re-writes the history of the repository and force-pushed to it, no the link won't ever change. The link is not for the commit's diff, it is for the repository as a whole at that point in history. (changed the link in the original comment so it can be used with wget or curl directly)

git revert reverts the commits referenced by the SHA it takes as an argument, those two commits only contain the changes that removed the script. Nothing else will be changed.

rfried commented on 2023-01-25 11:34 (UTC)

@ssorgatem) Thanks a lot

@loathingkernel) Does the github raw link points (only) to the commit 4f90d7bf5? So revert case maybe ok. But all updates later on, will be missed?

loathingkernel commented on 2023-01-25 09:15 (UTC) (edited on 2023-01-25 11:56 (UTC) by loathingkernel)

@ssorgatem

maybe it's worth exploring the option of making it into its own separate package,

This is an utterly nonsense solution, creating a separate package for a 200-line script. Source packages can git revert the two commits that removed it, and this package can directly download from the latest commit on github that included it by adding this link to the source array https://raw.githubusercontent.com/doitsujin/dxvk/4f90d7bf5f9ad785660507e0cb459a14dab5ac75/setup_dxvk.sh.

You are complicating things for no reason or tangible gain.

ssorgatem commented on 2023-01-25 09:13 (UTC)

@wioo you are right, forgot about the symlink. Should be fixed now.

wioo commented on 2023-01-25 09:10 (UTC)

Hi, ssorgatem. looks like "../" needs to be removed from "../setup_dxvk.sh".

ssorgatem commented on 2023-01-25 08:56 (UTC)

I made a quick fix by adding the missing script.

Since we'll have to maintain it now ourselves, maybe it's worth exploring the option of making it into its own separate package, so the other DXVK packages can depend on it rather than each packaging its own...