Package Details: dxvk-bin 1.10.1-1

Git Clone URL: (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:
Keywords: dxvk
Licenses: zlib/libpng
Conflicts: d9vk, dxvk
Provides: d9vk, dxvk
Submitter: ssorgatem
Maintainer: ssorgatem (kekonn)
Last Packager: ssorgatem
Votes: 196
Popularity: 3.19
First Submitted: 2018-03-02 07:39 (UTC)
Last Updated: 2022-03-26 18:44 (UTC)

Dependencies (2)

Required by (0)

Sources (1)

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

MarsSeed commented on 2022-01-26 23:06 (UTC)

Thanks for making the suggested changes! You've made my life easier! :)

MarsSeed commented on 2022-01-24 18:33 (UTC) (edited on 2022-01-24 18:36 (UTC) by MarsSeed)

+1: The 32-bit Vulkan library (lib32-vulkan-icd-loader) would better be only an optional dependency, similarly as for vkd3d-proton-bin.

Wine has a very reliable WOW64 runtime now, I am able to run 32-bit games in 64-bit wineprefixes. So I am trying to eliminate unneeded 32-bit Linux libraries and see how far can I go with such a setup. :)

MarsSeed commented on 2022-01-24 18:23 (UTC)

Hi! Thanks for the update!

Please consider my observation. This package should not mandatorily depend on Wine installed in the system. I am using it with Lutris, which is able to provide its own separate Wine runtimes. This dxvk-bin package works just fine when symlinked to the relevant Lutris runtimes directory.

(Lutris is also able to provide versions of dxvk, but I prefer setting it up with this dxvk-bin package since Lutris defaults to non-stable dxvk, and does not automatically update its managed wine prefixes with the latest dxvk.)

AvinashReddy3108 commented on 2021-09-25 12:09 (UTC) (edited on 2021-09-25 12:10 (UTC) by AvinashReddy3108)

Hey @ssorgatem.

  • Yes, the versions of DXVK I'm installing is same (via winetricks and the one from GitHub releases, and by extension this AUR package)

  • When testing both cases, the wineprefix is generated from scratch. (So I guess the prefixes are as identical as they can get)

  • The dxgi thing, how do I check that?

  • I think that winetricks verb installs d3d9 too (maybe d3d10 too, I'm not very sure of it.. tried to read the code on GitHub but it's not very clean)

ssorgatem commented on 2021-09-25 08:56 (UTC)

Are you installing the same version of DXVK with winetricks? Is it using wine's or DXVK's dxgi.dll? are you installing D3D10 and D3D9 too with the script?

Using the same options, both wine prefixes should be identical.

If anything you should report this upstream.

AvinashReddy3108 commented on 2021-09-25 07:13 (UTC) (edited on 2021-09-25 07:16 (UTC) by AvinashReddy3108)

For some reason, the winetricks "verb" for dxvk gives better results for me than this setup_dxvk script.

Game: Need for Speed ProStreet

Screenshots (intro screen aka "Click to continue" screen):

I used winetricks to install dxvk in the first screenshot, and used the setup_dxvk script to install dxvk for the second screenshot. The winetricks version works flawlessly, but the one with the setup_dxvk script is messed up with many textures not loading at all (and hence making the game unplayable)

tb0n3 commented on 2020-12-20 03:58 (UTC)

It works with wine-staging, so I went with that.

ssorgatem commented on 2020-12-07 10:04 (UTC)

Huh, weird. What is your wine version? Maybe there's been some change in how that package manages it...

tb0n3 commented on 2020-12-07 05:48 (UTC)

I'm unsure why, but despite having wine-staging-git in the dependencies it will not update with yay or makepkg because it claims wine conflicts. I do not have the wine package installed. Only wine-staging-git. I'm not sure what the fix is.

ssorgatem commented on 2020-07-05 09:12 (UTC)

Yes, but do look at the other options of the setup_dxvk script too, depending on what excatly do you want ;)

darkside commented on 2020-07-05 08:21 (UTC) (edited on 2020-07-05 08:22 (UTC) by darkside)

@ssorgatem Thank you very much!

Just to be sure, If I want to install it in custom wine prefix with symlink WINEPREFIX=~/wine/affinity setup_dxvk install --symlink Is the right way?

ssorgatem commented on 2020-07-05 08:14 (UTC)


It depends.

When you install dxvk through winetricks, winetricks copies the specified version of the DXVK dlls to that wineprefix. It won't get updated unless you manually update it.

With this package, you can install DXVK in a wineprefix with the --symlink option, which rather than copying the DXVK dlls into the wineprefix, symlinks them. So each time this package is updated, the DXVK dlls in each linked wineprefix are automatically updated too.

darkside commented on 2020-07-05 08:07 (UTC)

It is possible to install dxvk inside winetricks (installation of DLLs section). Is this something different?

loathingkernel commented on 2020-05-19 21:46 (UTC) (edited on 2020-05-19 21:47 (UTC) by loathingkernel)


To add to what others said, Proton's version of DXVK is different from upstream DXVK as it includes an extra component to enable the co-existence of DXVK with VKD3D under the same wine. It is required to pass configuration options to DXVK when wine's DXGI (required by VKD3D) is in use. GE's proton distribution also patches DXVK for the same effect.

Also, installing to arbitrary directories in the user's home folder is not something the package manager should do. It is up the userspace applications to do that.

ssorgatem commented on 2020-05-19 16:23 (UTC)

@shoober420: Installing in by default Proton directories seems like bad idea; they already include a version of DXVK. Like @kerkonn says, a separate package that woudl replace Proton's DXVK with another DXVK may be the way to go.

Wine is a dependency because you need wine to use it, and a minimum version too. The setup script won't work without wine, so you need wine even to install it into a Proton wineprefix.

kekonn commented on 2020-05-19 16:02 (UTC)


We don't want to do this by default. People might have their proton set up just the way they want to. Doing that would ideally be a package on it's own that depends on a dxvk package.

GE's Proton definitely includes DXVK, vanilla proton might do so as well, but I'm not sure.

I'll leave moving stuff to optdepends for @ssorgatem because I'm not sure if there are maybe reasons they are where they are.

shoober420 commented on 2020-05-19 14:34 (UTC) (edited on 2020-05-19 14:54 (UTC) by shoober420)

Would it be possible to have this package install dxvk in Proton directories? These specific directories especially.

Proton: ~/.steam/steam/steamapps/common/Proton X.X/dist/lib/wine/dxvk ~/.steam/steam/steamapps/common/Proton X.X/dist/lib64/wine/dxvk

Proton-GE: ~/usr/share/steam/compatibilitytools.d/proton-ge-custom/dist/lib/wine/dxvk ~/usr/share/steam/compatibilitytools.d/proton-ge-custom/dist/lib64/wine/dxvk

Could you also please add “wine” and “proton” as optional dependencies please? I do not have wine installed and it pulls almost 40 dependencies every time I try to install dxvk.

wioo commented on 2020-01-16 22:02 (UTC)

@ssorgatem, thanks.

ssorgatem commented on 2020-01-16 21:48 (UTC)

@wioo ah, it turns out that unintuitively "depends" are installed for the build process if declared outsed the package function. I thought that's what "makedepends" was for, but...

I think that should be fixed now.

wioo commented on 2020-01-16 18:10 (UTC) (edited on 2020-01-16 21:15 (UTC) by wioo)

Everytime you build this package in clean chroot, wine and its dependencies are installed for no reason. Do wine really needs to be among dependencies? This is just a "library" for wine (optional).

yochananmarqos commented on 2020-01-14 20:25 (UTC) (edited on 2020-01-14 20:25 (UTC) by yochananmarqos)

@ssorgatem: No need for mkdir at all since install -D SOURCE -t DEST creates all the components of the target directory. ;)

ssorgatem commented on 2020-01-14 18:36 (UTC)

@yochananmarqos thank you for your insight, I've updated the PKGBUILD taking that into account.

yochananmarqos commented on 2020-01-12 17:37 (UTC)

A few things:

  • The arch() array is in the PKGBUILD twice with different values.
  • This isn't a split package, no need for pkgbase or specifying the package name in the package() function.
  • provides() and conflicts() should be the same. Those git packages no longer exist.
  • The tarball is extracted in the package() function, no reason to extract it twice. Use a noextract() array.
  • Use install -d, not mkdir -p. No need to use chmod as install -d by default uses 755 permissions.

nixit commented on 2020-01-11 23:23 (UTC)


thanx, just switched to dxvk and wow... more FPS. :)

slobeck commented on 2020-01-10 22:41 (UTC)

Yes, D9VK has been folded into DXVK and is included in this package

nixit commented on 2020-01-10 20:48 (UTC) (edited on 2020-01-10 20:48 (UTC) by nixit)

I noticed d9vk is no longer in AUR, , which is what I Have installed to enhance guild wars 2.

does this take the place of d9vk

slobeck commented on 2020-01-10 18:55 (UTC) (edited on 2020-01-10 22:44 (UTC) by slobeck)

version 1.5.1-1 has been released edit the following lines in the PKGBUILD with pkgver=1.5.1 pkgrel=1 sha256sums=('474ce9995edd47a3bd347a8f3263f35cf8df2676f5b16668bf38efa298d75c01') the new version will download and install as normal.

kekonn commented on 2019-12-13 18:12 (UTC)

I see what I can do, as I am currently without an Arch environment and will have to do it from Windows.

fushinari commented on 2019-12-09 04:16 (UTC)

Can u up the pkgver? There's a newer version out

kode54 commented on 2019-10-27 22:57 (UTC)

No, it appears that pacman 5.2 now requires all makepkg users to declare that variable in their makepkg.conf if they're creating packages.

ssorgatem commented on 2019-10-27 13:03 (UTC)

Yeah, I don't know why does that warning pop up, as far as I can tell the maintainernline does follow that format

Smoerrebroed commented on 2019-10-27 11:55 (UTC) (edited on 2019-10-27 11:55 (UTC) by Smoerrebroed)

==> WARNING: PACKAGER should have the format 'Example Name email@address.invalid'

kek-mex commented on 2019-10-24 10:00 (UTC)

Version 1.4.3 has been released. Is this package going to be updated soon?

Mimicking commented on 2019-09-25 18:57 (UTC)


kekonn commented on 2019-09-25 16:43 (UTC) (edited on 2019-10-01 10:02 (UTC) by kekonn)

I think I fixed it. Can someone give it a try?

kekonn commented on 2019-09-25 14:14 (UTC)

Have you looked at Xabre's suggestion? That looks okay for me.

sokoban commented on 2019-09-25 12:17 (UTC)

Package keeps trying to upgrade, even though it's already current. How to fix this?

kekonn commented on 2019-09-24 20:39 (UTC)

@ssorgatem: my bad. That's my doing. I was in a rush early morning. I'll sleep on it the next time ;)

Xabre commented on 2019-09-24 09:27 (UTC) > solved versioning issues for me

zfkerr commented on 2019-09-24 05:56 (UTC)

Something's wrong with the versioning, yay keeps trying to update it but it's just reinstalling the same update over and over.

Xarius commented on 2019-09-23 17:31 (UTC)

Package keeps trying to upgrade, even though it's already current.

gamezelda commented on 2019-09-22 15:33 (UTC)

That .SRCINFO thing also causes yay (a AUR helper) to always detect this package as an upgrade, even though the latest version is already installed.

ssorgatem commented on 2019-09-22 08:16 (UTC)

That's weird, I sure haven't touched .SRCINFO at ll after generating with makepkg --printsrcinfo

kode54 commented on 2019-09-22 06:32 (UTC)

.SRCINFO also appears to have been hand edited rather than auto generated, it says the package version is 1.4.0, while the PKGBUILD says it's 1.4.

Xorg commented on 2019-09-20 05:15 (UTC)

@ssorgatem: pkgrel should be 1, not 0.

Xorg commented on 2019-09-14 08:13 (UTC)

Updated PKGBUILD for v1.3.4:

ssorgatem commented on 2019-06-17 20:56 (UTC)

@alexzk it behaves like upstream, which is, by default, it copies the DXVK libraries to your prefix, which means they are not automatically updated when you update the package.

If you want that, use the "--symlink" argument.

Namarrgon commented on 2019-06-15 16:58 (UTC)

$pkgdir needs to be quoted properly or the build will fail in directories that contain whitespace.

alexzk commented on 2019-06-10 21:45 (UTC)

Can you elaborate in pinned comment, if I must repeat 'setup_dxvk install' after package upgrade for each wineprefix i have, or it implies automatically. Because early 0.xx versions were doing copies of itself = need repeat.

grawity commented on 2019-05-25 21:31 (UTC)

The conflict with dxvk-bin<1.0-1 is redundant, as a package already cannot be co-installed with itself... however, it does cause trouble for AUR helpers which don't support versioned deps. It should probably be removed.

ssorgatem commented on 2019-04-16 14:33 (UTC)

No, putting $pkgdir there will break the link when installed.

That whole chmod line needs to be removed. It should be fixed now.

JIgnacioTG commented on 2019-04-16 06:57 (UTC)

I resolved the "chmod: cannot operate on dangling symlink 'setup_dxvk'" bug editing too the PKGBUILD file but adding the variable $pkgdir in the line of the symbolic link:

ln -s $pkgdir/usr/share/dxvk/ "$pkgdir/usr/bin/setup_dxvk"

I don't know if this breaks something.

mallgrab commented on 2019-04-15 23:49 (UTC) (edited on 2019-04-15 23:50 (UTC) by mallgrab)

It cries about "chmod: cannot operate on dangling symlink 'setup_dxvk'"
Editing the PKGBUILD and adding "cd $pkgdir/usr/bin"
below "mkdir -p $pkgdir/usr/bin"
fixed the problem for me.

ssorgatem commented on 2019-04-07 16:01 (UTC)

The 1.1 release has been pulled out because it was buggy (reportedly caused GPU hangs), so this package hasn't included it.

Nocifer commented on 2019-03-03 13:04 (UTC)

Hi, is there a reason that this package installs dxvk with the new --without-dxgi flag enabled by default? Or rather, I do understand the reason somewhat (probably so it can work out of the box without breaking synergy with vkd3d, dxup et al) but it's actually not really recommended by the developer because it breaks (or at least underperforms in) many games, especially when one's using an nvidia card. And even worse is that I can't see any way of installing WITH dxgi without modifying the provided script and removing the flag.

I think it'd be preferable if users could choose to install with or without dxgi themselves; maybe by creating a flag in your own script (e.g. --dxgi) which if present would serve to disable the --without-dxgi flag of the upstream script, which could then remain the default as it is now.

damachine commented on 2019-02-26 17:12 (UTC)

@ssorgatem Thanks for your help. have the old setup methode use for now.

ssorgatem commented on 2019-02-26 16:16 (UTC)

then the setup script should work when using the non-proton wine, and then you can go back to using proton's wine

damachine commented on 2019-02-26 16:12 (UTC)

"WINEPREFIX="/EXTRA/.steam/steamapps/compatdata/271590/pfx" wine winepath -u 'C:\windows\system32'"



ssorgatem commented on 2019-02-26 16:10 (UTC)

@damachine have you tried using it with non-proton wine on a proton prefix?

The older scripts had many limitations which this script solves (like being able to uninstall, for example). It also relied on winetricks and a winetrick verb... which I'm not too fond on mantaining.

But you are free to use an older version of this package, but replacing the DXVK files...

You can also just manually set it up; it's just symlinking or copying a couple files.

In any case, Proton should include this version of DXVK in a short time.

And last time I tried, whenever I started a game with Proton, it overwrote the manually installed DXVK with its own... so little point with the setup script supporting that.

damachine commented on 2019-02-26 16:00 (UTC)

@ssorgatem Is it possible to use the old setup script as a lagacy setup methode like that works for proton use. sorry that i repeat when it works before so fine.

ssorgatem commented on 2019-02-26 15:46 (UTC)

@damachine the setup script won't work with proton's wine, because proton's wine is missing some parts in which it relies.

Try using your system's wine, it should work that way.

Yes, the old method worked 2 days ago.... but now there's a new setup script, which requires wine to work (actual wine, not just the part of wine that proton has).

damachine commented on 2019-02-26 15:42 (UTC)

@ssorgatem i use steam beta with proton last beta of proton is installed i think its a wine 3.16 i see with protontricks under winecfg. local i have installed wine-staging 4.2-1 from arch repo with some prefix with dxvk. the old install methode works 2 days before from the dxvk-master git clone.

ssorgatem commented on 2019-02-26 15:31 (UTC)

@damachine that means either your WINEPREFIX or your wine installation are missing parts of wine, that is, winemenubuilder.exe

What wine are you using? I don't think it's going to work with the one from Proton.

damachine commented on 2019-02-26 15:20 (UTC)

@ssorgatem the command brings me "wine: cannot find L"C:\windows\system32\winemenubuilder.exe" wine: configuration in '/EXTRA/.steam/steamapps/compatdata/271590/pfx' has been updated. /EXTRA/.steam/steamapps/compatdata/271590/pfx/dosdevices/c:/windows/syswow64" i have test it with a non steam prefix i become the same. thanks for your work

ssorgatem commented on 2019-02-26 15:07 (UTC)

@damachine with that same prefix set, what is the output of wine winepath -u 'C:\windows\system32' ?

That's how the script determines the prefix' location. If it doesn't work for Proton prefixes (like yours), then that is a bug that should be filed upstream.

I'm just packaging the setup script unmodified, just wrapping it with the arguments so that it behaves the most compatibly like the previous scripts.

damachine commented on 2019-02-26 14:44 (UTC)

WINEPREFIX="/EXTRA/.steam/steamapps/compatdata/271590/pfx" ./ install brings me "Failed to resolve C:\windows\system32." also with other prefixes. have export the prefix and then "./ install" but the same failed as above Any help. The old setup methode had work fine before.

ssorgatem commented on 2019-02-26 12:20 (UTC)

@kode54 it should be fixed now

kode54 commented on 2018-12-30 02:06 (UTC)

Minor issue with these packages: It stages the .dll files as belonging to the user that built the package, rather than belonging to root.

ssorgatem commented on 2018-10-13 07:28 (UTC)

@BrianAllred it should be fixed now

BrianAllred commented on 2018-10-12 22:20 (UTC)

Is there anyway the script could have a proper shebang (#!/bin/sh) at the top? I use fish shell, and it can't execute the script (throws "Exec format error"), so I currently either have to run it in a bash shell, wrap it in a bash one-liner, or put the shebang in there myself.

Not a big deal, but would be nice to have. Thanks for maintaining this!

ssorgatem commented on 2018-09-30 00:22 (UTC)

It actually was updated, but it looks like it has changed again without notice or version change (it's no the first time it happens...)

linuxuser437442 commented on 2018-09-29 23:41 (UTC) (edited on 2018-09-30 02:35 (UTC) by linuxuser437442)

sha256sum in the makepkg for the dxvk-0.80.tar.gz seems to have not been updated from the last tar.gz file:

sha256sums=("f9e736cdbf1e83e45ca748652a94a3a189fc5accde1eac549b2ba5af8f7acacb" "1a88e01e02ef9bfd9bf43d8dec4e70b425fb25812f597463ee4145705c82a504")

7058a834bb006cad5462933110449b434df561e67d83f68d3965ecc74e2e1cbc dxvk-0.80.tar.gz

Thank you for the update!

ssorgatem commented on 2018-09-09 22:50 (UTC)

@sum01 mut be a problem on your end or a temporal githug issue, it works well for me.

sum01 commented on 2018-09-09 19:01 (UTC)

The upstream url is a dead link.

ssorgatem commented on 2018-08-28 04:34 (UTC)

@Greencopper, the "dxvk-bin" package contains nothing, it just depends on tje 32 and 64 bit packages.

greencopper commented on 2018-08-28 04:19 (UTC) (edited on 2018-08-28 04:31 (UTC) by greencopper)

sudo pacman -U dxvk-bin-0.70-2-x86_64.pkg.tar.xz 
loading packages...
resolving dependencies...
warning: cannot resolve "dxvk-win32-bin", a dependency of "dxvk-bin"
warning: cannot resolve "dxvk-win64-bin", a dependency of "dxvk-bin"
:: The following package cannot be upgraded due to unresolvable dependencies:

:: Do you want to skip the above package for this upgrade? [y/N]

zfkerr commented on 2018-08-17 15:36 (UTC) (edited on 2018-08-17 15:37 (UTC) by zfkerr)

Hi, @ssorgatem! DXVK 0.70 release brought the completely abolition of Philip "Doitsujin" Rebohle, the DXVK author thinks that it's you who should write a new such script, or take its script and add it to all your DXVK PKGBUILS's. Can we hope that you will do this? More details of this discussion can be found here:

Thank you! Regards!

TheRealSoup commented on 2018-08-17 14:18 (UTC)

In package_dxvk-win32-bin

Should it be replaces=("dxvk-bin") or replaces=("dxvk-bin<0.63-5")

ssorgatem commented on 2018-08-07 16:50 (UTC)

That's a good point, I updated to 32-bit package to depend on lib32-vulkan-icd-loader instead.

Before the split, the package consisted of 2 different builds of DXVK: a 32-bit build and a 64-bit build.

I think that alone justifies splitting it into 2 packages. Not everyone will need both DXVK builds.

It also allows to have one of them from this source package, and the other one from the dxvk-git package or even the winelib DXVK build, in which case the 32/64 bit split makes much more sense from the "host" point of view.

In the future, the ideal situation would be to use winelib builds instead of Windows DLLs for both 32 and 64 bit DXVK, but currently only 64-bit DXVK can be built as a wine library.

hybrid commented on 2018-08-06 21:37 (UTC) (edited on 2018-08-06 21:37 (UTC) by hybrid)

Thx for going the extra mile with a transition pkg. But I wonder why is this pkg split in the first place? I don't see any lib32 dependencies, it is more or less a blob. The 32bit/64bit is for the "guest system" wine, not for the "host" arch linux. This doesn't make any sense to me. What am I missing?

petercxy commented on 2018-08-06 09:16 (UTC) (edited on 2018-08-06 09:16 (UTC) by petercxy)

Shouldn't the win32 version also depend on lib32-vulkan-icd-loader?

ssorgatem commented on 2018-08-05 17:59 (UTC)

Yeah, I noticed just a few seconds too late. I'll fix it for the next release.

silly commented on 2018-08-05 17:48 (UTC)


just a small comment; you forgot to reset pkg rel when updated to 0.64 so now it is 0.64-5.

ssorgatem commented on 2018-07-22 07:24 (UTC)

Package updated. Maybe he could have released a 0.63.1 version instead of re-releasing 0.63.... with the same version number and same URL but different code.

Keridos commented on 2018-07-22 03:44 (UTC)

sha2sum not correct in build script anymore vor 0.63-1

bpierre commented on 2018-07-21 23:21 (UTC)

The URL for 0.63 is different because it should not be used:

Do not use

There is a critical regression which causes random crashes in some games after some time.

See: and

gyscos commented on 2018-07-21 23:09 (UTC)

Indeed, correct URL is

dogumon commented on 2018-07-21 22:50 (UTC) (edited on 2018-07-21 22:51 (UTC) by dogumon)


curl: (22) The requested URL returned error: 404 Not Found
==> ERROR: Failure while downloading

beefsack commented on 2018-06-28 00:45 (UTC)

@ssorgatem thanks!

ssorgatem commented on 2018-06-27 12:14 (UTC)

@beefsack that command is not good for generating the sum. Every time you run it it will have a different sha256sum.

You need to do it on the downloaded file.

If you do, you'll see it's the one I added yesterday to the PKGBUILD

beefsack commented on 2018-06-27 10:44 (UTC) (edited on 2018-06-27 10:45 (UTC) by beefsack)

The new sha256sum appears to be:

$ curl <> | sha256sum
4b3c66d3b40086653504b5a06a54cc992063c1aa7886327de84927b944c196f6  -

ssorgatem commented on 2018-06-26 11:47 (UTC)

uh... again?

Oh, it's probably related to the unity build thing.

tuxitop commented on 2018-06-26 11:43 (UTC)

Seems like the released package is changed upstream. Therefore the sha256sum needs to be updated.

ssorgatem commented on 2018-06-25 07:35 (UTC)

@DonHugo indeed. Thanks for spotting that! Fixed.

DonHugo commented on 2018-06-25 07:29 (UTC)


Shouldn't the setup part in the pinned comment be

For 32-bit D3D11: setup_dxvk32

For 64-bit D3D11: setup_dxvk64

and the reset argument only for uninstalling?

jcstryker commented on 2018-06-23 01:23 (UTC)

DXVK 0.60 currently requires the vulkan developer branch for NVIDIA cards:

I have submitted the 'nvidia-vulkan' package to the AUR, based off det's 'nvidia-full-beta', that will download and package the driver from this branch.

ssorgatem commented on 2018-06-22 19:41 (UTC)

Yes, that was the normal pattern, but the new release didn't follow it. So I changed the PKGBUILD for it.

Which worked well this morning.

But now the link is "fixed"... which breaks the PKGBUILD now... I'll update it now.

l33tlinuxh4x0r commented on 2018-06-22 19:30 (UTC)

The pkgbuild for version 0.60 doesn't have the right source file... It should be source=("$pkgver/dxvk-$pkgver.tar.gz") instead of source=("$pkgver/dxvk-v$pkgver.tar.gz")

Enverex commented on 2018-04-15 17:47 (UTC)

Nice one, well done peeps.

cogwerkz commented on 2018-04-13 13:19 (UTC) (edited on 2018-04-13 13:51 (UTC) by cogwerkz)

@Enverex @ssorgatem Mainainter of wine-staging-pba-git here, and I'm thinking the versioning problem @Enverex is having is in my PKGBUILD, not here and not in pacman.

I'll look into it and get it fixed! :)

Edit: The wine-staging-pga-git package shows the versions of the wine, wine-staging and wine-git replacements it provides now, so hopefully pacman shouldn't complain anymore. Sorry for the trouble it caused!

Edit2: Messed up my sed replacements on that first try, but now it properly extracts the various versions from the extensive versioning string. As of posting this the versions produced by the PKGBUILD are as below, and should function properly with pacman.

wine=3.5.r193.ga7b33a6a42 wine-git=3.5.r193.ga7b33a6a42 wine-pba=3.5.r33.8c72f84 wine-staging=3.5.r13.g3fe54232 wine-wow64=3.5.r193.ga7b33a6a42

ssorgatem commented on 2018-04-13 13:08 (UTC)

@Enverex That looks like a bug that should be reported to the pacman developers.

As for trying to work around it... isn't wine 3.6 scheduled for release later today? That should "fix" the issue...

Enverex commented on 2018-04-13 13:03 (UTC)

Pacman doesn't seem to be handling the dependency well for this:

:: dxvk-bin: installing wine-staging-pba-git (3.5.r13.g3fe54232+wine.3.5.r193.ga7b33a6a42+pba.3.5.r33.8c72f84-1) breaks dependency 'wine>=3.5'

3.5.r13.g3fe5423(blahblah) is obviously >= 3.5 but Pacman doesn't seem to agree. Do you think there's a way to gracefully handle this without removing the version requirement entirely?

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

ssorgatem commented on 2018-03-27 06:47 (UTC)

That error message means you haven't properly setup Vulkan in your wine prefix.

winicius commented on 2018-03-26 23:05 (UTC) (edited on 2018-03-27 02:24 (UTC) by winicius)

Getting the same error as @earthboundin for mortal kombat x on wine 3.4 after setting up dxvk for the prefix. Is there any way to remove dxvk from the prefix?

This is the error message I got:

0037:err:module:import_dll Library vulkan-1.dll (which is needed by L"C:\windows\system32\d3d11.dll") not found 0037:err:module:import_dll Library vulkan-1.dll (which is needed by L"C:\windows\system32\DXGI.DLL") not found 0037:err:module:import_dll Library DXGI.DLL (which is needed by L"C:\windows\system32\d3d11.dll") not found 0037:err:module:import_dll Library d3d11.dll (which is needed by L"Z:\home\winicius\.local\share\lutris\runners\winesteam\prefix\drive_c\Program Files\Steam\steamapps\common\MK10\Binaries\Retail\MK10.exe") not found 0037:err:module:import_dll Library vulkan-1.dll (which is needed by L"C:\windows\system32\dxgi.dll") not found 0037:err:module:import_dll Library dxgi.dll (which is needed by L"Z:\home\winicius\.local\share\lutris\runners\winesteam\prefix\drive_c\Program Files\Steam\steamapps\common\MK10\Binaries\Retail\MK10.exe") not found 0037:err:module:attach_dlls Importing dlls for L"Z:\home\winicius\.local\share\lutris\runners\winesteam\prefix\drive_c\Program Files\Steam\steamapps\common\MK10\Binaries\Retail\MK10.exe" failed, status c0000135

EDIT: sorry, had not configured wine vulkan

ssorgatem commented on 2018-03-20 17:40 (UTC)

Well, then it's a bug with the wine-vulkan-git PKGBUILD because it's not exposing the proper wine version.

DXVK required wine-vulkan before wine 3.4. As of 3.4, all the necessary patches are part of mainline wine, so any wine version based on 3.4 or above should work.

WhatTheBuck commented on 2018-03-20 17:36 (UTC)

@ssorgatem I rebuilt wine-vulkan-git right before trying to install this and it still didn't work. Isn't wine-vulkan required for this to work? Could it be because the package version of wine-vulkan-git doesn't appear as 3.4 when installed?

The "about" tab in winecfg lists the version as 3.4.

ssorgatem commented on 2018-03-20 17:33 (UTC)

@DrDoctor that means your version of wine-vulkan is below 3.4.

Either re-install wine-vulkan-git so that it gets the current code or install some other wine package that gives at least wine 3.4

WhatTheBuck commented on 2018-03-20 17:21 (UTC)

I can't install this without uninstalling wine-vulkan-git. It tries to install wine-staging instead.

ssorgatem commented on 2018-03-10 17:49 (UTC)

It looks like you don't have wine-vulkan properly setup

earthboundin commented on 2018-03-10 17:32 (UTC)

[ryan@Pepperanne Fallout 4]$ wine Fallout4.exe 000b:fixme:winediag:start_process Wine Staging 3.3 is a testing version containing experimental patches. 000b:fixme:winediag:start_process Please mention your exact version when filing bug reports on 002f:err:module:import_dll Library vulkan-1.dll (which is needed by L"C:\windows\system32\d3d11.dll") not found 002f:err:module:import_dll Library vulkan-1.dll (which is needed by L"C:\windows\system32\DXGI.DLL") not found 002f:err:module:import_dll Library DXGI.DLL (which is needed by L"C:\windows\system32\d3d11.dll") not found 002f:err:module:import_dll Library d3d11.dll (which is needed by L"J:\bigolboy\Games\Fallout 4\Fallout4.exe") not found 002f:err:module:import_dll Library vulkan-1.dll (which is needed by L"C:\windows\system32\dxgi.dll") not found 002f:err:module:import_dll Library dxgi.dll (which is needed by L"J:\bigolboy\Games\Fallout 4\Fallout4.exe") not found 002f:err:module:attach_dlls Importing dlls for L"J:\bigolboy\Games\Fallout 4\Fallout4.exe" failed, status c0000135 [ryan@Pepperanne Fallout 4]$

Getting this when I try to run Fallout 4. I ran the setup script, but to no avail.

ssorgatem commented on 2018-03-08 20:54 (UTC)

Thank you, I've updated the package.

frankyboy commented on 2018-03-08 18:59 (UTC)

version 0.31 is out

ssorgatem commented on 2018-03-02 17:34 (UTC)

It looks like it's due to the archive having been packaged by bsdtar or a very old version of GNU tar:

It shouldn't have any ill effect, though.

zfkerr commented on 2018-03-02 16:50 (UTC)

@ssorgatem, do you know what this means? This happens during the building.

Starting build()...

tar: Ignoring unknown extended header keyword 'SCHILY.fflags' dxvk-0.30/

tar: Ignoring unknown extended header keyword 'SCHILY.fflags' dxvk-0.30/x32/

tar: Ignoring unknown extended header keyword 'SCHILY.fflags' dxvk-0.30/x32/d3d11.dll

tar: Ignoring unknown extended header keyword 'SCHILY.fflags' dxvk-0.30/x32/

tar: Ignoring unknown extended header keyword 'SCHILY.fflags' dxvk-0.30/x32/dxgi.dll

tar: Ignoring unknown extended header keyword 'SCHILY.fflags' dxvk-0.30/x64/

tar: Ignoring unknown extended header keyword 'SCHILY.fflags' dxvk-0.30/x64/d3d11.dll

tar: Ignoring unknown extended header keyword 'SCHILY.fflags' dxvk-0.30/x64/

tar: Ignoring unknown extended header keyword 'SCHILY.fflags' dxvk-0.30/x64/dxgi.dll

tar: Ignoring unknown extended header keyword 'SCHILY.fflags' dxvk-0.30/README.txt

ssorgatem commented on 2018-03-02 16:42 (UTC)

Oh, thank you for spotting that! Should be fixed now.

zfkerr commented on 2018-03-02 16:30 (UTC)

@ssorgatem, a bug report here:

That is in your PKGBUILD:

cp -r "dxvk-$pkgver"/x64 $pkgdir/opt/dxvk

cp -r "dxvk-$pkgver"/x64 $pkgdir/opt/dxvk

And rightly so:

cp -r "dxvk-$pkgver"/x64 $pkgdir/opt/dxvk

cp -r "dxvk-$pkgver"/x32 $pkgdir/opt/dxvk