World of Warcraft

I installed OpenSuse 15.2 and this came with Wine 5.0 by default. The game worked. Then I added the Wine repo as I always do, to get the latest. I received wine 5.13 and WoW stopped working. The funny part (I thought) was that I use Lutris and in Lutris I configured Wine version TKG-4.6 since this always performed best for me.

So when I read this post, I found it to be weird that I was experiencing the black screen when Wow.exe started.

I removed Wine 5.13 and installed Wine 5.0 that came with the OS and Wow.exe worked again. When doing so, a lot of libs where downgraded.

So I think that TKG-4.6 or any other Wine version you use, uses the same libraries. So is the problem in Wine 5.10 and up or is it in the libraries?

Then I upgraded Wine 5.0 to 5.13 and none of the libs that got downgraded where upgraded during the installation of Wine 5.13, and the game still worked while running it with TKG 4.6 but with Wine 5.13 it crashed again. Then I again tried TKG 4.6 and it stopped working again.

So, I figure that other Wine variants are still depending on the installed systems Wine. I hope this is helpfull in any way.

You actually need to run the game with the working system Wine (either Wine 5.0 or Wine-Staging 5.13) before I can run it again with TKG 4.6

- What is the difference between Wine and Wine-Staging?
- Can someone explain why a custom Wine version, like TKG doesn't work when the wrong Wine version is uninstalled? Is Wine writing down some global settings that make TKG also fail?

wine - basic microsoft functionality, focus on office work.

wine-staging - custom patches, that are applied, to allow games to work, with maximum throughput at or above what windows can provide. Maintained by a separate group and applied to the main wine source, before being compiled.The staging patches, also help with games that use copy protection, and that is why so many custom patches are created.

Not familiar with TKG. Is that like Play on Linux or Lutris, and used to run specialized versions of wine for game play?

It is a Wine version that used to come with Lutris (they have their own now) and that has all sorts of patches for gaming.
github.com/Tk-Glitch/PKGBUILDS/tree/master/wine-tkg-git

I used to use this one, but now on OpenSuse15.2 the performance of the Proton 5.0.9 build with World of Warcraft is just amazing. So I don't use TKG anymore atm.

It is somewhat confusing with all these versions. Here is what i have gathered so far.

Wine: "default" from upstream WineHQ source. Currently at 5.13
Wine-staging: Wine + various patches that have yet to find its way upstream. Currently at 5.13
Proton: Steam version of wine-5.0 with added patches and modules (like dxvk++).
TKG: Custom wine that has loads of knobs to enable/disable patches - uses lots of patches from Proton. Can build "most" versions of wine
Lutris: Uses TKG sources to build a custom wine-staging for game compatibility. Currently at 5.7 due to upstream wine >5.10 disabling the "Esync/Fsync" patches.

If you use Proton or Lutris (Tkg), this will add multiple overrides for different libraries. Those are added to the "wine prefix registry", so if you switch BACK to a different version, the overrides are STILL THERE, and could explain why things break/works even tho it did not.

You can run: WINEPREFIX="/your/prefix/game/folder/whatever" winecfg
And look under "Libraries". Especially if you switch FROM a Lutris/Proton version TO a "regular" wine (like the distro included one), you should just clear out whatever is there. PS. If you use DXVK overrides you should not delete d3d11/dxgi++ overrides tho.

I blocked this version for no update. I'll keep installed versions for recover one that works.

Hello,
just tried with Wine-staging 5.14, still does not work.

Maybe this information will save someone the hassle of having to downgrade.

I have found a solution which works for me in wine-staging 5.9 with the rotating mouse. In WoW chatbox just type or copy this:

/console rawMouseEnable 1

As of current wow patch 8.7.3, this kinda borks mouse.

It is not a "wine issue", but it is a "Blizzard issue".
www.icy-veins.com/forums/topic/50901-how-to-fix-mouse-problems-after-patch-837/

"It is not a "wine issue", but it is a "Blizzard issue"."

It is not pure Blizzard issue, as mouse problem have been reported in other games, I also reported mouse messup using newest wine-staging few weeks back, and that was on WoW WotLK.

The reason i said this, is that it happens for Windows users aswell, so it is not a "wine bug"... unless ofc Blizzard got it "right" and there is a M$ API bug that wine also have implemented :)

The icy veins link shows that command with a 0 at the end, not a 1. so which do i use?

bugs.winehq.org/show_bug.cgi?id=49565 is the bug to watch here, 5.11+ is currently broken because ntdll is being worked upon and the staging patch required for wow was disabled therefore

Hello, anyone successful with running WoW with Wine Staging 5.11/5.12?
The game doesn't start for me, just empty window until I kill it manually.

Works fine with 5.10 staging

No i haven't,
it is either seh exception or nested exception spam on the console.
I guess we suffer from the same problem as bugs.winehq.org/show_bug.cgi?id=49436 Diablo3

With Wine-staging 5.12 occurs:

1. If I launch Wow.exe with openGL version, screen remains in black and if I do alt-tab, I can see that is a 132 windows error in the back.

2. If I launch Wow.exe with DXVK libraries, I can see in console al Vulkan info and nothing more. Remains stuck.

Luck that I have 5.8 compiled for me and works very good. I call 5.8 with /usr/local/bin/wine64 and 5.12 with /usr/bin/wine64.

World of warcraft no longer supports OpenGL as a API (and has not for quite a while). So launching Wow.exe with -opengl will be moot, and would default to whatever is detected... Most likely D3D12 if you have wine compiled with vkd3d support.
Wow.exe should be loaded with -d3d11, or edit the Config.wtf to force D3D11, unless you know 100% you use a working vkd3d.

WoW default is D3D12 "if detected", so in recent wine, it would be detected, but possibly not working too well...

Native DX12 and DX11 Modern, don't , multithreading is not implemented yet.

For those of you interested in testing, it seems as Valve/Steam proton-5.0 + vkd3d works fine with WoW and D3D12.

github.com/ValveSoftware/Proton

Click "wine" at the botton, and "clone or download" tab, then "Download ZIP". Continue to build wine how you usually do it.

I created a fresh wineprefix, installed the Battle.net client, logged on and exit. Then i just moved my c:/Program Files (x86)/World of Warcraft/ folder from my old prefix over, and started Battle.net client. It did some verification, and there we go.
To use D3D12, you need to build vkd3d separately as system library (can pull vkd3d from steam git and build aswell). You could always use DXVK and d3d11 if you do not venture that path. I have only tested vkd3d with nVidia hardware.

I decided to test this for 2 reasons.
1. Wine-staging-5.10 disabled "Esync - Eventfd synchronization", and thus the "Fsync" patches are not mergeable at the moment. (See: bugs.winehq.org/show_bug.cgi?id=36692#c16)
2. Proton is more tuned towards gaming/game performance. I have not done any benchmark comparisons between Proton-5.0 and Wine-staging-5.9.

You always could just add WOW to steam as non-steam game and checkbox to force-run it on the proton or use proton binary it installs, you only need to set the environment for that, or my issue is I experience random shutdowns, and it is impossible to debug them in the proton. In wine-staging 5.6-staging binary or self-compiled 5.8 with dxvk and staging patches it at least does not just shut down, but instead logout me with streaming data error. Performance-wise I see no significant difference between wine-staging with dxvk and steam proton, I am guessing they are doing something similar, there is only so much you can do to go from 10 fps on native wine dx implementation to stable-ish 40 on proton and dxvk. I rolled back to 5.6-staging binary since with self-compiled loading times increased significantly and I still got that error that annoyed me.

It was not "always so", cos last when i tried (albeit quite a while ago), Proton did not have all the patches for Battle.net (some encryption something), so you could not get signed in when doing that.
It might have worked since 5.0, cos i do not think i have tried after Proton-5.0 - until now that is.

And i agree, i find logging and stuff when running from steam to be a bit more awkward than doing it when running wine from a script, and i do not need the overhead of the steam client and whatnot running when i game.

As to the streaming data error... have you tried to download the wow cache files and use those? github.com/Bromeego/WoW-Cache
It replaces the "Cache" folder in your WoW installation folder with caches created from Windows.

Did anyone notice shutdowns of the game with recent versions of the game and wine-staging 5.10?
I get across ptr,classic and retail versions a popup that it cannot run in compatibility mode and then the game shuts down.

Today's update from 5.8 to 5.9 (in Ubuntu) seems to cause mouse rotate skips most of the time when I use the mouse to rotate my point of view. The view sometimes rotates much further than intended, sometimes up to 180° at a time even when the actual mouse movement should only warrant a small turn. Before I start filing a bug report, I'd like to know if I'm the only one with that kind of experience.

It's already been reported and fixed. Please downgrade to previous version, fix will be released once packaged into new version :)

Just stay with 5.8 version and wait for 5.10. They've broken WoW in 5.7 and again with 5.9, thus 5.10 should be okay before 5.11 will break it again.

Sorry for another post. This is the revised post of my previous steps but more comments and commands to do.

I hope now are complete (you are free to purge the previous comments of me).


#Pasos hechos para openSUSE Leap 15.1, espero que aplicables a otras distros // Steps done for openSUSE Leap 15.1. I hope that are applicable to other dsitributions

#Si el configure acaba con "configure: Finished. Do 'make' to compile Wine." y os dice un poco más arriba que no encuentra libhal, libsane, gstreamer, OSS Sound System, libFAudio o (en el caso de la build de 32 bit) vkd3d, no pasa nada. Nada de esto le hace falta a Wine. //
If configure finish with "configure: Finished. Do 'make' to compile Wine." and say a little above that not find libhal, libsane, gstreamer, OSS Sound System, libFAudio or (in the case of 32 bit build) vkd3d, it's OK. Nothing of these is necessary for Wine.

#Instalando deps // Installing deps

alsa-devel capi4linux-devel dbus-1-devel fontconfig-devel freeglut-devel freetype2-devel giflib-devel glib2-devel glibc-devel glu-devel gstreamer-devel gstreamer-plugins-base-devel krb5-devel libcom_err-devel libexif-devel libgnutls-devel libgphoto2-devel libgsm-devel libjpeg8-devel liblcms2-devel libmpg123-devel libOSMesa-devel libpcap-devel libpng16-compat-devel libpulse-devel libSDL2-devel libtiff-devel libudev-devel libv4l-devel libX11-devel libXcomposite-devel libXcursor-devel libXext-devel libXfixes-devel libXi-devel libXinerama-devel libXxf86vm-devel libxml2-devel libXrandr-devel libXrender-devel libxslt-devel Mesa-libGL-devel mpg123-devel ncurses-devel openal-soft-devel opencl-headers openldap2-devel libopenssl-devel sane-backends-devel unixODBC-devel xorg-x11-devel vulkan-devel xz-devel zlib-devel

En un sistema de 64 bits, también hará falta instalar los siguientes paquetes de 32 bits // On a 64 bit system, you will also need to install the following -32bit packages:

alsa-devel-32bit capi4linux-devel-32bit dbus-1-devel-32bit fontconfig-devel-32bit freeglut-devel-32bit freetype2-devel-32bit giflib-devel-32bit glib2-devel-32bit glibc-devel-32bit glu-devel-32bit krb5-devel-32bit libcom_err-devel-32bit libgnutls-devel-32bit libgphoto2-devel-32bit libgsm-devel-32bit libjpeg8-devel-32bit liblcms2-devel-32bit libOSMesa-devel-32bit libpcap-devel-32bit libpng16-compat-devel-32bit libpulse-devel-32bit libSDL2-devel-32bit libtiff-devel-32bit libv4l-devel-32bit libX11-devel-32bit libXcomposite-devel-32bit libXcursor-devel-32bit libXext-devel-32bit libXfixes-devel-32bit libXi-devel-32bit libXinerama-devel-32bit libXxf86vm-devel-32bit libxml2-devel-32bit libXrandr-devel-32bit libXrender-devel-32bit libxslt-devel-32bit Mesa-libGL-devel-32bit mpg123-devel-32bit ncurses-devel-32bit openal-soft-devel-32bit openldap2-devel-32bit libopenssl-devel-32bit unixODBC-devel-32bit xz-devel-32bit zlib-devel-32bit

(Instalando el paquete wine-32bit-build-deps instalará muchos de los paquetes de 32 bits mencionados encima.) // (Installing the wine-32bit-build-deps package will install most of the -32bit packages listed above.)

#Instalando Vulkan // Installing Vulkan
$ sudo zypper ar download.opensuse.org/repositories/home:/regataos/openSUSE_Leap_15.1/ Vulkan
$ sudo zypper ref
#Instalar los siguientes paquetes del repo añadido arriba (actualmente Vulkan es versión 1.2.137) // Install the next packages from the repo added above (today Vulkan is version 1.2.137)
$ sudo zypper in libvkd3d-utils1
$ sudo zypper in libvkd3d1
$ sudo zypper in libvulkan1
$ sudo zypper in libvulkan1-32bit
$ sudo zypper in vkd3d-devel
$ sudo zypper in vulkan-devel
$ sudo zypper in vulkan-headers
$ sudo zypper in vulkan-tools

#Desde Home // From Home
$ cd $HOME

#Creando directorios en $HOME // Making directories in $HOME
$ mkdir wine-dirs
$ mkdir ./wine-dirs/wine32-build
$ mkdir ./wine-dirs/wine64-build
$ mkdir ./wine-dirs/wine-sources

#Bajando Wine Source // Downloading Wine Source
$ wget dl.winehq.org/wine/source/5.x/wine-5.8.tar.xz
#Extrayendo Wine Source // Extracting Wine Source
$ tar -xvf ./wine-5.8.tar.xz --directory ./wine-dirs/wine-sources

#Bajando parches Staging // Downloading Staging patches
$ cd wine-dirs
$ git clone github.com/wine-staging/wine-staging.git

#Aplicando parches Staging // Applying Staging patches
1º Asegurarse de meter todo el contenido de Wine Source de $HOME/wine-dirs/wine-sources/wine-5.8 en $HOME/wine-dirs/wine-sources
//
1st Make sure to put all content of Wine Source from $HOME/wine-dirs/wine-sources/wine-5.8 to $HOME/wine-dirs/wine-sources
$ cd wine-staging
$ ./patches/patchinstall.sh DESTDIR="../wine-sources" --all

#Configurando Wine 64bit // Configure Wine 64bit
$ cd $HOME/wine-dirs//wine64-build
$ CC="ccache gcc" $HOME/wine-dirs/wine-sources/configure CFLAGS='-march=native -mtune=native -O3 -fPIC -fomit-frame-pointer -pipe' --enable-win64 --without-gtk3 --with-vkd3d --with-vulkan --without-mingw --disable-tests

#Compilando Wine 64bit (-j4 para CPUs de 4 núcleos) // Compile Wine 64bit (-j4 for CPUs with 4 cores)
$ make -j4

#Instalando deps pendientes Wine 32bit // Installing missing deps Wine 32bit
$ sudo zypper in sane-backends-devel-32bit
$ sudo zypper in libusb-1_0-devel-32bit
$ sudo zypper in gstreamer-plugins-base-devel-32bit
$ sudo zypper in libudev-devel-32bit
$ sudo zypper in libgcrypt-devel-32bit
$ sudo zypper in cups-devel-32bit
$ sudo zypper in libglvnd-devel-32bit

#Cambiar vulkan-devel x86_64 a i586 // Change vulkan-devel x86_64 to i586
$ sudo zypper in vulkan-devel-1.2.137-lp151.53.1.i586

#Configurando Wine 32bit (no vkd3d)// Configure Wine32bit (novkd3d)
$ cd $HOME/wine-dirs/wine32-build
$ CC="ccache gcc -m32" $HOME/wine-dirs/wine-sources/configure CFLAGS='-march=native -mtune=native -O3 -fPIC -fomit-frame-pointer -pipe' --with-wine64=$HOME/wine-dirs/wine64-build --without-gtk3 --with-vulkan --without-mingw

#Compilando Wine 32bit (-j4 para CPUs de 4 núcleos) // Compile Wine 32bit (-j4 for CPUs with 4 cores)
$ make -j4

#Instalar archivos 64bit // Install 64bit files
$ cd $HOME/wine-dirs/wine64-build
$ sudo make install

#Instalar archivos 32bit // Install 32bit files
$ cd $HOME/wine-dirs/wine32-build
$ sudo make install

#Cambiar vulkan-devel i586 a x86_64// Change vulkan-devel i586 to x86_64
$ sudo zypper in vulkan-devel-1.2.137-lp151.53.1.x86_64

#Ejecutar wine64 (or wine) del directorio /usr/local/bin // Run wine64 (or wine) located at /usr/local/bin

I run an amd 480 on a Kubuntu 20.04 System and i wonder why the DX11 renderer is going insanely slow compared to the dx11 legacy version.
What difference is there that makes such a day and night difference between slideshow and playable?

Without having verified this, the DX11 "engine" is using multithreading. The "Legacy" one does not. I do not think WineD3D engine has the multithreading capability at all, so i would imagine that things slow to a grinding halt when this is attempted.

us.forums.blizzard.com/en/wow/t/new-graphics-apis-in-8-1-5/121542

Since the site seems broken atm, and replies does not work, i will attempt to answer like this.

The development files that wine configure is looking for is vulkan-headers and libvkd3d-dev

I think the packages that configure is looking for is vulkan-headers, and it might be that the libvkd3d-dev that you use is too old? you might need to build vkd3d yourself, or get some pre-compiled ones that are up-to-date. (The "released 1.1" version of vkd3d does not work with WoW tho). Unless you build vkd3d yourself, i would stick with dxvk and dx11 tbh.

Now, i must admit i am utterly clueless to how Fedora actually manages the various .x86_64 vs .i586 libraries and their counterparts, but you need both 64-bit (x86_64) and 32-bit (i586) to build wine, although i dont know if the headers are different when building. The libraries themselves are different, so for running WoW (and battle.net) you need BOTH libvulkan for x86_64 and i586 since battle.net is 32-bit.

Good luck :)

Thanks for reply and tips.

In my previous post (with 1.0.65 version of vulkan) I put the packages used in a 2nd try of compile Wine (that I don't complete the build version, I am only trying).

In my first try (that is the Wine I am using) was with these files (vulkan 1.2.137 instead of 1.0.65 in my previous post):

krovikan@linux:~/Descargas> zypper se -iv vulkan
Cargando datos del repositorio...
Leyendo los paquetes instalados...

E | Nombre | Tipo | Versión | Arquitectura | Repositorio
---+------------------+---------+--------------------+--------------+---------------------
i+ | libvulkan1 | paquete | 1.2.137-lp151.53.1 | x86_64 | home:regataos Vulkan
name: libvulkan1
i+ | libvulkan1-32bit | paquete | 1.2.137-lp151.53.1 | x86_64 | home:regataos Vulkan
name: libvulkan1-32bit
i+ | vulkan-devel | paquete | 1.2.137-lp151.53.1 | x86_64 | home:regataos Vulkan
name: vulkan-devel
i | vulkan-headers | paquete | 1.2.137-lp151.47.1 | noarch | home:regataos Vulkan
name: vulkan-headers
i+ | vulkan-tools | paquete | 1.2.137-lp151.50.1 | x86_64 | home:regataos Vulkan
name: vulkan-tools

vulkan-devel x86_64 provides:

pkgconfig(vulkan) = 1.2.137
vulkan-devel = 1.2.137-lp151.53.1
vulkan-devel(x86-64) = 1.2.137-lp151.53.1

vulkan-devel i586 provides (this package is not installed, or X86_64 or i586 but not both at once) :

pkgconfig(vulkan) = 1.2.137
vulkan-devel = 1.2.137-lp151.53.1
vulkan-devel(x86-32) = 1.2.137-lp151.53.

vulkan-headers x86_64 provides:

vulkan-headers = 1.2.137-lp151.47.1

I used vulkan-headers in my operational Wine. But the error message what's the same in 32bit build (is because this that I remove switches --with-vulkan and --with-vkd3d in 32 bit build).

I am not worried about vkd3d (I don't need). I am more worried with vulkan.

Regards

I say the answer in the post. Now, I have Wine 64 and Wine 32, both with support Vulkan for DXVK.

My steps:

#Instalando deps // Installing deps
alsa-devel capi4linux-devel dbus-1-devel fontconfig-devel freeglut-devel freetype2-devel giflib-devel glib2-devel glibc-devel glu-devel gstreamer-devel gstreamer-plugins-base-devel krb5-devel libcom_err-devel libexif-devel libgnutls-devel libgphoto2-devel libgsm-devel libjpeg8-devel liblcms2-devel libmpg123-devel libOSMesa-devel libpcap-devel libpng16-compat-devel libpulse-devel libSDL2-devel libtiff-devel libudev-devel libv4l-devel libX11-devel libXcomposite-devel libXcursor-devel libXext-devel libXfixes-devel libXi-devel libXinerama-devel libXxf86vm-devel libxml2-devel libXrandr-devel libXrender-devel libxslt-devel Mesa-libGL-devel mpg123-devel ncurses-devel openal-soft-devel opencl-headers openldap2-devel libopenssl-devel sane-backends-devel unixODBC-devel xorg-x11-devel vulkan-devel xz-devel zlib-devel

On a 64 bit system, you will also need to install the following -32bit packages:

alsa-devel-32bit capi4linux-devel-32bit dbus-1-devel-32bit fontconfig-devel-32bit freeglut-devel-32bit freetype2-devel-32bit giflib-devel-32bit glib2-devel-32bit glibc-devel-32bit glu-devel-32bit krb5-devel-32bit libcom_err-devel-32bit libgnutls-devel-32bit libgphoto2-devel-32bit libgsm-devel-32bit libjpeg8-devel-32bit liblcms2-devel-32bit libOSMesa-devel-32bit libpcap-devel-32bit libpng16-compat-devel-32bit libpulse-devel-32bit libSDL2-devel-32bit libtiff-devel-32bit libv4l-devel-32bit libX11-devel-32bit libXcomposite-devel-32bit libXcursor-devel-32bit libXext-devel-32bit libXfixes-devel-32bit libXi-devel-32bit libXinerama-devel-32bit libXxf86vm-devel-32bit libxml2-devel-32bit libXrandr-devel-32bit libXrender-devel-32bit libxslt-devel-32bit Mesa-libGL-devel-32bit mpg123-devel-32bit ncurses-devel-32bit openal-soft-devel-32bit openldap2-devel-32bit libopenssl-devel-32bit unixODBC-devel-32bit xz-devel-32bit zlib-devel-32bit

(Installing the wine-32bit-build-deps package will install most of the -32bit packages listed above.)

#Desde Home // From Home
$ cd $HOME

#Creando directorios en $HOME // Making directories in $HOME
$ mkdir wine-dirs
$ mkdir ./wine-dirs/wine32-build
$ mkdir ./wine-dirs/wine64-build
$ mkdir ./wine-dirs/wine-sources

#Bajando Wine Source // Downloading Wine Source
$ wget dl.winehq.org/wine/source/5.x/wine-5.8.tar.xz
#Extrayendo Wine Source // Extracting Wine Source
$ tar -xvf ./wine-5.8.tar.xz --directory ./wine-dirs/wine-sources

#Bajando parches Staging // Downloading Staging patches
$ cd wine-dirs
$ git clone github.com/wine-staging/wine-staging.git

#Aplicando parches Staging // Applying Staging patches
1º Asegurarse de meter todo el contenido de Wine Source de $HOME/wine-dirs/wine-sources/wine-5.8 en $HOME/wine-dirs/wine-sources
//
1st Make sure to put all content of Wine Source from $HOME/wine-dirs/wine-sources/wine-5.8 to $HOME/wine-dirs/wine-sources
$ cd wine-staging
$ ./patches/patchinstall.sh DESTDIR="../wine-sources" --all

#Configurando Wine 64bit // Configure Wine 64bit
$ cd $HOME/wine-dirs//wine64-build
$ CC="ccache gcc" $HOME/wine-dirs/wine-sources/configure CFLAGS='-march=native -mtune=native -O3 -fPIC -fomit-frame-pointer -pipe' --enable-win64 --without-gtk3 --with-vkd3d --with-vulkan --without-mingw --disable-tests

#Compilando Wine 64bit // Compile Wine 64bit
$ make -j4

#Instalando deps pendientes Wine 32bit // Installing missing deps Wine 32bit
$ sudo zypper in sane-backends-devel-32bit
$ sudo zypper in libusb-1_0-devel-32bit
$ sudo zypper in gstreamer-plugins-base-devel-32bit
$ sudo zypper in libudev-devel-32bit
$ sudo zypper in libgcrypt-devel-32bit
$ sudo zypper in cups-devel-32bit
$ sudo zypper in libglvnd-devel-32bit

#Cambiar vulkan-devel x86_64 a i586 // Change vulkan-devel x86_64 to i586

#Configurando Wine 32bit (no vkd3d)// Configure Wine32bit (novkd3d)
$ cd $HOME/wine-dirs/wine32-build
$ CC="ccache gcc -m32" $HOME/wine-dirs/wine-sources/configure CFLAGS='-march=native -mtune=native -O3 -fPIC -fomit-frame-pointer -pipe' --with-wine64=$HOME/wine-dirs/wine64-build --without-gtk3 --with-vulkan --without-mingw

#Compilando Wine 32bit // Compile Wine 32bit
$ make -j4

#Instalar archivos 64bit // Install 64bit files
$ cd $HOME/wine-dirs/wine64-build
$ sudo make install

#Instalar archivos 32bit // Install 32bit files
$ cd $HOME/wine-dirs/wine32-build
$ sudo make install

#Cambiar vulkan-devel i586 a x86_64// Change vulkan-devel i586 to x86_64

#Ejecutar wine64 (or wine) del directorio /usr/local/bin // Run wine64 (or wine) located at /usr/local/bin

Hello:

Wine 32 and Wine 64 are running. I can play World of Warcraft. But..

I don't have support of Vulkan (or vkd3d) for Blizzard Launcher that is made in 32 bit (yes, in configure of Wine 32 I was forced to remove --with-vulkan and --with-vkd3d switches)

If I try to start Blizzard Launcher with DXVK, crash after login to Launcher.

My configure for Wine 32:

configure: libvulkan and libMoltenVK 32-bit development files not found, Vulkan won't be supported.
configure: vkd3d 32-bit development files not found (or too old), Direct3D 12 won't be supported.

My vulkan files:

krovikan@linux:~/wine-dirs/wine32-build> zypper se -iv vulkan
Cargando datos del repositorio...
Leyendo los paquetes instalados...

E | Nombre | Tipo | Versión | Arquitectura | Repositorio
---+--------------------+---------+--------------------+--------------+----------------------------
i+ | libvulkan1 | paquete | 1.0.65.0-lp151.4.4 | x86_64 | Repositorio principal (OSS)
name: libvulkan1
i+ | libvulkan1-32bit | paquete | 1.0.65.0-lp151.4.4 | x86_64 | Repositorio principal (OSS)
name: libvulkan1-32bit
i+ | vulkan | paquete | 1.0.65.0-lp151.4.4 | x86_64 | Repositorio principal (OSS)
name: vulkan
i+ | vulkan-devel | paquete | 1.0.65.0-lp151.4.4 | x86_64 | Repositorio principal (OSS)
name: vulkan-devel
i+ | vulkan-devel-32bit | paquete | 1.0.65.0-lp151.4.4 | x86_64 | Repositorio principal (OSS)
name: vulkan-devel-32bit

My vkd3d files:

krovikan@linux:~/wine-dirs/wine32-build> zypper se -iv vkd3d
Cargando datos del repositorio...
Leyendo los paquetes instalados...

E | Nombre | Tipo | Versión | Arquitectura | Repositorio
---+-----------------+---------+----------------+--------------+---------------------
i | libvkd3d-utils1 | paquete | 1.1-lp151.32.1 | x86_64 | home:regataos Vulkan
name: libvkd3d-utils1
i | libvkd3d1 | paquete | 1.1-lp151.32.1 | x86_64 | home:regataos Vulkan
name: libvkd3d1
i+ | vkd3d-devel | paquete | 1.1-lp151.32.1 | x86_64 | home:regataos Vulkan
name: vkd3d-devel

I have the same if I install Vulkan 1.2.137 from download.opensuse.org/repositories/home:/regataos/openSUSE_Leap_15.1/

I searched for internet and I don't know what to do.

I had 1 FPS in raid groups with Wine 5.6, DXVK 1.6.1, GeForce GTX 950M (proprietary drivers) and it turned out that it was because of IceHUD WoW addon. If You have performance problems, try disabling all addons and if it helps, then turn them on in groups to pin down the problematic one.

I see smarter people than me say how to fix it, but I found an easier way (imo) for idiots like me
I installed Lutris -> searched for WoW -> installed bnet -> created a symlink to my already installed wow in my wineprefix -> launched bnet from lutris -> started WoW
This was simpler for me than downgrading wine or compiling it myself

Tried to enter this as a reply, and the site would not let me, so making a new comment.

I have created a wine-dirs folder from my home folder, and run the following script inside that folder. It downloads the wine development, and the wine-staging and applies the wine staging patches, so that when it is done, you can run the build script I sent in the previous message.

clear
echo Cleanup and fresh download of repositories needed
rm -fr wine
rm -fr wine-staging
echo WineHQ Devel Source Git
git clone github.com/wine-mirror/wine.git
echo Unoffical Wine Staging Git
git clone github.com/wine-staging/wine-staging.git
cd wine-staging
echo Working in $(pwd)
./patches/patchinstall.sh DESTDIR="../wine" --all
cd ~/wine-dirs
echo this is the end, if no errors were presented, then compile and enjoy

I use the following script to compile on my computer, so you will need to change the march and mtune options to match your processor, or just remove them. My system is Fedora 32, AMD FX 8350 8 core, Geforce 1050, 32Gig 1866Mhz DDR3, Nvidia Proprietary driver 480.22.

clear
echo Clean Start
rm -fr wine64-build
rm -fr wine32-build
echo Make Build Directories
mkdir wine64-build
mkdir wine32-build
cd wine64-build
../wine/configure CFLAGS='-march=bdver2 -mtune=bdver2 -O3 -fPIC -fomit-frame-pointer -pipe' --enable-win64 --without-gtk3 --with-vkd3d --with-vulkan --without-mingw
make -j8 && cd ../wine32-build && PKG_CONFIG_PATH=/usr/lib/pkgconfig ../wine/configure CFLAGS='-march=bdver2 -mtune=bdver2 -O3 -fPIC -fomit-frame-pointer -pipe' --with-wine64=../wine64-build --without-gtk3 --without-mingw --with-vkd3d --with-vulkan && make -j8

Good Luck

I have openSUSE Leap 15.1.

To do all this, I need to git clone 2 times the wine git?

Seems that, reading wiki.winehq.org/OpenSUSE is necessary (if I have a mistake reading some point, please tell me.) do (my comments are with \\\ before):

Install patterns-openSUSE-devel_basis and make sure that ccache, git, , gcc-32bit and bison-32bit are installed.

Install the devels:

alsa-devel capi4linux-devel dbus-1-devel fontconfig-devel freeglut-devel freetype2-devel giflib-devel glib2-devel glibc-devel glu-devel gstreamer-devel gstreamer-plugins-base-devel krb5-devel libcom_err-devel libexif-devel libgnutls-devel libgphoto2-devel libgsm-devel libjpeg8-devel liblcms2-devel libmpg123-devel libOSMesa-devel libpcap-devel libpng16-compat-devel libpulse-devel libSDL2-devel libtiff-devel libudev-devel libv4l-devel libX11-devel libXcomposite-devel libXcursor-devel libXext-devel libXfixes-devel libXi-devel libXinerama-devel libXxf86vm-devel libxml2-devel libXrandr-devel libXrender-devel libxslt-devel Mesa-libGL-devel mpg123-devel ncurses-devel openal-soft-devel opencl-headers openldap2-devel libopenssl-devel sane-backends-devel unixODBC-devel xorg-x11-devel vulkan-devel xz-devel zlib-devel

and the 32bit devels:

alsa-devel-32bit capi4linux-devel-32bit dbus-1-devel-32bit fontconfig-devel-32bit freeglut-devel-32bit freetype2-devel-32bit giflib-devel-32bit glib2-devel-32bit glibc-devel-32bit glu-devel-32bit krb5-devel-32bit libcom_err-devel-32bit libgnutls-devel-32bit libgphoto2-devel-32bit libgsm-devel-32bit libjpeg8-devel-32bit liblcms2-devel-32bit libOSMesa-devel-32bit libpcap-devel-32bit libpng16-compat-devel-32bit libpulse-devel-32bit libSDL2-devel-32bit libtiff-devel-32bit libv4l-devel-32bit libX11-devel-32bit libXcomposite-devel-32bit libXcursor-devel-32bit libXext-devel-32bit libXfixes-devel-32bit libXi-devel-32bit libXinerama-devel-32bit libXxf86vm-devel-32bit libxml2-devel-32bit libXrandr-devel-32bit libXrender-devel-32bit libxslt-devel-32bit Mesa-libGL-devel-32bit mpg123-devel-32bit ncurses-devel-32bit openal-soft-devel-32bit openldap2-devel-32bit libopenssl-devel-32bit unixODBC-devel-32bit xz-devel-32bit zlib-devel-32bit

Do symlinks (in Leap 15 the targets of the symlinks may need to be adjusted for other versions of openSUSE, depending on what version of the library you have installed) :

ln -s libgstreamer-1.0.so.0 libgstreamer-1.0.so
ln -s libgstbase-1.0.so.0 libgstbase-1.0.so
ln -s libGL.so.1 libGL.so

\\\ I have:
ls -all /usr/lib/libgstreamer*
lrwxrwxrwx 1 root root 28 mar 31 2019 /usr/lib/libgstreamer-1.0.so.0 -> libgstreamer-1.0.so.0.1205.0
-rwxr-xr-x 1 root root 1422996 mar 31 2019 /usr/lib/libgstreamer-1.0.so.0.1205.0
ls -all /usr/lib/libgstbase*
lrwxrwxrwx 1 root root 26 mar 31 2019 /usr/lib/libgstbase-1.0.so.0 -> libgstbase-1.0.so.0.1205.0
-rwxr-xr-x 1 root root 490308 mar 31 2019 /usr/lib/libgstbase-1.0.so.0.1205.0
ls -all /usr/lib/libGL.so*
lrwxrwxrwx 1 root root 14 dic 17 2018 /usr/lib/libGL.so.1 -> libGL.so.1.0.0
-rwxr-xr-x 1 root root 415292 dic 17 2018 /usr/lib/libGL.so.1.0.0
\\\ Is this correct?

Jump to 2.2.4 for do the Shared WOW64 \\\ I think is the right, need confirmation (I always have wine-staging and wine-staging-32bit)

For 64bit:

cd $HOME
\\\ Is right to do here git clone source.winehq.org/git/wine.git and rename the directory to wine64 instead of making?
mkdir wine64
cd wine64
CC="ccache gcc" ../wine-git/configure --enable-win64 --disable-tests \\\ I need to add the rest of the flags you have in the post after CFLAGS?

make \\\ What means make -j8?

For 32bit:

cd ..
\\\ Is right to do here git clone source.winehq.org/git/wine.git and rename the directory to wine32 instead of making?
mkdir wine32
cd wine32
CC="ccache gcc -m32" PKG_CONFIG_PATH=/usr/lib/pkgconfig ../wine-git/configure --with-wine64=../wine64 --disable-tests \\\ I need to add the rest of the flags you have in the post after CFLAGS?

make \\\ What means make -j8?


All this (if work) have the patches of wine-staging or is a plain wine?

@Alberto
Here is more general description of what you need to do to comile wine wiki.winehq.org/Building_Wine
On most modern distros you need WOW64 part of the explanation
Bow about your questions:
First, directory structures^
All of the modern wine build instructions expect something like this:
$HOME/wine-dirs - just a distinct place you gonna do it in all, can be anything, but you need to change paths in later scripts too
$HOME/wine-dirs/wine-source can also ba named whatever, for example Steve have it named simply 'wine', you can see it here:
'../wine/configure'
Next, we need 2 preferably separate directories to compile our binaries into, usually, it is done by changing directory into them, and configuring source project from them, configurator automatically copies everything for compilation into the current directory. there are other ways, but this is the easiest.
In all the manuals it is wine64-build and wine32-build, for WOW64 we need both archs, more in the link at the top of my post
there is also separate wine-staging git project, which applies some patches to wine. If you need those patches, you need to follow separate instructions for that: github.com/wine-staging/wine-staging
So, usually, it goes like this:
- you create all your project directory structure
$ mkdir wine-dirs
$ mkdir ./wine-dirs/wine32-build
$ mkdir ./wine-dirs/wine64-build
$ mkdir ./wine-dirs/wine-sources
- You download wine source code, e.g.
$ wget dl.winehq.org/wine/source/5.x/wine-5.8.tar.xz
- You extract wine source in the wine-source directory if you have chosen to download tarball e.g:
$ tar -xvf ./wine-5.8.tar.xz --directory ./wine-dirs/wine-sources
- You download staging patches, e.g
$ cd wine-dirs
$ git clone github.com/wine-staging/wine-staging
- you apply staging patches, e.g:
$ cd wine-staging
$ ../patches/patchinstall.sh DESTDIR="../wine-sources" --all
- you go to the wine64 build directory and start configure script look at all "this DEV library is not found, this functionality will be disabled" messages, google how that DEV library is called in your distro and install it, continue until most (ideally-all) of the libraries is installed. More in this in WOW64 part of the building wine manual, link at the top

- make -j(number) is just to build something quicker if you got more cores, just calling make is safe option

- all the enviromental values can be set just before actual make in one line, those are CFLAGS or PKG_CONFIG_PATH,
- all the options for the make itself should go after calling make, those look like '--with-vkd3d',
--!!--You only need to specify PKG_CONFIG_PATH for wine32-build, everything else should be called with knowledge of what it does or not used at all. Knowledge is available on google, no other way around it
unfortunately.

tl;dr IMHO easier to just downgrade to older binaries, I am relatively proficient with compiling own version of stuff on Linux, and current;y wine-staging 5.8 (compiled and binaries) does not work for me either. Wine 5.6 binaries on the other hand, work quite well.

I think it is saner to just '-march=naitve -mtune=native', that would work for most of ppl or just fallback to plain no optimisation compiling. '-fPIC -fomit-frame-pointer' are also default in gcc now.

First all, a lot of thanks to @yearswriter from this detailed explanation.

Until now I do:

#Desde Home // From Home
$ cd $HOME

#Creando directorios en $HOME // Making directories in $HOME
$ mkdir wine-dirs
$ mkdir ./wine-dirs/wine32-build
$ mkdir ./wine-dirs/wine64-build
$ mkdir ./wine-dirs/wine-sources

#Bajando Wine Source // Downloading Wine Source
$ wget dl.winehq.org/wine/source/5.x/wine-5.8.tar.xz
#Extrayendo Wine Source // Extracting Wine Source
$ tar -xvf ./wine-5.8.tar.xz --directory ./wine-dirs/wine-sources

#Bajando parches Staging // Downloading Staging patches
$ cd wine-dirs
$ git clone github.com/wine-staging/wine-staging.git

#Aplicando parches Staging // Applying Staging patches
1º Asegurarse de meter todo el contenido de Wine Source de $HOME/wine-dirs/wine-sources/wine-5.8 en $HOME/wine-dirs/wine-sources
//
1st Make sure to put all content of Wine Source from $HOME/wine-dirs/wine-sources/wine-5.8 to $HOME/wine-dirs/wine-sources
$ cd wine-staging
$ ./patches/patchinstall.sh DESTDIR="../wine-sources" --all


All until now is OK (to work git was necessary include ). But now I am stuck.

In wiki.winehq.org/OpenSUSE#Building_Shared_WoW64 say me that for configure is:
$ CC="ccache gcc" ../wine-git/configure --enable-win64 --disable-tests
and after is the turn of
$ make

How I can adapt the order above to configure (for after do make order if all is OK configured) witht the order (or orders) from @Steve Ebey?:
$ ../wine/configure CFLAGS='-march=bdver2 -mtune=bdver2 -O3 -fPIC -fomit-frame-pointer -pipe' --enable-win64 --without-gtk3 --with-vkd3d --with-vulkan --without-mingw
make -j8

I don't know if is all OK but I configured with:

CC="ccache gcc" $HOME/wine-dirs/wine-sources/configure CFLAGS='-march=native -mtune=native -O3 -fPIC -fomit-frame-pointer -pipe' --enable-win64 --without-gtk3 --with-vkd3d --with-vulkan --without-mingw --disable-tests

pastebin.com/5gsw8hNR

Is too long, so I make a pastebin.

I am worried with the error of libFAudio. Is necessary?
The rest of configure is OK? Because I don't know how to interpret what lines are correct and what lines are wrong.

Build 64 is done.

Build 32 is stucked in:

configure: error: libvulkan and libMoltenVK 32-bit development files not found, Vulkan won't be supported.
This is an error since --with-vulkan was requested.

My vulkan is from download.opensuse.org/repositories/home:/regataos/openSUSE_Leap_15.1/
version 1.2.137

I have vulkan-devel 1.2.137 that provides vulkan-devel = 1.2.137 and vulkan-devel(x86-64) = 1.2.137 :S
Look lke as the 1 package provides 32 and 64 bit devel, but configure is stopped.

Yeah, WoW with wine 5.7 binaries on Ubuntu does not work.
Works for me with 5.6 eoan binaries, both on Ubuntu 19.04 and 20

With 5.7 binaries from wineHQ repo it freezes right after creating the window.
Compiling my own wine from git changed the behaviour, it froze a little bit further, I can see login prompt and some UI rendered after wineserver crashed and asked for enabling dumps, but it is really hard to debug since it hungs my whole X.

Reverted to 5.6 binary from eoan (after installing wineHQ wine eoan repo), works more or less with dxvk 1.6.1 only occasional logout with data streaming error from client, usually when I open trade\inventory\collections, but also sometimes right ater loading somewhere.

$ sudo apt remove wine-staging wine-staging-amd64 wine-staging-i386:i386
$ sudo apt-get install wine-staging=5.6* wine-staging-amd64=5.6* wine-staging-i386:i386=5.6* winehq-staging=5.6*
$ WINEPREFIX=~/.wine56 winecfg

5.8 same mistake both in compiled localy and binary from repo:
$ 0024:err:seh:setup_exception stack overflow 2528 bytes in thread 0024 eip 000000007bccb403 esp 0000000000120c30 stack 0x120000-0x121000-0x220000

Compiled working wine 5.8 with staging patches on Ubuntu ~focal.
Intel Core I3-6006U
Nvidia GeForce 940Mx w 2Gb VRAM
8 Gb DDR4
Applied all patches from wine-staging
No CFLAG optimisation flags,
Configure options: '--without-mingw --with-vkd3d --with-vulkan'

after last update (2 or 3 days ago) i didn't run the game and now it go to the zombie state

The title say the question.

I begin to think that until the weekend or so far, WoW will be borked.

Bye to the children's week. :(

With wine-staging 5.8, World of Warcraft continue borked. :(

My system is openSuSE Leap 15.1, kernel 5.5.7-1, KDE Plasma 5.18.5, KDE Framewotk 5.69, Qt 5.14.1, i5 6600K, Nvidia 1070 GTX with 440.66.11 Beta driver, 32Gb RAM

Curious. Now, World of Warcraft Classic works!!! (before Classic had the same error as the Retail)

But Retail (BfA), what is my interest, continue with the *** stack smashing detected ***: terminated :((

Inredible. I install the PTR, make a Troll Zandalari and the game works, but in PTR.

And Retail nothing of nothing.

After much flailing about, including complete uninstalls of wine, I finally succeeded in getting the 'force version' to take by:
installing 32 bit first
then 64 bit
then winehq-staging

using synaptic.

My current problem - now battle.net app dies after login, with a
'failed to create graphic content'
whiney. It was working fine prior to my attempts to roll back 5.7.

I've used wine uninstaller to remove all versions of mono and gecko; also removed the Ubuntu versions I tried installing.
Oddly, with those removed, running wine did NOT trigger an install.
I tried renaming .cache/wine then launching batnet - still no install attempt.

After uninstalling all of gecko and mono, I ran msiexec /i on the cache msi files in .cache/wine.
Uninstaller now sees: winegecko 2.47.1 (both 32 and 64), and wine mono (runtime and windows support) 4.94

I presume that means wine should know those are there and to use them?

I compiled my own version of wine-staging to get past the regression.
Does anyone have an idea how a Computer with a 8gb vram gpu and 16b ram itself can end up with wow causing these lines and a colored moire effect on the login screen?

0024:err:virtual:try_map_free_area wine_anon_mmap() error Nicht genügend Hauptspeicher verfügbar, start 0x142ea0000, size 0x800001000, unix_prot 0x3.
There are almost 15 gb of ram free according to the system.

As of the April 29 patch I am also getting a crash at program launch. WoW had been working fine for months on Fedora Core 31 with the repo version of wine staging (5.6). I upgraded to Fedora Core 32 to pick up the new repo version (5.7-1), but still get the same error. Last bit of log below. I am using the kmod-nvidia-5.6.7-300 driver from rpmfusion repo.

info: Presenter: Actual swap chain properties:
info: Format: VK_FORMAT_B8G8R8A8_UNORM
info: Present mode: VK_PRESENT_MODE_FIFO_KHR
info: Buffer size: 1274x850
info: Image count: 3
info: Exclusive FS: 2
*** stack smashing detected ***: terminated

my nvidia driver version is 440.82 so I am wondering what driver you are running for your Nvidia. Might be too old of a driver. I have Fed 32, Nvidia 1050 and no problems, with either the distro or my self compiled wine, that is optimized for my processor.

Thanks, I have a "GeForce GTX 1050 Ti" and according to the NVIDIA server settings app, I've got the 440.82 driver version. So I guess it should be able to work. I wonder what is going wrong.

I run proprietary driver, maybe a glitch in package from kmod? are you starting from the launcher, or using a command line? I use dxvk 1.6.1 and my startup script is:

env DVXK_HUD="fps" DXVK_LOG_LEVEL=none STAGING_SHARED_MEMORY=1 STAGING_WRITECOPY=1 GL_THREADED_OPTIMIZATIONS=1 WINEDEBUG=-all wine64 '/home/steve/.wine/drive_c/Program Files (x86)/World of Warcraft/_retail_/Wow.exe' -d3d11 &>/dev/null

hope this helps

Hello,
that commands was working for me on Debian 10 Buster:

# install a specific version of wine, here 5.6:
apt-get install wine-staging-amd64=5.6~buster wine-staging-i386=5.6~buster wine-staging=5.6~buster winehq-staging=5.6~buster

# hold that packages, prevents an update
apt-mark hold wine-staging wine-staging-amd64 wine-staging-i386:i386 winehq-staging
apt-mark showhold

# remove the holding of the packages, if a new working package is available:
apt-mark unhold wine-staging wine-staging-amd64 wine-staging-i386:i386 winehq-staging

Greetings
Stefan

I am not able to test it right now. Is WoW running again with wine-staging 5.7-1?

Tested with Archlinux and wine-staging-5.7-1 and it is not working

Tonight, after the minipatch of yesterday at night, I can't launch WoW.

I press Play in Launcher and the button change to initializing but after 2-3 seconds nothing happens and the button change to Play (process WoW.exe is not created in Ksysguard).

The command to start Launcher is env DXVK_HUD=0 WINEDEBUG=-all WINEPREFIX="/home/krovikan/.winedxvk" wine64 '/mnt/juegos/wine/drive_c/Program Files (x86)/Battle.net/Battle.net.exe'

If I try manual start from exe file of the game by console:

krovikan@linux:/mnt/juegos/wine/drive_c/Program Files (x86)/World of Warcraft/_retail_> env DXVK_HUD=1 WINEDEBUG=-all WINEPREFIX=/home/krovikan/.winedxvk wine64 Wow.exe
*** stack smashing detected ***: terminated

The error is displayed after less than 1 second after I press Enter to accept the command to launch the game.

I don't change nothing at the system from yesterday (yesterday runs OK before the minipatch, after I don't know because I close Launcher after update).

My sistem is openSuSE Leap 15.1, kernel 5.5.7-1, KDE Plasma 5.18.4, KDE Framewotk 5.69, Qt 5.14.1, i5 6600K, Nvidia 1070 GTX with 440.66.11 Beta driver, 32Gb RAM (no changes of any type nor software updates from yesterday)

I can't find anything in Internet.

I have the same problem with 2 computers :

Computer 1 with wine-staging 5.3 and RADV + Radeon RX580 = ** STACK SMASHING DETECTED **. Update to wine-staging 5.7 and uninstall dxvk (1.6.1) doesn't change anything.

Computer 2 with wine-staging 5.7 and Mesa + Intel HD Graphic 5500 = ** STACK SMASHING DETECTED**

Computer 3 with wine-staging 5.7 and Nvidia Geforce 1070GTX and proprietary drivers the game run well, without problem.?!

All run Opensuse Tumbleweed with latest update. Wow classic run well. I have try to reinstall in a new prefix without success.

Sorry, I have now the same problem with computer 3.

It seems that I was able to connect yesterday without installing the mini patch and therefore the game worked well but this morning the patch was installed and I have the same problem.

On computer 1 and 3 I have wine-staging installed from official tumbleweed repo : version 5.7-3.1, on my laptop (computer 2), I have try to install wine from repository on the download page on the winehq website. The version is 5.7-1160.1 but nothing change I can't launch the game with the same ** STACK SMASHING DETECTED**.

The 3 computers have Tumbleweed with kernel 5.6.6-1 and KDE Plasma 5.18.4. Nvidia drivers is 440.82. I play without lutris or playonlinux.

I can't find anything on the internet, so I am not sure if the bug is specific to wine or Opensuse. I will try on Fedora.

I think it's a bug with Opensuse wine version.

I can launch World of Warcraft if I install PlayOnLinux, create a prefix (or reuse my wow prefix) and use wine-staging 5.6 provided by PlayOnLinux.

If I compile wine-staging from source I'm sure it will work.

I also started getting the "stack smashing" error. I am currently running 5.7 but I rolled back to 5.5 as well(both staging release from fedora). I also tested this with dxvk-1.6.1, 1.5, and I also did a test with no additional graphics layers included. The bug seems not graphics related at all, at least that our different graphics layers are affecting.

System specs for completeness: Ryzen 9 3950x, 64gb ram, Nvidia 2070S, on proprietary drivers(440.82). Fedora 32

3 of my other friends are also seeing the same issue. One was able to play for an extra day b/c he wasn't kicking off battlenet, and didn't get updated till later. So definitely related to the mini-patch on blizzards end too.

I think this is a problem related to some compilation option and that it only concerns a few distributions.
As I wrote above, I can play without problems using a version of wine provided by PlayOnLinux (5.6 staging).
I came across an old bug from 2015 concerning Fedora on the Redhat bugzilla and the "-fstack-protector-strong" option seemed to be in question.

Hello,
I can confirm that everything freezes on my system with 5.7-staging after the login screen, in the moment I enter the game.
I have to manually kill the wine process.

Strange thing:
I've noticed an improvement in everything is before the "entering game" phase.
I've always had a fraction of second of freeze at the startup at the characters display page, but with 5.7 it seemed extremely fast.

However it's unplayable.
Rolled back to staging 5.6

Archlinux
linux-5.6.7

Look at the bug reports, the 5.7 freeze is happening across a lot of games, and a patch has been released that fixes it, but only if you compile the wine source code yourself. I f you are using the distro version then you will just have to wait to get the updated wine, from the distro.

Sorry one Question. How to switch back from wine 5.8 to 5.7 on Ubuntu? Is there an easy way?

You mean from 5.7 -> 5.6 since 5.8 is not out yet? :)

You can install older packages by using the version number, but that would mean you should "pin"(lock) it to that version so it is not automatically upgraded by running apt upgrade.

I am at work atm, so can't test this, but maybe have a look at www.howtogeek.com/117929/how-to-downgrade-packages-on-ubuntu/ for a gui approach? There is probably easier methods with a quick one-liner, but have no way of testing this and i do not know how well versed in apt commands you are :)
Maybe something like "sudo apt install winehq-staging=5.6~bionic" (for Ubuntu 18.04). You should add a "-s" to the end so you "simulate" what would happen tho, and check that all sub-packages is downgraded. eg. "sudo apt install winehq-staging=5.6~bionic -s"
linoxide.com/linux-command/install-specific-version-package-apt-get/

OBS! Pay CLOSE attention tho, cos sometimes weird shit happens when you downgrade packages where some dependencies suddenly have you uninstall almost every package for strange reasons... so do not just click "apply" and hope for the best. You should not be "downgrading" 30-40-100 packages if that ends up being the suggestion! (Yes.. Suggestions like this MAY occurr when synaptic/apt are a bit too automagic). So BE WARNED and use WITH CARE!

Shown in the bug report for 49011 is a patch, to apply to the wine folder, after the staging patches are applied. I do not know if, or when the distro binaries will get this patch, but I can attest to it solving the problem for WoW. Played almost 3 hours, after applying the patch, and compiling.

Ubuntu/debian distros did not get this patch, so the released wine-staging-5.7 is borked for those that do not compile themselves.

Seems to work fine with that patch.

"Fine" being relative, cos i still have the odd/random crash at times, but i mostly think that is due to nVidia shitty drivers :)

Can log in, but once the character is picked, and the screen shows the inn at boralus, everything freezes.

Same with me. 5.7 is borked.

I experienced also that when i updated my wineprefix with "wineboot -u" it completely bugged out, so i actually had to recreate my whole prefix and copy the WoW installation over and do a new install of battle.net and check the wow installation.

Back with 5.6 again now, and it works as it used to, so something has messed WoW up :(

Something with 5.7 is messed up... not that WoW is messed up NOW that i am back to 5.6.

Just to clarify.. sorry :)

Well for me the game doesn't start at all.
The console prints
fixme:d3d12_command_queue_GetPrivateData: iface 0x7d81a9f0, guid {000000f0-0000-000d-f0a9-817d00000000}, data_size 0x22f538, data 0x22f500 stub!fixme:d3d12_command_queue_SetPrivateData: iface 0x7d81a9f0, guid {000000f0-0000-000d-f0a9-817d00000000}, data_size 16, data 0x22f500 stub!
wine: Read access denied for device L"\\??\\Z:\\", FS volume label and serial are not available.
0009:err:seh:setup_exception stack overflow 2512 bytes in thread 0009 eip 000000007bcbff85 esp 0000000000130c40 stack 0x130000-0x131000-0x230000

and the game hangs before showing the login screen.

Yeah, not sure whats up with 5.7 tbh, but there was some changes that required a rework of the fsync patches.

When i tried to upgrade my wineprefix (wineboot -u), it asked to download a new wine-mono, and upon upgrading this, it all went tits up from there. Replacing the "system.reg" file with one from a recent/fresh wineprefix, the upgrade was no problem. This to me seems to indicate some sort of old registry settings lingering causing wine-mono to go bonkers.

That in itself should really not have anything to do with WoW. The first two lines you posted Chiro, should be of no concern... The first one is a "fixme" and not breaking anything, and the second one is just wine telling you that you do not have access to linux / folder, since "Z" is mapped to / which normally really should not be accessible from wine. My oppinion, but it seems to be the default, and you cannot remove it...
The last one is the crash i guess, but it does not say much to the cause of it.

I can log in just fine, but as soon as the character appears in game, it completely freezes and i have to kill the wine process.

I see that wine-staging is not yet posted on any repository although it was compiled 21 hours ago.. not sure if that is just a minor delay, or if something is up. I do HOPE that someone has detected something, and is perhaps working on some fix before it gets posted, but if not, i guess this error is bound to be more common once it will be available to those that do not self-compile :)

This one is also interesting... github.com/Frogging-Family/wine-tkg-git/issues/28

Version 1.5.5 of dxvk seems to have solved the problem. Before i'm using 1.5.4. winetricks -f dxvk on wow wineprefix solved this issue

I am using 1.5.5 + git, but i have nVidia, and this does not work for me. Wine-staging (wined3d) with d3d11legacy does not work either. Will continue testing some more tonight.

Apparently something is up i guess...
eu.forums.blizzard.com/en/wow/t/wtf-just-happened/134776/4
www.reddit.com/r/wow/comments/flkh93/anyone_else_just_have_wow_unexpectedly_force_close/

So might not AT ALL be wine related. Especially if you compare amount of players not using Win10 (or even Mac), i am not surprised there is not a torrent of posts on this here :)

Oh.. Interesting.

The two wine versions i tested was both compiled with "-march=native" gcc optimization. Recompiled wine without this, and i can play again (atleast it looks like it so far).

I had this happen one time before aswell a while back (dont remember), but enabled this optimization a few versions later, and it has worked fine after that... until last night it seems. I will not give it a 100% solution yet, cos i have not been playing for any length of time tbh, but comparing to instantly crashing 100% of the time its a clear improvement. I do sometimes get that Error #132 when exiting the game tho.

Program: C:\Program Files (x86)\World of Warcraft\_retail_\Wow.exe
ProcessID: 308
ThreadID: 309
Exception: ACCESS_VIOLATION

The instruction at "0x00007f3b6316e048" referenced memory at "0x0000000000000018".
The memory could not be "written".

Would be interesting to see if anyone else that struggles are using this gcc optimization. It is not enabled when using pre-built distro packages tho, so it is probably only for those compiling themselves or using a sourcebased distro like Arch/Gentoo or the likes.

Hi,

I was experiencing random crashes (usually after a few seconds or minutes in game), and graphic issues (pink sky in Mechagon for example) since last friday evening.
Same happened when 8.3 and 8.2 patch were released, and issues fixed themselves at the weekly maintenance the week after without me doing anything, so I always thought this was an issue on Blizzard side.

I recompiled wine-staging 5.4 with -march=x86-64 instead of -march=skylake (and -march=broadwell before): this seems to have fixed those issues. Thank you :)

I'm running wine-staging 5.4 with dxvk 1.5.5, gentoo kernel 5.4.15 and nvidia drivers 440.59 (I was running wine-staging 5.1 with dxvk 1.5.3, same applies)

Regards

there is also this
us.forums.blizzard.com/en/wow/t/lockups-since-83-nvidia-gpus-windows-thread/430491

i was having the problems described there after the patch on yesterday. most of the time the game froze instantly on login, sometimes only after i open the character or collections (mounts, transmogs) panel. i have had problems with the latter previously (streaming error) for which downloading the cache of a windows install fixed it. now however i got no error, the game just froze and having an empty cache or populated one made no difference

i tried with and without dxvk 1.5.3, 1.5.5 and the new 1.6, with dx11 set to legacy and not, nvidia-drivers 440.59 and 440.64
what finally worked was compiling wine-staging 5.4 without -march=native, as you described

Yeah, depending on what processor you are compiling on when using -march=native, i guess certain optimizations might change something that the latest WoW patch needs from wine. Not all optimizations are good i guess.

Just for reference, it would be interesting to see what processors (and thus optimization flags) might have problems with this. I use a Intel 8700K (Coffee Lake) processor, and the flag "-march=native" enables the following according to gcc:

So doing this:
gcc -E -v - &1 | grep cc1

/usr/lib/gcc/x86_64-linux-gnu/9/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu - -mtune=generic -march=x86-64 -fasynchronous-unwind-tables -fstack-protector-strong -Wformat -Wformat-security

gcc -march=native -E -v - &1 | grep cc1

/usr/lib/gcc/x86_64-linux-gnu/9/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu - -march=skylake -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -msgx -mbmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b -mno-waitpkg -mno-cldemote -mno-ptwrite --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=12288 -mtune=skylake -fasynchronous-unwind-tables -fstack-protector-strong -Wformat -Wformat-security

So, kinda enables a few optimization, especially avx ones it seem. Maybe one could tinker with this to figure out what would be the case, but quite frankly it is not worth it since it (afaik) only affects WoW. + that most ppl use pre-compiled distro provided packages anyway, and those are just optimized as "-march=x86-64" anyway.

If anyone else have any experiences with this, perhaps using a different processor - AMD - without problems, it would be interesting to know.

One other thing too would ofc be GCC version having something to do with this, and also since wine uses MinGW64 to compile by default it would also be worth checking out.

For ref. i use Ubuntu 18.04:
gcc version 9.2.1 20191102 (Ubuntu 9.2.1-17ubuntu1~18.04.1)
gcc-mingw-w64-x86-64 8.3.0-6ubuntu1~18.04.1+21.1build2

I tried with different settings and different drivers (dxkv, vkd3d with dx12, and so on ...). Only by compiling with -march = x86-64 I solved it.
In fact, the problem appears to be in the flags set by -march = skylake. So it shouldn't be a GPU problem. In fact I have an RX580 (AMD) and an Intel i5-6600k processor (skylake) and I have the same problem.

I am using gentoo
5.5.11 gentoo patched kernel
gcc version 9.3.0
wine-staging-5.4

Wow classic doesn't seem to suffer from the same problem. But I only tried for about ten minutes.

I played earlier today around 4pm GMT, and there was no issues, but when i logged on around 7pm GMT there was a small patch downloaded from the Battle.net launcher, and i was immediately met with a crash when logging in.

I have tried rolling back graphics drivers (nVidia), Wine (as i said, worked earlier today with wine-staging-5.4), even kernel. Switched to vkd3d for D3D12, same issue. Removed dxvk completely and ran with d3d11legacy and Wine, same issue.

Now to the rather interesting part: I had issues on my Win10 box aswell, until i upgraded the drivers to the latest WHQL. That box also uses a nVidia card. Ofc any driver fixes for WoW directly in Windows will not carry over to Linux, so it is somewhat of a head-scratcher.

Everyone else happily playing WoW tonight with an nVidia RTX2070/GTX970? :)

Same for me. Played without problem before the small patch. Now i can play only with without dxvk using direct12, with poor performance (unplayable).
wine-staging-5.4, AMD RX580, kernel 5.5.10 (i'm using AMDGPU driver).

When I run either retail or classic, from commandline script, with winecfg set to windows 10, I can not connect, and blizzard pops an error message. If I change the version to Windows 7, then it connects and loads the realm and I can log on with any and all of my characters. I do not use the battle.net app to launch, since I have to run with dxvk.

Hi, I also run from command line with dxvk, winecfg set to Windows 10 and don't have this kind of issue. If it can help, my command line looks like:

cd /mnt/ntfs/wow/folder/_retail && env WINEPREFIX=/home/me/.winedxvk DXVK_HUD=0 DXVK_LOG_LEVEL=none WINEDEBUG=-all STAGING_SHARED_MEMORY=1 STAGING_WRITECOPY=1 __GL_THREADED_OPTIMIZATIONS=1 DXVK_STATE_CACHE_PATH=/home/me/tmp/dxvk_state_cache wine64 Wow.exe -d3d11

The wine prefix was created from scratch using wine 5.0 staging (I'm running on Gentoo), and then running dxvk 1.5.3 setup on it.

thanks for the information. I tried your command line, and it made on difference. I can run wine as windows 7 and play all day long, but if I change to windows 10 in winecfg, then I get the bliz51914003 you have been disconnected, as soon as I put in my password. Nothing on blizzards tech support has this specific error number. I run fedora 31, with nvidia gtx 1050. I have also tried this from my work computer, also fedora 31, but running AMD 8570 graphics card. Neither one can log in, if winecfg set to windows 10, but work fine with winecfg set to windows 7. If others using fedora have this problem let me know. I self compile, but also tried with the distro version of wine-staging, and it does same thing.

I have the exact same issue running with Ubuntu, so it is not a "fedora issue".

It has been like that for quite a while tho (year+ i think). Maybe some library override or whatnot that is set? I only have the DXVK (d3d) dll-overrides set, but maybe others that can log in uses something more? msvcrt or whatever that is different from Win7 Win10?

Good Day,

I use Fedora 30 and currently do not update beyond wine 4.17 as I have an issue with the keyboard beyond that version. Just note I use Wine from Fedora repos and not any other.

The problem I have is that I have to press most keys a second time before they activate ie. Press W to move forward does nothing until I release and press again.

Anyone have a similar issue ?

Regards

are you running latest wow client, and do you have wayland running? You might consider looking in the 8.2.5 or 8.3.0 for others that may have the same problem. i run fedora 31, with nvidia gtx 970. I have no issues with keypress. you might also test with no addons running, in case one of them is the problem. blizzard has updated the client, and some people have had numerous problems because of that.

Yeah, i have had this happen.. and might possibly still be like it, but have not re-checked if its the case, since the solution (atleast for me) was to tick the box in winecfg (under Graphics) saying "Automatically capture the mouse in full-screen windows".

I have posted about this on bugzilla, and i believe this has something to do with some "raw-input patchset" that staging uses.

Lemme know if it fixes the issue for you tho :)

If anyone using a Ubuntu-based distro and would like to test out pre-built packages for libvkd3d and wine to test D3D12 in World of Warcraft you can test my repo's here:

libvkd3d:
launchpad.net/~cybermax-dexter/+archive/ubuntu/vkd3d
Install:
sudo add-apt-repository ppa:cybermax-dexter/vkd3d
sudo apt-get update

Then add custom wine with additional patches for WoW:
build.opensuse.org/package/show/home:SveSop/wine-staging
Install:
sudo dpkg --add-architecture i386
wget -qO - download.opensuse.org/repositories/home:/SveSop/xUbuntu_18.04/Release.key | sudo apt-key add -
sudo sh -c "echo 'deb download.opensuse.org/repositories/home:/SveSop/xUbuntu_18.04/ ./' >> /etc/apt/sources.list.d/Wine.list"
sudo apt update
sudo apt install winehq-staging

The wine-staging package is built as a higher build-version than the default winehq version, so adding the repo it should upgrade the winehq packages when doing a "sudo apt upgrade". These are built for Ubuntu 18.04 (Bionic), 19.04 (Disco) and 19.10 (Eoan).

Q: Will you build for other distro's? A: Nope, although wine is built for Debian 10, i do not have a patched libvkd3d library for that.
Q: Should i report bugs on WineHQ forums? A: No. This is experimental, and NOT in any way supported or endorsed by WineHQ dev team.
Q: Can i comment here, and ask why this does not work for me? A: Sure. I will do my best to see if i can answer it :)

Probably not too much interest in this i guess, but nevertheless, all testing is both interesting and helpful in the long run - atleast for me :)

Hello,

solution was, to remove battlemet-cache which was written by wine with battlenet cache, which was written by Windows. I used the one stored on github, some time ago.

Hello,

i had issues logging in since Saturday 20191109. Even with ucrtbase Native/Builtin and ms-win-api-ms-win-crt-private-l1-1-0.d Native/Builtin there was no way to login. Wine says:

0123:fixme:kernelbase:AppPolicyGetThreadInitializationType FFFFFFFA, 00FCFF00
016b:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFA, 0032FE9C

after that, debugging stops, when battlenet calls the login screen to open.

while on Satrday it was complainig over BGcryp not using right algorithm, after the login screen was opened, which is not any longer reproducible.
Maybe so has found a solution?

Same here since yesterday.
Battle.net App has been updated last week. Until yesterday, it only starts with a white background for me. Since yesterday, start fails with the same message.

Game start is fine, I think until there is also an update which has to be installed throug Battle.net App :-/.

Anyone else? Maybe with a solution?

I have same issue.

My temporary fix for these is keep drive_c/Program Files (x86)/Battle.net/Battle.net.11512 and copy in a safe place. Delete other versions of this subdirectory.

This procedure always before start Launcher.

Launcher versions > 11512 starts in a white screen.

Launcher

Launcher 11512 (or smaller) runs OK

Regards

In my case, applying the fix listed in "Blizzard Battle.net App" in AppDB worked (through winecfg, set api-ms-win-crt-private-l1-1-0 and ucrtbase libraries to native first)

Thanks. Your research and efforts are appreciated. I am running wine 4.14 staging, because I have an issue with crash132 error, with version greater the 4.14 of wine staging, but only on retail, not classic. it is not dxvk or vkd3d that cause the problem, so just staying with 4.14. Once battle.net did the update, and it crashed, I thought I was screwed. You have made the game playable, and I can keep the updates working. Just curious, have you been able to run twitch desktop app to update addons? I used to have it working, and have forgotten the steps I used.

I'm running 4.14 staging and did not try versions above yet, so not sure about this crash132 error (only playing retail, I already played too much "classic" during vanilla). I also had one single battle.net crash after applying the fix for those 2 dll, none afterwards.

I used to run my own zsh/wget/curl/awk script to fetch addons updates, but since 2 weeks I have issues with cloudflare protection on website where I was getting them (some issue with cookies management I think, since I don't manage it at all in my script). I thus recently tried to install twitch desktop app, which succeeded, but I've been unable to make twitch desktop app detect my WoW folder, neither automatically or manually. For now I did not investigate further about twitch desktop app

I have a link (with ln -s) named 'World of Warcraft' (without quotes) pointing, in my case, to:

/home/krovikan/.wine/drive_c/Program Files (x86)/World of Warcraft/

Thanks to this link I can manage everyday WoW addons from functional Twitch app (I have a wineprefix only for Twitch).

I somehow killed bnet trying to roll back 5.7, so thought was screwed when new patch of WoW arrived.
Amazingly, WoW launched bnet, and the behind-the-scenes bits managed to update WoW anyway.
The annoying bit was, with no batnet window up, I had no idea how far it had progressed, until a small pop-up window announcing 'playable' appeared.
Still had to wait a bit, since I've never felt safe launching WoW while batnet was 'reclaiming disk space' - not a good spot for something to crash.

The game worked fine yesterday (and has for months now). Today, right after applying Linux patches in the usual way, I get this when trying to start the Blizzard app launcher:

Unhandled exception: unimplemented function api-ms-win-crt-private-l1-1-0.d._o_getenv called in 32-bit code (0x7b43e11c).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:7b43e11c ESP:165ff7a4 EBP:165ff828 EFLAGS:00000212( - -- I -A- - )
EAX:7b42a541 EBX:00000004 ECX:165ff7d0 EDX:165ff854
ESI:75f4db40 EDI:165ffa3c
Stack dump:
0x165ff7a4: ffffe86d ff676980 ffffffff 079b8000
0x165ff7b4: ffffe86d 7bd26fa4 80000100 00000001
0x165ff7c4: 00000000 7b43e11c 00000002 75f4db40
0x165ff7d4: 75f50f00 00110060 00000000 00000005
0x165ff7e4: 00000000 00110060 00000000 00000005
0x165ff7f4: 00000000 ff676980 00000000 00000000
Backtrace:
=>0 0x7b43e11c GetFirmwareEnvironmentVariableW+0x13c() in kernel32 (0x165ff828)
1 0x75f4db27 in api-ms-win-crt-private-l1-1-0.d (+0xdb26) (0x165ff868)
2 0x75f4b799 in api-ms-win-crt-private-l1-1-0.d (+0xb798) (0x165ff884)
3 0x162db7c0 EntryPoint+0xffffffff() in d3dcompiler_47 (0x165ff884)
4 0x0f03d7aa EntryPoint+0xffffffff() in libglesv2 (0x165ffabc)
5 0x0f024b8a EntryPoint+0xffffffff() in libglesv2 (0x165ffc48)
6 0x0f039de5 EntryPoint+0xffffffff() in libglesv2 (0x165ffd70)
7 0x0f03bf03 EntryPoint+0xffffffff() in libglesv2 (0x165ffda8)
8 0x0eff5f47 EntryPoint+0xffffffff() in libglesv2 (0x165ffdb0)
9 0x0eff74ff EntryPoint+0xffffffff() in libglesv2 (0x165ffdf4)
10 0x0eff80b6 EntryPoint+0xffffffff() in libglesv2 (0x165ffe08)
11 0x0eff7015 EntryPoint+0xffffffff() in libglesv2 (0x165ffe18)
12 0x0f177d1f EntryPoint+0xffffffff() in libglesv2 (0x165ffe38)
13 0x7bcbc5cb NtGetCurrentProcessorNumber+0x2d4a() in ntdll (0x165ffed8)
14 0x7bcaaac8 call_thread_func_wrapper+0xb() in ntdll (0x165ffeec)
15 0x7bcae320 RtlCaptureStackBackTrace+0x1ff() in ntdll (0x165fffdc)
16 0x7bcaaaba call_thread_exit_func+0x31() in ntdll (0x165fffec)
0x7b43e11c GetFirmwareEnvironmentVariableW+0x13c in kernel32: addl $12,%esp

I don't _think_ it downloaded a new app launcher version, but it's hard to be sure.

I just applied some OS upgrades. It must have included a Wine update because I saw winecfg fire when I started WoW. I had problems after the latest WoW expansion similar to what others mentioned -- solid colors, etc. I found that I was able to work around it by switching monitor between "Default" and "Monitor 1" -- switching either direction worked. It seemed that subsequent Wine updates made it less frequent and eventually fixed it. I'm currently on "wine-3.20 (Staging)" and the problem is back, worse than ever.

Besides the solid blocks I have wild flashes of color constantly. Switching monitors does *not* work around it this time. I have a screenshot, and will file a bug so I can post if if that will help: gunmayhem.io/

Hi,

For those who like me can not login since yesterday (I was stuck at loading realm list, and getting a WOW51900328 error after some time), it seems to be linked to TTL on IPv4 stack:
us.forums.blizzard.com/en/wow/t/linux-users-unable-to-log-in-wow51900328-329-error-after-logging-in/292402/176
eu.forums.blizzard.com/fr/wow/t/bloquer-sur-connexion-au-serveur-de-jeu-wow51900328/21729/53

Running a "echo 128 > /proc/sys/net/ipv4/ip_default_ttl" allowed me to login and play again.

Regards,

Thanks, that worked for me too! (classic wow).
However you can't just echo to that file unless you're root (which I hope you're not).
Use "tee" to do it instead"

echo 128 | sudo tee /proc/sys/net/ipv4/ip_default_ttl

For anyone curious, the default value (at least on my system) was 64. I'm super happy to be changing a low level network stack TTL value in order to play wow though...what could possibly go wrong...

WoW also works with IPV6 without changing TTL.

Afaik this problem has to do with the recent DDOS struggles Blizzard have had.

I recently had to rebuild antiX Linux Core and reinstall Wow on an SSD. Needless to say I'd forgotten what a pain the arse it can be struggling to remember all the things you used to take for granted when installing wine for WoW. Like install gnutls-bin and winbind (to reduce non-fatal errors).

I was surprised to discover that I did need to set winecfg to Windows 10 now (Windows 7 did not work for me) the Staging CSMT (deprecated) toggle didn't appear to do anything so I left it off. :D

Not sure when it happened, but i might suspect WoW 8.2..

If you look in the WoW/_retail_/Logs folder, and check the "gx.log" (WoW graphics driver log), you should notice this little tidbit:

8/13 19:47:41.281 Detected NvAPI and checking if it's valid...
8/13 19:47:41.354 Created 11.1 Device
8/13 19:47:41.357 ConstantBufferOffsetting Support: true
8/13 19:47:41.361 SetMaximumFrameLatency set: 2
8/13 19:47:41.364 Wine detected, skipping NvAPI/ADL loading

This is (imo) actually interesting news, cos it show clearly that Blizzard devs are aware that ppl play WoW under Linux/Wine, and they have made a workaround due to the troublesome (with some functions atleast) NvAPI for those with nVidia cards.

Interesting, as i just noticed it a few days ago.

"Are aware" was kinda bad wording, as they have ofc been aware quite some time... But i meant more like "acknowledging" that ppl do so, and make tweaks to help out :)

Blizzard was always aware of wine. Just look at your crash log in your wow folder.
It shows Linux instead of wine when you look at platform.

After starting up the client and selecting a language/region, the game immediately hangs before opening. I receive the follow (shorted) output:

002b:fixme:msctf:ThreadMgrSource_AdviseSink (000000000363E2D0) Unhandled Sink: {ea1ea136-19df-11d7-a6d2-00065b84435c}
info: Game: Wow.exe
info: DXVK: v1.3.1
warn: OpenVR: Failed to locate module
...
...
info: DXGI: NvAPI workaround enabled, reporting AMD GPU
002b:err:seh:setup_exception stack overflow 48 bytes in thread 002b eip 000000007bcb4c04 esp 00000000001415e0 stack 0x140000-0x141000-0x240000

Any clues what it might be? I'm using wine 4.12.1, DXVKv1.3.1, and have seemingly set DXVK_FAKE_DX10_SUPPORT=1 correctly.

You do not need the DXVK fake variable at all. You also need to make sure, that your wine is set to windows 7 or windows 10, and that you select dx11 in the game.

I've tried setting wine to windows 7 and windows 10 and neither changed anything. I also set the game to use dx11 in the config file, but that didn't fix it either. Any other ideas?

did you also remove the fake dx10? it is no longer needed. Are you launching from battle.net or from the command line I have in the how to on here? I recommend the command line.

forgot to ask, are you running the staging version of wine? that is required to make WoW work.

Aha. That's what it was. Upgrading to wine-staging fixed it. Thanks a ton, man.

Glad to help. Have fun.

Currect status "Garbage" is not correct. Wow 8.2.0 works properly with Nvidia + DXVK.

I can't submit test result since I didn't try with vanilla wine-staging, so I want to writeup at least a positive comment.
Im using:
Wow 8.2.0 30993 (Jul2 2019)
kernel 5.0.0
nvidia driver 430.26
wine-tkg-staging-esync-vkd3d-opt-git-4.10.r9.g3bba6934
In dx12 tests:vkd3d git b59b6b87 (2019-06-18) + d3d12_command_list_invalidate_bindings patch
In dxvk tests:dxvk 1.3.1

Other environment that doesn't matter I think:
-Debian 10+experimental random mix
-Non-compositing window manager on X11 (awesome, gnome-flashback)

I tried with gtx770 and gtx1060, resuslts are similar.

Dxvk-based with dx12: fps is fine, but entering New zone - Nazjatar - hangs.
Wine-dx11 with "DirectX11 legacy" selected in Wow: fps is sometimes playable (5-30 dropping quality settings doesn't help much).
Wine-dx11 with "DirectX11" selected in Wow: fps is always unplayable, even flags at login screen are not smooth.
dxvk-dx11 with "DirectX11 legacy" selected in Wow: typical playable wine+wow fps (30-100 at MAX graphics quality).
dxvk-dx11 with "DirectX11" selected in Wow: similar, maybe even a bit faster.

So from my expereince with dxvk-dx11 wow 8.2.0 has nearly the same playability as 8.0-8.1. So, nothing similar to "Garbage" at least with above-mentioned software versions.

I didn't test laucnhing from Battle.net app, I'm using it only for updating.

Confirmed working here too with winehq-staging 4.12.1~buster, nvidia drivers 418.74, kernel 4.19.37-6 (debian), and dxvk 1.3.1

This is the error, if I use the compile script from the how to. I have had to add --without-mingw to the configure options to get it to compile, and it seems to run WoW fine. Does anyone else have issues with mingw and fedora 30. if not, then can you tell me what might be different?

collect2: fatal error: ld terminated with signal 6 [Aborted], core dumped
compilation terminated.
free(): invalid next size (normal)
winegcc: x86_64-w64-mingw32-gcc failed
make[1]: *** [Makefile:1558: comctl32_test-stripped.exe] Error 2
make[1]: Leaving directory '/home/steve/wine-dirs/wine64-build/dlls/comctl32/tests'
make: *** [Makefile:8392: dlls/comctl32/tests] Error 2

Currently running:
Fedora 29: 5.1.11-200.fc29.x86_64
nvidia 430.26 (akmod)
Wine: 4.11 staging - built from git
vkd3d built from git

(git builds essentially as listed above)
(launch script essentially as listed above)

d3d12 works fine until I land a toon in naz'jatar, then I get WoW locking up (no sound, mouse moves but cannot click the interface) -- No wow errors and I've yet to drop a debug log for it. Flipping to d3d11 at character selection and logging back into the stuck toon allowed me to hearth back out -- (didn't have the library overrides for d3d11 so the framerate was terrible, but it didn't hang)

only error I see at the moment that is directly related is in dmesg:

NVRM: Xid (PCI:0000:01:00): 31, Ch 00000056, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_T1_7 faulted @ 0x0_00000000. Fault is of type FAULT_PDE ACCESS_TYPE_READ
NVRM: Xid (PCI:0000:01:00): 31, Ch 00000056, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_T1_2 faulted @ 0x0_00000000. Fault is of type FAULT_PDE ACCESS_TYPE_READ

I've got same error on nvidia gtx770 сard
Wow 8.2.0 30993 (Jul2 2019)
kernel 5.0.0
nvidia driver 430.26
wine-tkg-staging-esync-vkd3d-opt-git-4.10.r9.g3bba6934
vkd3d git b59b6b87 (2019-06-18) + d3d12_command_list_invalidate_bindings patch that prevents wow flickering.

On entering naz'jatar picture freezes, however mouse& sound are still working. Window manager reacts to its key bindings with several seconds timeout. (Second seat with second nvidia card is extremely slowed down too during this time).

NVRM: Xid (PCI:0000:03:00): 31, Ch 00000014, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_L1_0 faulted @ 0x0_00000000. Fault is of type FAULT_PDE ACCESS_TYPE_READ

I've coollected vkd3d traces near the hang (10 MB, several seconds):
gist.githubusercontent.com/galkinvv/649a19ce96550d7199f25c22ee7ec0f3/raw/d7745c14be772ab9e3b38b20b9b52fed9de5d1e7/wow82_vkd3d_hang_on_nvidia.log

I think that the investigation starting point is near '1562358506.895769 warn:d3d12_command_queue_Wait: Failed to submit wait operation, vr -4.'

With the correct library overrides in wine its playable in Legacy D3D11 mode. == all areas.

Fedora just dropped wine-staging 4.12 -- I'll check the update and try a rebuild since I'm showing 4.11 from git.
_ also - theres a vulkan-mesa update that may play in as well....

I'll quietly point out that to build vkd3d from git you need to have a copy of widl to generate certain files - this is typically in your $wineinstallpath/bin directory - - you need to add this to your path before running make -

In case it happens to anyone else, the game causes a graphics crash and requires me to reboot my machine on DX12 with VKD3D shortly after selecting your character and loading into the game. I don't see any other bug reports about it so I'm assuming it's an AMD RADV issue (I'm using an RX580). Falling back to DX11 with DXVK allows me to log in and play the game.

It also causes hangups/crashes on NVIDIA cards in the new zones. There is something in dmesg (MMU Fault: ENGINE GRAPHICS GPCCLIENT_T1_1 faulted) and the whole system slows down until I do wineserver -k

DX11 works fine though

Alright, managed to get the game to install in a clean prefix by booting the stock kernel instead of linux-hardened. There is definitely a bug in either vkd3d or amdgpu because if I try to use DX12 I get a GPU crash with journalctl flooded with amdgpu_ioctl errors. DX11 runs fine.

Is anyone having an issue where the Battlenet app hangs on "Checking residency" when trying to install the game? It does not happen for the WoW classic client but it happens 100% of the time for the retail WoW client and no workarounds have worked for me. I've tried in several fresh prefixes as well.

With wine-staging 4.10 (TkG) addons take 3x~4x as much CPU time compared to with 4.8. I think it has to do with the tinkering they are doing with GetTickCount. I'm using AddonUsage addon to check it together with ingame CPU profiling. I noticed first in raid. But just standing in Boralus with staging 4.10 gives me around 33 ms/s addon usage. While with staging 4.8 I'm around 9 ms/s.

(4.9 + bugs.winehq.org/attachment.cgi?id=64567&action=diff was even slightly better then 4.8, with 8 ms/s)

However, since I don't have regular wine staging (I'm using TkG builds), I'll first have to get normal staging builds before I can bug report it. Arch doesn't have a regular wine-staging 4.10 build yet, so I can't compare regular 4.8 to 4.10 yet. So I'm asking here: Has anyone else noticed this already? Or is there someone that can test the difference between 4.8 and 4.10 in terms of Addon CPU usage?

Dox

PS: I tested 4.10 TkG with and without that monotic patch described in bugs.winehq.org/show_bug.cgi?id=47332 so that is not it.

PS2: With regular wine-staging 4.8 I have 43 ms/s. So I already know something is different with TkG builds. And I'll post my ms/s with 4.10 when it becomes available in ARch.

Ok, was able to build plain Wine-Staging 4.10. Seems that gives me around 43ms/s as well. Plain staging 4.8 and 4.10 give around the same numbers. So this might not affect normal staging builds since that already has high CPU usage. TkGs builds on the other hand gives around 8ms/s with 4.9, and 33 ms/s with 4.10. So I had to find what the culprit was.

After researching, the solution was reverting the moving of GetTickCount to kernel : github.com/wine-mirror/wine/commit/13e11d3fcbcf8790e031c4bc52f5f550b1377b3b#diff-08a473061bc11d2b62cf21997e28877b

And reapplying: bugs.winehq.org/attachment.cgi?id=64567&action=diff

I now have below 8 ms/s again for addon usage on 4.10. So even though it might be a correct solution, and perhaps unnoticable on normal staging builds, it seems way less CPU efficient for WoW.

Narrowed it down to the fact that 13e11d actually copied code to dlls/kernel32 and the monotonic patch had to be adjusted to also patch there. After this was done I was able to log in and see even less CPU usage, namely: 6 ms/s.

However, now I'm having some issues getting it to work with dxvk. Crashing with the dreaded 132. Can log in with vkd3d though.

Switched nvidia driver and I was able to log in again. Raiding is much better now with 4.10 + Monotonic patch. Addon usage during raid combat doesn't go above 30 ms/s, and my fps stays at 60 fps on 2560x1440 with my 970. And in other games you notice the difference aswell. The movement for GetTickCount to kernel32 and forcing CLOCK_MONOTONIC is amazing.

If you want to test it yourselves, add the 2 CLOCK_MONOTONIC patches that you can find here to your own builds: github.com/Tk-Glitch/PKGBUILDS/tree/master/wine-tkg-git/wine-tkg-patches

I was having issues with self compiled wine, until I added --without-mingw to the configure command. Everything compiles and runs, including battle.net and twitch. I might as well be playing on windows, from the performance I get and the way it works. I am also using vkd3d to run wow in DX12 and having no problems or lockups or crashes. I am wondering if mingw on fedora 30 has not been updated, as the compile always fails, if I enable mingw. will continue testing, but at least I can play wow and update my addons.

My latest results were with vanilla Wine Staging from the WineHQ Ubuntu repository. After more poking (with repeated resets to a clean install thanks to ZFS snapshots) I learned the following:

1. Setting the default version of Windows to Windows 10 lets the game start, but the framerate is unusable.

2. Subsequently setting the graphics API to "DirectX 11 Legacy" gives me the expected framerates.

Random nits I noted last time I tried WoW under Wine appear to be corrected - I don't crash when I bring up collections, for instance. I'll post another full test after I've had an opportunity to play through various things - travel, battlegrounds, etc.

You might consider vkd3d and install vulkan. I am running dx12 in wow, with decent frames, and since wine also builds vkd3d, it would just take install libvkd3d and the vulkan drivers for nvidia.

Just recently discharged from the hospital, after a blood clot broke loose in my lung, and on top of that I had pnuemonia as well. I am on the road to recovery, and would love to be able to play wow, but something has changed and I have no idea what. Using my own notes, I have been able to compile wine, vkd3d and all the relevant software. I have installed vulkan and libvkd3d, and can run the battle.net app, but whether i launch from the app or from the shortcut I made, it fails with the error 132, and I have not quite recovered to the point I can spend hours trying to track down the problem. I run Fedora 30, GTX 970, AMD fx8350. Latest self compiled wine, and vkd3d. Are there any winetricks installs that I need to run, settings possibly in my x-org or other graphics issues?

Try running 'winetricks vcrun2017' seemed to help with battle.net passing control to the game.

Have you tried wine-staging-4.8?

There has been some changes with >4.8, and with 4.9 release yesterday i don't seem to be able to start WoW at all atm.

Still investigating tho, but WoW works fine with 4.8 for me atleast.
Just since you mention "latest self compiled wine", there is also some problems if you compile without mingw-w64 aswell, although a few bugs have been weeded out.

4.8 would be fine, has anyone instructions, how to downgrade/rollback on Ubuntu?

Just tried "sudo apt-get install wine-staging-i386=4.8~bionic wine-staging-amd64=4.8~bionic"
which runs fine so far, but after that, there are missing important things like wineserver etc.

You should consider clearing all the packages as you have probably mixed packages from different versions.

First do "dpkg -l | grep -i wine

Then do "sudo apt purge" for all the packages with version 4-9~bionic and 4-8~bionic. You can type all the packages on one line. eg. "sudo apt purge winehq-staging wine-staging-amd64...." and so on.

Then you can install again with "sudo apt install winehq-staging=4.8~bionic"

The key being that the meta package is called winehq-staging and not just wine-staging :)

Hopefully that will fix ya :)

You made my day buddy, thanks a lot!!

My fault was the missing winehq-staging :-). Rest was already fine.
Little info:
"sudo apt install winehq-staging=4.8~bionic"
gave me:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
winehq-staging : Hängt ab von: wine-staging (= 4.8~bionic)
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.

whats telling me, that winehq-staging depends on some other things.

"sudo apt install winehq-staging=4.8~bionic wine-staging=4.8~bionic wine-staging-amd64=4.8~bionic wine-staging-i386=4.8~bionic"
did the trick for me.

Now with 4.8 everything is fine. Thanks again!

Great :)

Those that self-compile can add a patch to wine-staging-4.9.
bugs.winehq.org/attachment.cgi?id=64567&action=diff

So hopefully this will be fixed by 4.10 for those using precompiled packages :)

source.winehq.org/git/wine.git/commitdiff/13e11d3fcbcf8790e031c4bc52f5f550b1377b3b

In case anyone want to test GIT vs. this bug.

Reverting to wine-staging 4.8 worked for me.
Archlinux + AMDGPU vulkan-radeon and DXVK 1.2 on RX580 with wine-staging 4.8

Wow is running beautifully including the Battle.net launcher. In order to downgrade a package from the official repos, you can find it and download it from archive.archlinux.org and use pacman -U or you can just use the URL its self by with:
sudo pacman -U archive.archlinux.org/packages/w/wine-staging/wine-staging-4.8-1-x86_64.pkg.tar.xz

It shouldn't be necessary to do anything to your wine bottle, but you can always generate a new one if it suits you. I do, but it may just be a touch of OCD in my case, just don't forget to run if you do make a new bottle:
setup_dxvk install
to make sure you're mapped to Vulkan

Hey, sorry to bug you, but you appear to have the exact same setup as me (RX580, Arch Linux) so I figured I'd ask. Are you running into any trouble getting the Battlenet app to install WoW? I've tried on several fresh prefixes and no matter what I can't get it to get past "Checking residency". It seems to be an issue with Agent.exe crashing/hanging but other than an inactive bug thread about being unable to install games, I can't find any other information about it. I've tried wine-staging 4.8 and 4.11 as well as Lutris.

Thanks!

funny you mentioned mingw, as when i started compiling without-mingw everything started working as expected.

I have exactly the same problem.
Tried wine 4.9, wine-staging 4.9 and wine-tkg-git (4.9) and I'm unable to launch the game.
As soon as the command is executed the game "starts" with a black screen. A couple of seconds later there is a crash popup showing up.

info: DXGI: NvAPI workaround enabled, reporting AMD GPU
0xC0000096 (PRIV_INSTRUCTION) at 000000007b6c36cd : error 132: ERROR #132 (0x85100084) Fatal exception!
info: DXGI: NvAPI workaround enabled, reporting AMD GP


My system:
Archlinux (5.1.4-arch1-1-ARCH)
Nvidia Gforce 1060 6GB
Latest nvidia drivers (430.14-4)
Latest dxvk (1.2.1-0)
Winecfg:
- Windows 10
- Enable VAAPI as backend for DXVA2 GPU decoding
- Overwrites:
--nvapi (disabled)
--nvapi64 (disabled)
--d3d12 (disabled)

downgrade to wine-staging 4.8 - i posted instruc a few posts up if you need to know how. works great (except that I'm using all AMD) not that I think it matters in this case.

Same here.

WIne-staging 4.9 with overrides for DXVK, winever 8.1, openSUSE Leap 15.0.
I try use Snapper to rollback to 4.7 but I have wine version errors. I update again to 4.9 and wait a solution.

Error log:

World of WarCraft: Retail Build (build 29981)

Exe: Z:\home\krovikan\.wine\drive_c\Program Files (x86)\World of Warcraft\_retail_\Wow.exe
Command: "Z:\home\krovikan\.wine\drive_c\Program Files (x86)\World of Warcraft\_retail_\Wow.exe"
Time: May 27, 2019 11:06:15.019 PM
User: krovikan
Computer: linux
------------------------------------------------------------------------------

This application has encountered a critical error:

ERROR #132 (0x85100084) Fatal exception!

Program: Z:\home\krovikan\.wine\drive_c\Program Files (x86)\World of Warcraft\_retail_\Wow.exe
ProcessID: 8
Exception: 0xC0000096 (PRIV_INSTRUCTION) at 000000007b6b06ed

I downgraded to wine-staging 4.8 and everything is working now.
The issue is with wine/wine-staging 4.9

When the 4.8 was release (2 weeks ago) I have problems with one game and I rollback to 4.7.

When the 4.9 goes out I upgrade from 4.7 to 4.9. In other words, I don't have snapshot to roll back to 4.8.

I can only wait. :(

There are download links on the main wine hq site, to get source for wine and the staging repo. if you go to the winehq home page, click on Downloads and then scroll down to the bottom of the page, you should find links to git hub repos for wine and wine staging, and they all show releases in tarball that you can download and use to build wine for your self.

Finally I search for RPMs of wine-staging for openSUSE Leap 15.0 at RPM Search.

I downloaded wine-staging 4.2 and the 32 bit version. Before install I remove the packages of wine-staging 4.9, winetricks and wine-mono. After I install the RPMs and again the other wine packages.

And all OK. Blizzard games runs fine OK.

I store in safe guard the RPMs of wine-staging for the future (if necessary).

Downgrading Wine-staging to 4.8 solved the problem you described for me.

On Arch, this involves going to archive.archlinux.org/packages/w/wine-staging/ and either downloading it and installing with pacman -U or copying the url and using pacman -U

EZPZ.
If you're a neat-freak, you can always delete your old wine bottle, generate a new one with:
winecfg
and then run:
setup_dxvk install

I was away from the game for 6 months or so, but since coming back I've had trouble with a pair of addons that windows users do not have problems with. Tradeskillmaster is almost completely unusable, every action to do with vendors/bags/mail/professions causes multi-second lags for every single interaction (i've mostly just disabled this addon at this point due to this). I've also had a problem with All The Things. It fails to load when you login due to the script running too long. You can then refresh your list manually after login, which also causes the game to freeze for 20 seconds or so, and then it mostly works normally. There is however a 1-4 second delay every time you collect a new appearance/recipe/whatever.

Both of these addons worked fine a few months back. Has anyone else seen these issues/know a workaround/different wine version that doesn't have the issue?

I'm on wine-staging 4.6-1 on arch linux.

you can try adding elevator=deadline to your linux command line in grub. You can also try installing vulkan and running in dx12 in wow. Also look to the how to here, to see the command line that I run for my wow.

Hey Steve, thanks for the reply. My schedule appears to already be mq-deadline (I'm assuming that's the correct one for my system, if i should switch that to deadline let me know). I tried your startup script but it doesn't change anything for me. I currently run the game with dxvk and dx11, i get ~90 fps when playing the game, its only these addons that cause any framerate issues so i'm not so sure changing the graphics is going to do anything. I go from 99 fps to 0fps complete freeze and back to 90fps when the issue occurs. Both of these addons involve large JSON data structures that they access from lua files and as far as i can tell that is where the slowdown happens. Thoughts?

do the drop outs occur randomly, or at a specific interval. I know fedora uses tracker to update file information, when a file is modified, and killing that made my system run faster. basically tracker touches every file that gets modified to update the tracking database, to enhance file search. not sure if your distro has something like that. if so, try to disable it. unfortunately, it could just be bad addon behaviour. I used to run carbonite maps and quest, but had to find a different one, as carbonite killed fps in linux, but not in windows.

With All The Things it happens at load and whenever i collect a new transmog appearance or pet or something. With Trade Skill Master it happens pretty constantly and is almost unplayable. I mostly just disable TSM and deal with ATT at this point. I do see tracker-miner-fs running in the background, I'll try killing that to see if it helps, otherwise I'll looks for a TSM replacement.

Can confirm, I have the same Lags with TSM, pretty much not useable. I have them to when opening Vuhdo or Elvui config dialogs

Hi, I also have the same behaviour: both of them almost freeze the game for every bag/bank interaction, and drop to 0 fps when scanning the Auction House. I completely stopped using All The Things addon, and I only load TradeSkillMaster addon on specific character dedicated for this. I'm using wine-staging 4.4 and dxvk (same issue with vkd3d, which shows a bit lower fps than dxvk since last WoW patch).

I had a moment to take a look at this again today and tried older wine versions, 4.0 was the oldest i had in my local cache, and it didn't change anything.

I think the issue is maybe the multi-threading updates from the 8.1 patch? When I'm playing the game and not seeing issues all 4 cores are steadily in the 40-50% range. But when i click the button to refresh All The Things and the game freezes for 10 seconds or so i see a single core jump to 100% and the other cores drop to 10% until it completes and everything goes back to the way it was before. Any one have any ideas of settings that could be tweaked to help with this?

Using wine-staging 4.5 and vcrun2015 via winetricks, I get a null pointer exception whenever I try to launch WoW 8.1 via the Battle.net app. (I also tried witout winetricks.)

I'm using an AMD processor that has Vulkan support in Ubuntu Disco.

Here is part of the error code:

This application has encountered a critical error:

ERROR #132 (0x85100084) Fatal Exception!
...
Exception: ACCESS_VIOLATION

The instruction at "0x000000018000396a"
referenced memory at "0x0000000000000000"
The memory could not be "read".

Press OK to terminate the application.

Use battle.net simply to update after patches are released. The game will NOT run from the launcher. You must use the command line, as shown in the how to on this site. I would also suggest installing vkd3d and vulkan, to get the best performance with the command line since it invokes DX12 to run the game.

Thanks for the tip. Unfortunately I still get a similar null pointer exception when launching the game via the cli.

It will run from the launcher. That's the only way I can get to launch wow.

Works for D3d12 and using dxvk. When I try to launch the wow exe I get an error. Fails every time.

XUbuntu 18.10
AMD graphics, open source driver
wow 8.1.5

winhq-staging 4.4
wow installed manually without lutris.
set in winecfg: windows 8.1
set in winetricks glsl enabled (possibly vcrun2015 and corefonts needed as well)

(using "DirectX 11" leads to 2 fps, so I activated "DirectX 11 legacy")

open wow ->System->advanced-> "DirectX 11 legacy"

Game works fine at the moment.

I had problems the very first start when i had to activate "DirectX 11 legacy". So alternatively set the option out of game in the config.wtf

you can run WoW with DirectX 11 Legacy by using the -direct -d3d11legacy switches on Wow.exe within the '_retail_' folder below the install of your World of Warcraft install.
cd ~/.wine/drive_c/WoW #where I installed World of Warcraft through the Battle.net app
wine _retail_/Wow.exe -direct -d3d11legacy #run World of Warcraft

if you add the libvkd3d, you can run dx11 with decent frames per second. You HAVE to run wow from command line, as the battle.net launcher will remain in the background while the game plays. I would also recommend using vulkan and the libvkd3d to be able to run dx12. There are two patch files on the vkd3d bug report that correct the black screen problem after the most recent patch from blizzard.

Updated wine staging from 4.2 to 4.3 and now I get a black screen when using D3d12 and vkd3d.

Nothing else changed. Reinstalled wine, wow, recompiled and applied patch to vkd3d, still black screen.

Same here, tried some of the archived staging commits that I keep on my computer, and they all present black screen. Switched to DXVK --without-dxgi and was able to run in DX11 for the time being.

Black screen here too. I'm running wine staging 4.4 that I compiled and vkd3d. It was running fine until a small WoW update, then the black screen. No other changes on my system.

Same here. nvidia, Wine 3.3, vkd3d 1.1 self-compiled from git on 2019-03-14. Everything worked until the little patch, and thereafter I just get the black screen when using vkd3d. gx.log shows it keeps failing talking to the video card.
Switched to dxvk and d3d11 and it's usable again, but would prefer being back on vkd3d.

Yeah, confirming black screen....but I came back for the free weekend to test the new DX11 renderer, and for me DX11 (multithreaded renderer) with DXVK is faster then vkd3d atm. Tested with /timetest, but also in capital cities, raids and pvp.

I think the cause may be this one:
fixme:vkd3d_dxbc_compiler_get_descriptor_binding: Could not find binding for type 0x2, register 3, shader type 0x1.

Also getting the black screen; running DX11 Legacy mode for now.

This seems to be the cause and fix:
bugs.winehq.org/show_bug.cgi?id=46882

I haven't tried this yet but others are reporting successfully using vkd3d 1.1 with this patch to run WoW under d3d12

This patch did not fix the black screen for me with vkd3d 1.1 but it does with the current vkd3d Git HEAD which at the time of writing is 8df50592f66be7065d5b376fd1c6eb0745ca2a42 (Thu, 18 Apr 2019 16:49:06 +0000).

With the patch plus current git, this makes it work:

cd World of Warcraft/_retail_/
VKD3D_DEBUG="none" WINEDEBUG=-all STAGING_SHARED_MEMORY=1 STAGING_WRITECOPY=1 wine Wow.exe -d3d12

- no need for Battle.net launcher running
- Windows version set to Windows 10
- Wine Staging 4.6

Extra note - I had to disable SSAO in the in-game graphics options to stop lots of graphical flickering, but other than that it worked very well with the graphics slider set to full.

I still need the battle.net launcher. Won't work when calling the wow.exe.

Okay, to get the stuff needed to build wine, perform the following steps: This works for fedora 29 and may be what other distros need as well.

sudo dnf install wine
sudo dnf builddep wine
sudo dnf remove wine

Now you have all the build dependecies that wine needs, and by removing the distro wine, after you get the dependencies, you do not have to worry about multiple versions in your wine prefix. i also read on the dxvk site, that a bug in dxvk with certain nvidia drivers, may be causing slow downs. There are also a lot of broke addons, including my own addon Prospectbar Lives. Blizzard has removed the itembuttontemplate, so I have to find the proper replacement.

Steve, I did do "sudo dnf builddep wine" to start with,

I tried "sudo dnf install wine" and then "sudo dnf remove wine" which seemed to remove everything the first command installed...

This made no difference. vkd3d will not make successfully:
"$ make -j9
make all-am
make[1]: Entering directory '/home/%username%/wine-dirs/vkd3d'
CC libs/vkd3d/device.lo
CC libs/vkd3d/resource.lo
CC libs/vkd3d/command.lo
CC demos/gears-gears.o
CC libs/vkd3d/utils.lo
CC libs/vkd3d/vkd3d_main.lo
CC libs/vkd3d/state.lo
CC libs/vkd3d-utils/vkd3d_utils_main.lo
GEN libs/vkd3d_version.c
CC demos/triangle-triangle.o
In file included from ./include/vkd3d_d3d12.h:117,
from demos/demo.h:39,
from demos/gears.c:49:
./include/vkd3d_d3dcommon.h:132:17: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘IUnknown_QueryInterface_Stub’
void __RPC_STUB IUnknown_QueryInterface_Stub(
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
make[1]: *** [Makefile:1139: libs/vkd3d/command.lo] Error 1
make[1]: Leaving directory '/home/spaceman/wine-dirs/vkd3d'
make: *** [Makefile:815: all] Error 2
$

Predicatably:
make[1]: *** [Makefile:1139: libs/vkd3d/command.lo] Error 1
make[1]: Leaving directory '/home/spaceman/wine-dirs/vkd3d'
make: *** [Makefile:815: all] Error 2

$ PKG_CONFIG_PATH=/usr/lib/pkgconfig ../wine/configure CFLAGS='-march=bdver2 -mtune=bdver2 -O3 -fPIC -fomit-frame-pointer -pipe -DWINE_NO_TRACE_MSGS -DWINE_NO_DEBUG_MSGS' --with-wine64=../wine64-build --without-gtk3 --with-vkd3d --with-vulkan --with-x^C
...
checking for -lvkd3d... not found
configure: error: vkd3d 32-bit development files not found, Direct3D 12 won't be supported.
This is an error since --with-vkd3d was requested.

Brick wall. :D

my mistake, so sorry, you also need to do:

sudo dnf install libvkd3d
sudo dnf builddep libvkd3d
sudo dnf remove libvkd3d

Now you should have all the build dependencies that you need to make wine and vkd3d from source. Hope this helps.

Dude your patience is exemplary. Very many thanks.

please do not run sudo dnf remove libvkd3d as that will remove libvkd3d-devel that wine needs to have to compile properly. Also, wine 4.4 has been released, and there is a bug fix for ubuntu users, to allow wine to compile with vkd3d.

some infos about the system:

Intel i5-6500
Nvidia GTX960 with driver 418
Kubuntu 18.04 and Ubuntu 18.10 tested
WineHQ staging 4.3

"MSAA" and "Multisampe Alphatest" is deactivated.(read that in official forum)

Char screen works fine.
After login to a char in low populated area(Ogrimmar), playing works fine with limited 100FPS
With a char in citys like Dalaran or Boralus, with lots of other players, WoW freezes instantly.

Wow_d3d11.log:
err: DxvkDevice: Command buffer submission failed: VK_ERROR_DEVICE_LOST
err: DxvkDevice: Command buffer submission failed: VK_ERROR_DEVICE_LOST
err: DxvkDevice: Command buffer submission failed: VK_ERROR_DEVICE_LOST
err: DxvkSubmissionQueue: Failed to sync fence: VK_ERROR_DEVICE_LOST
err: DxvkSubmissionQueue: Failed to sync fence: VK_ERROR_DEVICE_LOST
err: DxvkSubmissionQueue: Failed to sync fence: VK_ERROR_DEVICE_LOST
err: DxvkSubmissionQueue: Failed to sync fence: VK_ERROR_DEVICE_LOST
err: DxvkSubmissionQueue: Failed to sync fence: VK_ERROR_DEVICE_LOST

I can confirm I hit the same issue this afternoon after patching to 8.1.5, can someone remind me how to capture an appropriate WINEDEBUG piped out to a file...whatever I was doing capture a log with more lines of code than Windows 10.

Since the patch yesterday my computer freezes after loading in a character. I am running Ubuntu 18.04 using wine 4.3 from here and DXVK 1.0. I'm not really sure what steps to take to troubleshoot this so any help would be greatly appreciated.

Hey there,

same problem here.
Also installed a fresh Ubuntu 18.10 on another hard disk, with a fresh World of Warcraft installation.
Same issue.
Help to solve it in Ubuntu would be great.

Temporarily next step will be another distro. Any experience with Manjaro?

Same problem here. Before the patch all runs often good.

Wine-Staging 4.3 + DXVK 1.0 in openSUSE Leap 15.0
If I launch WoW from Blizzard app, after enter to the world all system is freeze and I need to push the RESET button of the computer.
If I launch WoW from command line (without Blizzard app) after a few seconds of entered in the world, screen freeze and I need to kill Plasma with Ctrl-Alt-Backspace twice. After few seconds I can open Plasma again from login screen.

I tried Wine-Staging 4.3 without DXVK and halt Error #132

i5-6600K
GTX1070 with propietary driver 418.42.02
AA off

I have too the:

err: DxvkDevice: Command buffer submission failed: VK_ERROR_DEVICE_LOST
err: DxvkDevice: Command buffer submission failed: VK_ERROR_DEVICE_LOST
err: DxvkDevice: Command buffer submission failed: VK_ERROR_DEVICE_LOST
err: DxvkDevice: Command buffer submission failed: VK_ERROR_DEVICE_LOST
err: DxvkSubmissionQueue: Failed to sync fence: VK_ERROR_DEVICE_LOST
err: DxvkSubmissionQueue: Failed to sync fence: VK_ERROR_DEVICE_LOST
err: DxvkSubmissionQueue: Failed to sync fence: VK_ERROR_DEVICE_LOST
err: DxvkSubmissionQueue: Failed to sync fence: VK_ERROR_DEVICE_LOST
err: DxvkSubmissionQueue: Failed to sync fence: VK_ERROR_DEVICE_LOST

I haven't tried this fix yet but just aw it on reddit.

www.reddit.com/r/linux_gaming/comments/b0udaq/for_those_experiencing_crashing_after_the_latest/

Thanks a lot dude!!!
That fix works. But I have to start WoW without Lutris. I Think its the Lutris WoW Profile. Will take a look next.
But with this fix installed, everything is fine again :-)

Works again with the new libraries of DXVK at the end of ticket 964 of github:

github.com/doitsujin/dxvk/issues/964

The file is:

github.com/doitsujin/dxvk/files/2964170/dxvk-master.tar.gz

Sort of good news! As of patch 8.1.5 I can now see the character select screen and log into the game with DX12. Unfortunately I'm getting less than 1fps so the game is utterly unplayable. I'm curious to hear from other people's experiences with the latest patch.

I had being beaten, Steve, so I've spent the last two days trashing one Fedora install and trying to fully document my process in getting vkd3d and Wine64 compiled from source.

Following your steps I've got as far as:
./configure --enable-demos --with-sysroot
This process completes with the summary I succeeded in getting:
Configuration summary for vkd3d 1.1

Have XCB: yes
Have SPIRV-Tools: no

Building demos: yes

Building crosstests: yes
The SPIRV-Tools no is really annoying as I built the successfully from source! Path issue?

Frustratingly I've hit the wall with :
make...

widl is required to generate include/vkd3d_dxgi1_3.h...
So inevitably:
error: vkd3d_d3d12.h: No such file or directory #include
^~~~~~~~~~~~~~~compilation terminated

I thought widl was a mingw component...there are many mingw packages so is installed a couple ...tools and ...gcc. Any idea how to move beyond this problem mate?

Hi, I had the exact same issue, resolved by using:

WIDL=../wine-4.3/wine64-build/tools/widl/widl ./configure --enable-demos --with-sysroot

instead of just ./configure --enable-demos --with-sysroot

I decided to recompile it all again and found that installing the compiled wine before you start working on vkd3d solves the issue.
Slightly out of order on the howto section, but works a treat - no commandline changes needed.

I did wonder about this...good shout sir. Thank you very much for your input.

Things were progressing again then I hit this wall:

PKG_CONFIG_PATH=/usr/lib/pkgconfig ../wine/configure CFLAGS='-march=bdver2 -mtune=bdver2 -O3 -fPIC -fomit-frame-pointer -pipe -DWINE_NO_TRACE_MSGS -DWINE_NO_DEBUG_MSGS' --with-wine64=../wine64-build --without-gtk3 --with-vkd3d --with-vulkan --with-x
...
checking for mpg123_feed in -lmpg123... no
checking libavutil/avutil.h usability... no
checking libavutil/avutil.h presence... no
checking for libavutil/avutil.h... no
checking for -lopenal... not found
checking for -lodbc... libodbc.so.2
checking for -lnetapi... not found
checking for -lvulkan... libvulkan.so.1
checking for -lvkd3d... not found
configure: error: vkd3d 32-bit development files not found, Direct3D 12 won't be supported.
This is an error since --with-vkd3d was requested.

Er...I was compiling wine to first to resolve the widl errors I had from vkd3d. Now I cannot continue compiling wine32 because vkd3d isn't build. :D

Happy daze.

Using:
WIDL=../wine-4.3/wine64-build/tools/widl/widl ./configure --enable-demos --with-sysroot

I was able to progress to make which was a storm (of some sort):
make[1]: Entering directory '/home/%username%/wine-dirs/vkd3d'
CC demos/gears-gears.o
CC libs/vkd3d/device.lo
CC libs/vkd3d/resource.lo
CC libs/vkd3d/state.lo
CC libs/vkd3d/utils.lo
CC libs/vkd3d/command.lo
CC libs/vkd3d/vkd3d_main.lo
GEN libs/vkd3d_version.c
CC libs/vkd3d-utils/vkd3d_utils_main.lo
CC demos/triangle-triangle.o
In file included from ./include/vkd3d_d3d12.h:117,
from demos/demo.h:39,
from demos/triangle.c:46:
./include/vkd3d_d3dcommon.h:132:17: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘IUnknown_QueryInterface_Stub’
void __RPC_STUB IUnknown_QueryInterface_Stub(
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
make[1]: *** [Makefile:1182: demos/gears-gears.o] Error 1
make[1]: Leaving directory '/home/spaceman/wine-dirs/vkd3d'
make: *** [Makefile:815: all] Error 2

Reinstall Fedora and start again (30 is out soon)? LOL XD

strange how after compiling vkd3d and installing with:
sudo make install
sudo ldconfig

you've ended up with:
checking for -lvkd3d... not found

wish I could help you out :(

Hello,
vkd3d project can be found here : github.com/d3d12/vkd3d/

See "README", it is written how to get widle working, it is as simple as download wine source and compiling only widle (it is given in wine source).

Everything is explained in this file.

I'm sorry but what part of "Using:
WIDL=../wine-4.3/wine64-build/tools/widl/widl ./configure --enable-demos --with-sysroot"
was unclear?

Read a README, well thank you, /slowclap.

Not my fault if you need 5 comments to go on and can't follow instructions properly

It's your fault if you can't read a thread to see what someone has done before wading in with "advice". Right up with Let me Google that for you. Jog on.

Hi,
I am using winestaging 4.1 and install went just fine, but when I start the game it opens and never finishes establishing a connection. Battlenet is working just fine, so I wonder if I missed anything. Any1 had this problem prior?
regards Chris

You need to poke wholes in your firewall software and also your physical router, to allow WoW to talk to itself. Search the wow tech support forum to find the ports they need opened. Also if you use the battle.net launcher to start the game, you may run into issues. Most people build a script, to run the wow.exe from the _retail_ folder in the wow directory on your computer. The script in the howto will start wow, if you are wanting to run it with dx12 and meet the system requirements to do that. you need wine staging and the vkd3d library, as well as the vulkan drivers that support your video card. Hope this helps.

I have winehq-staging installed, with Wine 4.2. I also installed the vkd3d from cybermax-dexter on launchpad. I am using Linux Mint 19.2 (Tara), and my computer's built-in on-board video (intel).

I can see gears-vkd3d working.

However when I run WoW with the -d3d12 flag, Direct3D 11 is loaded, and is the only option in the System -> Advanced menu. My FPS is abysmal, and I am hoping that dx12 will be better, but it isn't working. Help?

have you set winecfg to use windows 10? DX12 is only available in windows 10.

yes, winecfg is set to Windows 10.

might consider compiling vkd3d from source, per the how to shown here. Some distro versions of vkd3d are not compatible with WoW. As I have done recently, I am happy to email you the current WoW patched vkd3d that I run.

My distro doesn't include a version of vkd3d. I am using one that is from a PPA (I believe I found below) which is supposed to be made specifically for WoW.

Ok, so I did the steps for compiling vkd3d from source:

rm -fr vkd3d
git clone source.winehq.org/git/vkd3d.git
cd vkd3d
./autogen.sh
./configure --enable-demos --with-sysroot
make -j6
sudo make install
sudo ldconfig


and am using the game launch script:

#!/usr/bin/env bash
winetricks win10
env VKD3D_DEBUG=none WINEDEBUG=-all STAGING_SHARED_MEMORY=1 STAGING_WRITECOPY=1 nice -20 wine64 '/home/steve/.wine/drive_c/Program Files (x86)/World of Warcraft/Wow.exe'
winetricks win7

yet still no Directx12 only 11.

Still no bueno.

Distro: Linux Mint 19.2 (Tara)
Wine: 4.2 (staging) -- Set to Windows 10
vkd3d: package from cybermax-dexter/vkd3d bionic PPA - specifically built with patches for WoW.
intel integrated graphics
vulkan from Padoka Stable PPA (mesa implementation)

gears-vkd3d and triangle-vkd3d both work, and work well.

Using:
env VKD3D_DEBUG=none WINEDEBUG=-all STAGING_SHARED_MEMORY=1 STAGING_WRITECOPY=1 nice -20 wine64 '/home/darkhelm/.wine/drive_c/Program Files (x86)/World of Warcraft/_retail_/Wow.exe'

WoW System -> Advanced settings does not show DirectX 12. It only shows DirectX 11.

Is your Intel video DX12 compatible? I had an old nvidia card that wasn't and the option would not show up in WoW. Once I upgraded to a new card and driver the option showed up.

Fairly certain it is. The laptop was made about a year ago.

If it didn't work, you would think that the gears-vkd3d and triangle-vkd3d demos would not work.

Looked it up. I have an Intel HD 620 (Kaby Lake GT2) chipset, which is DirectX 12 compatable.

Check to make sure you are running latest vulkan, and your intel driver is also the latest for your distro. Find the gx.log in ~/.wine/drive_c/Program Files (x86)/World of Warcraft/_retail_/Logs and make sure it sees the video card. If you have dxvk dll overrides in your winecfg, you need to remove them, so that it uses the wine compiled dxgi and not the dxvk dxgi.

vulkan version: 1.1.97.0~rc1-1lunarg18.04.1.1
mesa version: 18.3.3-1~b~padoka0
vkd3d version: 1.1cybmod21-bionic~1ppa1
wine (staging) version: 4.2~bionic

I have nothing for dxvk installed. This was a clean wine-staging install. The only thing I added was corefonts.

gx.log:

2/20 08:35:31.313 LogOpen
2/20 08:35:32.312 ConsoleDetectDetectHardware():
2/20 08:35:32.718 cpuIdx: 1
2/20 08:35:33.290 ConsoleDeviceInitialize(): hwDetect = 0, hwChanged = 0
2/20 08:35:34.168 D3d11 Device Create
2/20 08:35:34.845 Format: 1471 x 811 Window, vsync 0
2/20 08:35:35.723 Found Adapter 0: Vendor Id 0x8086, Device Id 0x0162 - Sysmem = 0
2/20 08:35:36.320 Choosing adapter 0
2/20 08:35:38.411 Caps:
2/20 08:35:39.152 Vendor ID: 8086
2/20 08:35:39.916 Device ID: 162
2/20 08:35:40.707 AFR Groups: 1/1
2/20 08:35:41.287 Feature Level: DX=3, GL=0, MTL=0
2/20 08:35:42.944 NotifyOnDeviceCreate
2/20 08:35:43.295 D3d11 Device Create Successful
2/20 08:35:43.931 CPU Processor Detection: 4 H/W threads
2/20 08:35:44.544 Memory Detection: 8242466816 bytes of physical memory available
2/20 08:35:45.391 Detected Graphics Defaults: 4 (CPU = 6, GPU = 4, MEM = 6)
2/20 08:35:58.907 RenderSettings::NotifyChanged
2/20 08:37:04.269 No
2/20 08:38:38.071 No
2/20 08:38:39.601 No
2/20 08:40:04.438 D3d11 Device Destroy
2/20 08:40:05.137 NotifyOnDeviceDestroy
2/20 08:40:05.959 D3d11 Device Destroyed

So, I have the latest vulkan, latest intel driver, latest Wine and latest vkd3d I can get. I have no dxvk at all, and I believe I see that gx.log has identified my card.... but it shows dx11 not dx12.

try adding -d3d12 at the end of the wow.exe command line in your startup script. Are you compiling the vkd3d code, or using distro provided? There is a specific patch for WoW in a bug report. Do you know if the vkd3d you have is using that patch? When you start up wow, from command line, and go to the System section, does the api drop down even show dx12 as an option? On that same screen, what is shown for the graphics card it detects? Use the drop down to go from auto to the specific card you want to use and see if that helps.

I tried -d3d12 on the command-line. No effect.

I am using vkd3d from a repo that is specifically patched to work with WoW. The maintainer says it has the patch on it.

In system -> advanced, there is no option for DirectX 12

Card listed: Intel HD Graphics 4000

Which.... is not my card. And apparently is one that doesn't support DirectX 12 Interesting.

lspci says:

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 (rev 02)

Which is able to support DirectX 12.

So my question then is -- why is WoW seeing an Intel 4000 chip, when I have an Intel HD Graphics 620?

can you run the game in windows 10 and see if wow detects dx12 and the video card? I am thinking either wine is not seeing the card properly, or that blizzard has a problem.

Sorry, I don't have a Windows computer. My guess is somehow Wine is not seeing it correctly. Is there something I can use to test if Wine is using vkd3d? I have tried gears-vkd3d and triangle-vkd3d, both of those work, and work well.

okay, if gears and triangle, from vkd3d work then yes, dx12 is working for you. So, try dxvk and see if the game works. if so, then see what video card is being shown on system settings in wow. if it shows hd 4000 then the problem may be blizzard.

I just want to be extra sure.... is there a tool I can use in wine that prints out or displays what card I have?

So I found some other applications that do system diagnostics, and they are also not detecting the video card... Wouldn't a Windows application be able to see my card information?

wine 4.3 fixed the issue with intel hd 620 so you should be able to see dx12 now as an option. still need to load in the staging version, and they also fixed vsync for d3d12 to honor the game settings used, instead of being on all the time.

Yeah, tested with 4.3. It is properly detecting my video card in WoW (that is, I see the option in Settings -> Advanced), and yet still no DirectX 12 as an option. This is getting really annoying.

Here is the output from gx.log:

3/6 09:33:46.851 LogOpen
3/6 09:33:46.963 ConsoleDetectDetectHardware():
3/6 09:33:46.980 cpuIdx: 1
3/6 09:33:47.011 ConsoleDeviceInitialize(): hwDetect = 1, hwChanged = 0
3/6 09:33:47.039 D3d11 Device Create
3/6 09:33:47.058 Format 1600 x 900 Fullscreen, ArgbX888, vsync 0
3/6 09:33:47.129 Found Adapter 0: Vendor Id 0x8086, Device Id 0x5916 - Sysmem = 0
3/6 09:33:47.148 Choosing adapter 0
3/6 09:33:47.192 Caps:
3/6 09:33:47.215 Vendor ID: 8086
3/6 09:33:47.237 Device ID: 5916
3/6 09:33:47.263 AFR Groups: 1/1
3/6 09:33:47.284 Feature Level: DX=3, GL=0, MTL=0
3/6 09:33:47.312 NotifyOnDeviceCreate
3/6 09:33:47.330 D3d11 Device Create Successful
3/6 09:33:47.442 CPU Processor Detection: 4 H/W threads
3/6 09:33:47.462 Memory Detection: 8242462720 bytes of physical memory available
3/6 09:33:47.504 Detected Graphics Defaults: 4 (CPU = 6, GPU = 4, MEM = 6)
3/6 09:33:47.783 RenderSettings::NotifyChanged
3/6 09:33:49.750 No
3/6 09:33:50.376 RenderSettings::NotifyChanged
3/6 09:34:07.934 GxRestart
3/6 09:34:08.200 D3d11 Device Destroy
3/6 09:34:08.221 NotifyOnDeviceDestroy
3/6 09:34:08.329 D3d11 Device Destroyed
3/6 09:34:08.345 D3d11 Device Create
3/6 09:34:08.467 Format 1600 x 900 Fullscreen, ArgbX888, vsync 0
3/6 09:34:08.588 Taking Adapter 0 by name: Vendor Id 0x8086, Device Id 0x5916 - Sysmem = 0
3/6 09:34:08.612 Intel(R) HD Graphics 620
3/6 09:34:08.673 Caps:
3/6 09:34:08.690 Vendor ID: 8086
3/6 09:34:08.713 Device ID: 5916
3/6 09:34:08.736 AFR Groups: 1/1
3/6 09:34:08.758 Feature Level: DX=3, GL=0, MTL=0
3/6 09:34:08.784 NotifyOnDeviceCreate
3/6 09:34:09.236 D3d11 Device Create Successful
3/6 09:34:11.790 D3d11 Device Destroy
3/6 09:34:11.811 NotifyOnDeviceDestroy
3/6 09:34:11.879 D3d11 Device Destroyed

I have not set dx to 12; afaik I don't have vulkan support in my distro yet anyway; But I noticed abysmal framerates, unplayable.
Your post pointed me to the solution: there is also a DX 11 Legacy setting in WoW, that seemed to fix the abysmal framerates, at least to a playable level.

Is anyone else getting this error when playing with vkd3d?

/var/log/syslog.1:Feb 16 13:39:50 recluce kernel: [ 2027.592153] NVRM: Xid (PCI:0000:02:00): 13, Graphics Exception: Class 0x1 Subchannel 0x0 Mismatch
/var/log/syslog.1:Feb 16 13:39:50 recluce kernel: [ 2027.592158] NVRM: Xid (PCI:0000:02:00): 13, Graphics Exception: ESR 0x4041b0=0x1
/var/log/syslog.1:Feb 16 13:39:50 recluce kernel: [ 2027.592161] NVRM: Xid (PCI:0000:02:00): 13, Graphics Exception: ESR 0x404000=0x80000002
/var/log/syslog.1:Feb 16 13:39:50 recluce kernel: [ 2027.592331] NVRM: Xid (PCI:0000:02:00): 13, Graphics Exception: ChID 001e, Class 0000c197, Offset 00002398, Data 00000000

I'm using the wine staging from my distro, Xubuntu 18.10, along with vkd3d from the PPA that Sveinar Søpler posted here. It works great except for these exceptions happening very occasionally. It seems to be associated to certain locations, since once it triggers if I go back to the same place it happens again. Otherwise I can play for hours with no problem, including doing raids. The two locations it's happened to me don't seem like anything special. Once was at the island off the coast of Stormsong Valley and another in arathi highlands fighting the big spider during a world quest.

According to Nvidia's documentation the Xid: 13 error is from the driver or application, not hardware.

Hi, I got the same since I tried to use vkd3d:
[15250.524113] NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception: Class 0x1 Subchannel 0x0 Mismatch
[15250.524114] NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception: ESR 0x4041b0=0x1
[15250.524116] NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception: ESR 0x404000=0x80000002
[15250.524193] NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception: ChID 001e, Class 0000b197, Offset 00002398, Data 00000000
Or sometime:
NVRM: Xid (PCI:0000:01:00): 31, Ch 0000001e, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_T1_0 faulted @ 0xff_8baba000. Fault is of type FAULT_PTE ACCESS_TYPE_READ

It can happen after 6 seconds or more than hour playing WoW, but it always happen. When this happen, screen goes black, I cannot switch to any other application nor virtual desktop, and then after almost a minute, I'm able to get back control but at that point only WoW is frozen, and I have to kill all wine related process.

I'm using wine-staging 4.0 from my distro (Gentoo with 4.14.83 kernel AMD64) with "wine/dlls/dxgi/swapchain.c" patched manually, and with vkd3d (last git).
I also tested wine 4.2 from winehq with staging patches: same behavior.
My nvidia-drivers are version 415.27. I also tested 418.30: same behavior (my graphic card is a GeForce GTX 980M). With older version 390.87 I only get a black screen when starting WoW.

For now I went back to use -d3d11 when starting WoW since it is not playable with regular crashes on -d3d12, but performance is really low (between 5 and 20fps, with settings at level 5, compared to 80+fps with settings at level 9 with -d3d12).

Not related: I remember someone having small "freeze" when mouse hovering object in inventory: in my case this was linked to "TradeSkillInfo" addon, not wine.

are you running a laptop, with optimus or prime, and are you certain that the nvidia card is active? can you run the vkd3d gears demo?

Indeed I'm running on a laptop (ASUS ROG G752VY). I can run vkd3d gears and triangle demos.

I never tried to setup optimus or prime (I only installed the nvidia-drivers package to get my Xorg running), so I was quite sure that I was only using the nvidia card. However I saw that in my kernel the "Intel 8xx/9xx/G3x/G4x/HD Graphics" option was enabled, so I'm not confident anymore (is this enough to activate optimus or prime ?). I checked my distribution notes about setting up optimus (wiki.gentoo.org/wiki/NVIDIA/Optimus) and my xorg.conf does not contain anything related to the Intel card, and xrandr gives me only the nvidia card:

# xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x1b9 cap: 0x1, Source Output crtcs: 4 outputs: 6 associated providers: 0 name:NVIDIA-0

I did not saw anything about optimus in nvidia-settings tool: is there a way to confirm whether it is enabled or not (or is the above enough to know whether it is enabled or not) ?

did you compile vkd3d yourself, or use a distro version? There are 2 patches, that I apply to my local copy of the vkd3d that I have, and they are listed on the bug report for vkd3d, shown in this appdb. Hoping this helps. If you want, I can email my copy of the repo I compile from, so you can compile it on your system.

I tried to use vkd3d 1.0 and 1.1 from my distro: both failed (black screen).
I then compiled it myself with instructions provided in this thread:
git clone source.winehq.org/git/vkd3d.git
cd vkd3d
./autogen.sh
./configure --enable-demos --with-sysroot --prefix=/opt/vkd3d
make
sudo make install

My local git copy is up to date with 'origin/master'
I used the --prefix in order not to interfere with my distro package manager too much, and then used 'export LD_LIBRARY_PATH=/opt/vkd3d/lib' before starting wine (I can confirm this works since without it, I fall back to a black screen linked to the use of vkd3d 1.1 or 1.1). For reference, I did a test without the --prefix, thus overwriting files from vkd3d-1.1 package, then recompiled wine in order to ensure I got the correct headers: result was the same.

In regards to optimus/prime: reading through the requirments in order to enable the use of the Intel card, I can confirm I'm did not do this (I don't have bumblebee installed neither).

I guess the 2 patches are "Update descriptors hack" and "WIP private data patch". i did not try those, I'll recompile vkd3d from git with those and test.

I compiled last git version of vkd3d, with "Update descriptors hack" patch only ("WIP private data patch" does not properly apply, and to my understanding have already been included in the git version I fetched).
I have now been playing for several hours without a single crash. Also, I used to have to disable SSAO to avoid display artifact: it seems to work fine now.

So in my case: last git version of vkd3d + "Update descriptors hack" patch seems to have fixed the "NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception" issue.

Thank you for your help.

Some feedback after additionnal hours of play: in fact the crash still happen, but a lot less (about one crash every 4 hours, instead of at least one crash per hour)

Nvidia has released a new driver update. One of the items fixed is an Xid: 13 error. It 418.43

For reference, since upgrading wine-staging to 4.4, nvidia-drivers to 418.43 and vkd3d up to date with git repository, I did not encounter Xid: 13 error.
(vkd3d now sometimes log "fixme:vkd3d_dxbc_compiler_get_descriptor_binding: Could not find binding for type 0x2, register 3, shader type 0x1.", which cause a small freeze, but does not crash the game)

Does anyone have this working with an AMD Radeon card? I've built vkd3d from source and applied all the WoW-specific patches and no matter what I am getting a black screen on character selection. I see some bug reports about RADV-specific problems so I'm wondering if anyone has gotten it to work and what their environment is like. I'm running mesa 18.3.3 and I'd like to avoid compiling mesa/llvm/clang from git if possible, although I'd consider it if that would solve the problem.

I have openSUSE Leap 15.0 and I try to install VKD3D. My Nvidia driver is 415.22.05 and my card is GTX 1070.

Now I have for 64 btis: /usr/lib64/libvkd3d.so.1 and /usr/lib64/libvkd3d.so.1.1.0.
Also I have for 32 bits: /usr/lib/libvkd3d.so.1 and /usr/lib/libvkd3d.so.1.1.0.

When I run the line proposed by Steve: env VKD3D_DEBUG=none WINEDEBUG=-all wine64 '/home/krovikan/.wine/drive_c/Program Files (x86)/World of Warcraft/_retail_/Wow.exe' the game run but in the log in screen, system section, I can't see DX12 (only DX11).

My winecfg is set to W10 and using my default wine. I have .wine as default (where I type the command above) and I have .winedxvk for DXVK when is needed with their ENV.

I can't provide log because I don't have. If I remove WINEDEBUG=-all and set VKD3D_DEBUG=-all then I can see log in console but I can't save to a file (I googled to do but I can't).

I forgot to say that I use wine-staging 4.1

What version of vulkan are you running? use vulkaninfo to post that information here. if you are running dxvk, what happens with it, and what frames per second do you get?

Vulkan 1.1.96 when I use DXVK 0.96.

Vulkan info shows:

===========
VULKAN INFO
===========

Vulkan API Version: 1.0.65

The number of frames depends of activity.

I have 159 addons (real number is 32 because in the 159 are included core addons + modules + modules loaded on demand). With this profile the World is acceptable. 50 - 60 fps in Daz'alor.
But in raid, the number goes down to 2,4 - 3,9 fps (screen freezing) in the first boss (Champion of Light) while I am recording with vokoscreen 2.5.0 at 25fps (mp4 format with libx264 and libmp3lame).

I have a profile with 92 addons (real number is 14 because in the 92 are included core addons + modules + modules loaded on demand). With this profile, made for Raid, I have 9 - 17 fps (screen smoothly) in the first boss (Champion of Light) while I am recording with vokoscreen 2.5.0 at 25fps (mp4 format with libx264 and libmp3lame).

Example of Addon with modules loaded on demand is DBM (I have all expansions of DBM).

Before patch 8.1, I can raid without problems while I am recording. I can do Ghuun (example) smoothly. The day of 8.1 and after, Uldir have freezings (not playable) in Vectis, Zul, Mythrax and Ghuun (while recording). I don't have information without recording.

Today I try VKD3D but don't appear DX12 in the combo of API select as described in the OP.

You MUST remove the winecfg dll overrides for dxvk BEFORE you try vkd3d. also, you could make a script file for vkd3d to start wow, and put -d3d12 on the wow command line, to start the game. Shown here is the command line I use.

env VKD3D_DEBUG="none" WINEDEBUG=-all STAGING_SHARED_MEMORY=1 STAGING_WRITECOPY=1 wine64 '/home/steve/.wine/drive_c/Program Files (x86)/World of Warcraft/_retail_/Wow.exe' -d3d12 &>/dev/null

The word wrap on this post caused a line wrap, but that is all one line. Hope this helps. You might also consider compiling vkd3d from source and linking it with the wine staging, to get all the fixes that are included. the script that I use to compile it, is in the how-to section here. There are some patches for screen flash attached to a bug report for vkd3d that you might need also. You would need to apply them, after the source is downloaded, but before you compile it.

I have not done any raiding with my set-up, so might see how I do, since wing 1 of daz'alor is open in lfr. I will post here afterwards with fps results.

I try your command: env VKD3D_DEBUG="none" WINEDEBUG=-all STAGING_SHARED_MEMORY=1 STAGING_WRITECOPY=1 wine64 '/home/steve/.wine/drive_c/Program Files (x86)/World of Warcraft/_retail_/Wow.exe' -d3d12 &>/dev/null but no DX12 is selected in System.

My prefix .wine no have overrides for DXVK, so it's no the problem. For use DXVK I use always: env DXVK_HUD=1 WINEDEBUG=-all WINEPREFIX="/home/krovikan/.winedxvk" wine64 '/mnt/juegos/wine/drive_c/Program Files (x86)/Battle.net/Battle.net.exe'

Do not launch from the battle.net app, it will not properly start the game. You may need to compile vkd3d to get it to work, most distro versions of vkd3d are 1.0 and that one does not work with ANY DX12 games at all. Copy and paste the build vkd3d scriot from the how to, and see if it compiles and works for you.

I tried but nothing to do in openSUSE.

git files and instructions in your Howto are make for debian (or so it seems).

My steps:

krovikan@linux:~/Descargas> git clone source.winehq.org/git/vkd3d.git
Clonando en 'vkd3d'...
remote: Counting objects: 8493, done.
remote: Compressing objects: 100% (3057/3057), done.
remote: Total 8493 (delta 6819), reused 6833 (delta 5327)
Recibiendo objetos: 100% (8493/8493), 1.93 MiB | 1.17 MiB/s, listo.
Resolviendo deltas: 100% (6819/6819), listo.
krovikan@linux:~/Descargas> cd vkd3d
krovikan@linux:~/Descargas/vkd3d> ./autogen.sh
./autogen.sh: línea 3: autoreconf: no se encontró la orden

I look into autogen.sh and I see the call to autoreconf. I install dh-autoreconf (for support autoreconf) plus other debian dependencies as dpkg, debhelper and others.
I install also vulkan-devel.

I change the line of autogen.sh from autoreconf to dh_autoreconf and now:

krovikan@linux:~/Descargas/vkd3d> ./autogen.sh
dh_autoreconf: cannot read debian/control: No such file or directory

Unknown option: f
dh_autoreconf: No compatibility level specified in debian/compat
dh_autoreconf: This package will soon FTBFS; time to fix it!
dh_autoreconf: Compatibility levels before 5 are deprecated (level 1 in use)
dh_autoreconf: cannot read debian/control: No such file or directory

I hope that some day exists one winetricks vkd3d as for dxvk (I update easy dxvk with winetricks instead of compiling).

In the test results, you described it as "Platinum" and that you did not use a workaround. However, you have also posted what is clearly a complex piece of compiling (without leaving instructions on what tools are necessary to compile it) a second piece of software not included with default WINE. At best, this should have been labeled as Gold or Silver and the rating is misleading. Also, if VKD3D is necessary to run this and other games, shouldn't it be included by default in the standard Wine downloads? I find these test results to be very misleading.

vkd3d is sourced as part of wine, to implement dx12 over vulkan instead of opengl. I compiled solely from source provided by wine, and no outside third party. I explained in great detail in the how to, about dependencies to build wine, and if you read, others do state that they are running distro versions of wine and the companion dx12 library built from vkd3d. Most distros, including fedora offer libvkd3d in the wine repository. everything tested is available in the wine source tree and the wine distro trees, so choosing to compile from source does not invalidate any results. We are all free to compile, on our own distros that we run, and I am happy to help anyone achieve the results I get from the game.

You're not understanding my comment. "Platinum" refers to a program that works "out of the box" with no modifications upon install to get it running. In other words, a program which an end user with minimal experience might open with wine even from the gui by double clicking and have it run as though it were on windows. This install requires more technical know how than that. I've been using wine and linux for fifteen years now, and reading your instructions is off-putting to me. Imagine what it would be like for those not familiar with wine at all who just want to run WoW. For the record, I attempted to install WoW on Ubuntu today which is what landed me here. Battle.net, which is usually the ugly elephant in the room came up and running without a hitch, but WoW itself would not come up even when WoW.exe was running. I had not heard of vkd3d or its importance in running this piece of software. Upon seeing your results, I became confused until I read further and saw that there "was" an additional install and workaround needed in order to support DirectX12 which Wine still does not do on its own.

Unless the software will run without any further compiling, workarounds, or installs other than double clicking on "install.exe", please don't mark it as platinum with no workarounds needed.

Also, for the record, libvkd3d is not in the ubuntu wine repositories, and yes, I'm running wine from the repos on this site. 18.04 and WINE 4.0 (stable).

Install wine staging, not wine stable, WoW needs the extra staging patches. Ubuntu should have staging. I am surprised the Ubuntu does not have libvkd3d for you to use. I prefer to compile and run, but I NEVER said it would not work "out of the box" and if that is what you want, I would suggest Lutris or Play on Linux. They use wine as a base, and build a user friendly gui to help novices install games and they also have a good support as well as being open source. I will stand by my rating, because the libvkd3d is a wine component, and as some programs need Microsft .net framework to run, wine needs vkd3d if you want good performance with DX12. That being said, vkd3d being part of the wine development, and not presented by any third party, I still say it works "out of the box".

To be fair Steve, and I have had some (processor cooking) success with vkd3d, finding and installing all the dependencies for vkd3d and then compiling it from source is far from a straight-forward process.
Platinum
Works as well as (or better than) on Windows out of the box.

Rating WoW this way may be technically true, but is disingenuous. WoW works almost as well as in Windows if you jump through numerous (not insignificant) hoops and work out all the dependencies of Wine64 and vkd3d for your distro and compile from source.

In a full raiding environment (not LFR) Wine-staging (from repo)/vkd3d (self-compiled) delivers comparable frames to DXVK and nowhere near those of Windows. I found it difficult to cool my FX8350 and had several system shutdowns.

I have the benefit of having tested this rigorously in both Windows 7 and 10 and in Linux. The distros I have tested are antiX, Debian and Fedora and my results were at best mixed, at worst complete inability to run anything and at best very playable but remarkably mediocre. Have you played WoW on Windows recently?

I'm using the latest wine-staging build on Arch which has been compiled with vkd3d support, as well as vkd3d-git and lib32-vkd3d-git from the AUR, and I'm getting a black screen after logging in without seeing the character select screen. I can move the cursor around but can't see or click on anything else.

Has anyone else encountered this? I am not seeing any relevant bugs in the bugtracker. Here is the console output that loops over and over again in case that is relevant:

```
002a:fixme:dxgi:d3d12_swapchain_init Ignoring swap effect 0x4.
002a:fixme:dxgi:d3d12_swapchain_init Ignoring refresh rate.
002a:fixme:dxgi:dxgi_factory_MakeWindowAssociation iface 0xb63e0, window 0x60066, flags 0x6 stub!
002a:fixme:d3d12:D3D12CreateDevice Ignoring adapter 0x1467d970.
002a:fixme:d3d12:D3D12CreateDevice Ignoring adapter 0x1467d970.
fixme:vkd3d_create_device: Unsupported feature level 0xc000.
002a:fixme:dxgi:dxgi_factory_CheckFeatureSupport iface 0xb6090, feature 0, feature_data 0x236620, data_size 4 stub!
002a:fixme:d3d12:D3D12CreateDevice Ignoring adapter 0x1467d970.
002a:fixme:d3d12:D3D12CreateDevice Ignoring adapter 0x1467d970.
002a:fixme:dxgi:dxgi_adapter_QueryVideoMemoryInfo iface 0x1467d970, node_index 0, segment_group 0, memory_info 0x1d13d2b8 partial stub!
002a:fixme:dxgi:dxgi_adapter_QueryVideoMemoryInfo iface 0x1467d970, node_index 0, segment_group 0x1, memory_info 0x1d13d2d8 partial stub!
002a:fixme:dxgi:dxgi_adapter_SetVideoMemoryReservation iface 0x1467d970, node_index 0, segment_group 0, reservation 2bc00000 stub!
fixme:d3d12_device_CheckFeatureSupport: Root signature version 1_1 not supported yet.
fixme:vkd3d_serialize_root_signature: Ignoring error blob 0x236688.
fixme:vkd3d_serialize_root_signature: Ignoring error blob 0x236688.
002a:fixme:msctf:ThreadMgr_ActivateEx Unimplemented flags 0x4
002a:fixme:msctf:ThreadMgrSource_AdviseSink (0x10010550) Unhandled Sink: {ea1ea136-19df-11d7-a6d2-00065b84435c}
fixme:vkd3d_bind_heap_memory: Invalid heap offset 0x10000.
fixme:rs_desc_from_d3d12: Ignoring MultisampleEnable 0x1.
fixme:rs_desc_from_d3d12: Ignoring MultisampleEnable 0x1.
fixme:rs_desc_from_d3d12: Ignoring MultisampleEnable 0x1.
```

You might need to get the patches, that were posted as attachments to the vkd3d bug report. There should be two patches with the bug report, to compile with the git source, and also make sure to relink the compiled library, so wine uses it, and not the distro library.

Do you know which specific patches I would need? According to bugs.winehq.org/show_bug.cgi?id=46291, at least one of them has already been merged into master (source.winehq.org/git/vkd3d.git/commit/d18360a8b77d6f6be6d48f8207b18fdd70d7ff8f). Thanks!

bugs.winehq.org/show_bug.cgi?id=46291 has all the progress notes, on what was done, and a link to both patches. Even in my recent compiles, I have to apply the screen flash patch. Other than that, everything works great on Fedora 29 with my Nvidia GTX 970 and proprietary 418.30 driver from the nvidia website. I use dkms to install the driver, and currently running kernel 4.20.5-200 on my computer.

The patch at bugs.winehq.org/attachment.cgi?id=63011 does not apply against vkd3d master:

$ patch -Np1 -i ../wip.patch
patching file libs/vkd3d/command.c
Reversed (or previously applied) patch detected! Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file libs/vkd3d/command.c.rej
patching file libs/vkd3d/vkd3d_private.h
Hunk #1 succeeded at 232 with fuzz 2 (offset 69 lines).
Hunk #2 FAILED at 889.
1 out of 2 hunks FAILED -- saving rejects to file libs/vkd3d/vkd3d_private.h.rej

I applied the screen flash patch but I'm still getting the same behavior (black screen at character select). I'm on AMD with the latest open source drivers and mesa if it's relevant.

If you would like, I can put my current local git of vkd3d in a tarball and send it to you. Knowing it works for my nvidia card, if it fails for you, then the problem would be narrowed to the driver. Let me know if you want that. Once you have it, you would need to compile, and link it, using the script on here, but remove the line that deletes the directory, so you do not lose the changes. Let me know.

Thanks for that. Can you send me the hash of the most recent vkd3d commit you're using? I should be able to apply the patches and compile myself from that commit without you needing to send me the tarball.

the current commit 6df9554c354d9eb2e364efab43cde6b18489cb56 (HEAD -> master) that I built from today.

Is that the revision after applying the patches by any chance? I am not seeing that hash anywhere in the current master branch. Thanks!

Yes, it probably is. When I use git pull refresh on my local copy, it applies the patches again, as the first step in update. My offer to send my local copy still stands, if you need it.

Can you paste the output of `git log --oneline -n 10` from inside the srcdir? If that doesn't work then I'll take you up on the tarball offer.

142fee8 (HEAD -> master) This is another update
ba58e89 Okay, this fixes the screen flash in WoW.
a81a7f8 (origin/master, origin/HEAD) vkd3d-shader: Add initial support for built-in patch constants.
4ad4cbb vkd3d-shader: Factor out vkd3d_symbol_set_register_info().
df654aa vkd3d-shader: Factor out vkd3d_dxbc_compiler_emit_builtin().
c314b5b vkd3d-shader: Get sysval semantic from shader signature for inputs.
ba7807b vkd3d-shader: Rename scan instruction function to vkd3d_shader_scan_instruction().
fd3d661 vkd3d-shader: Unset r# registers state while leaving current shader phase.
59d97b0 vkd3d-shader: Implement hull shader barriers.
0397808 vkd3d-shader: Add support for instanced join phases.

hope this helps, let me know if you need the source tarball.

Thanks, can you go ahead and post the tarball somewhere? It looks like you're just applying patches on top of master but the WIP patch at bugs.winehq.org/attachment.cgi?id=63011 does not apply for me. The screen flashing patch does.

send me an email and I can attach the tarball to my reply to your message. my email address is eaglecomputers.ok@gmail.com

Talk to you soon.