https://bugs.winehq.org/show_bug.cgi?id=47471
Bug ID: 47471 Summary: World of Warcraft, 8.2.0 New zone Nazjatar Product: vkd3d Version: 1.1 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: vkd3d Assignee: wine-bugs@winehq.org Reporter: eaglecomputers.ok@gmail.com Distribution: ---
Game freezes completely when loading into the new zone, if DX12 is being used, but works fine if you use DX11 with DXVK.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #1 from Steve Ebey eaglecomputers.ok@gmail.com --- also wondering where to find vulkan headers for 1.113, since the official vulkan site shows the latest sdk is 1.108
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #2 from Henri Verbeet hverbeet@gmail.com --- The upstream vulkan-headers repository is at https://github.com/KhronosGroup/Vulkan-Headers. Likewise, the SPIRV-headers repository is at https://github.com/KhronosGroup/SPIRV-Headers.
https://bugs.winehq.org/show_bug.cgi?id=47471
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be Summary|World of Warcraft, 8.2.0 |World of Warcraft 8.2.0 |New zone Nazjatar |freezes when entering New | |zone Nazjatar
https://bugs.winehq.org/show_bug.cgi?id=47471
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|World of Warcraft 8.2.0 |World of Warcraft 8.2.0 |freezes when entering New |freezes when entering New |zone Nazjatar |zone Nazjatar (directx 12)
https://bugs.winehq.org/show_bug.cgi?id=47471
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #3 from Józef Kucia joseph.kucia@gmail.com --- Could you try to get a VKD3D_DEBUG log? Is the bug easily reproducible with a free WoW account?
https://bugs.winehq.org/show_bug.cgi?id=47471
Steve Ebey eaglecomputers.ok@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eaglecomputers.ok@gmail.com
--- Comment #4 from Steve Ebey eaglecomputers.ok@gmail.com --- Created attachment 64865 --> https://bugs.winehq.org/attachment.cgi?id=64865 Log capture, of a character on Nazjatar and I try to log in to that character
shows the fixme for the freeze that happens with a character on Nazjatar. This zone was added in patch 8.2 of WoW BFA, and is the only place that vkd3d will not work. I can run dx12 everyhere else in game.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #5 from Steve Ebey eaglecomputers.ok@gmail.com --- I do not think a free account will let you go to Naz, as the game requires level 120 characters, to see the zone.
https://bugs.winehq.org/show_bug.cgi?id=47471
Sveinar Søpler cybermax@dexter.no changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cybermax@dexter.no
--- Comment #6 from Sveinar Søpler cybermax@dexter.no --- @Steve Ebey Are you able to log in AT ALL with wine-staging-4.12.1 ? Battle.net is just a black square for me (since its running d3d11). Other d3d11 things like Unigine benchmarks are also just black for me with wined3d.
Wine-staging-4.11 works fine tho, and wine-staging-4.12.1 with DXVK.
I will get around to testing Nazjatar with vkd3d shortly and report back.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #7 from Sveinar Søpler cybermax@dexter.no --- Created attachment 64876 --> https://bugs.winehq.org/attachment.cgi?id=64876 Tracelog of crash
Since the regular "debug" log did not seem to interesting (the d3d12_command_queue_Wait: Failed to acquire Vulkan semaphore for fence was spammed when standing at the character select screen too).
https://bugs.winehq.org/show_bug.cgi?id=47471
Vasily Galkin galkin-vv@ya.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |galkin-vv@ya.ru
--- Comment #8 from Vasily Galkin galkin-vv@ya.ru --- Created attachment 64912 --> https://bugs.winehq.org/attachment.cgi?id=64912 vkd3d traces near the hang (10 MB, several seconds, with relative timestamps)
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.'
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #9 from Steve Ebey eaglecomputers.ok@gmail.com --- after most recent commit, i get the error spirv headers too old. How can I fix this. Running fedora 30 and downloaded the current spirv headers.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #10 from Józef Kucia joseph.kucia@gmail.com --- (In reply to Steve Ebey from comment #9)
after most recent commit, i get the error spirv headers too old. How can I fix this. Running fedora 30 and downloaded the current spirv headers.
You can get the latest SPIR-V headers from https://github.com/KhronosGroup/SPIRV-Headers. Other option is building with the latest Vulkan SDK: https://vulkan.lunarg.com/sdk/home. Vulkan SDK 1.1.114.0 has support for VK_EXT_shader_demote_to_helper_invocation and VK_EXT_texel_buffer_alignment.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #11 from Steve Ebey eaglecomputers.ok@gmail.com --- running latest sdk, downloaded from github for spirv, built and installed. Still fails, with spirv headers too old. Do I need to point to the folder with new spirv headers, or copy them to a specific folder for the build of vkd3d to work?
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #12 from Sveinar Søpler cybermax@dexter.no --- (In reply to Steve Ebey from comment #11)
running latest sdk, downloaded from github for spirv, built and installed. Still fails, with spirv headers too old. Do I need to point to the folder with new spirv headers, or copy them to a specific folder for the build of vkd3d to work?
Depending on distro, you either need to update packages with new spirv/vulkan - headers, or place it correctly.
Eg. For Ubuntu you can download the newest Vulkan SDK from LunarXchange here: https://vulkan.lunarg.com/sdk/home#linux. Follow the howto for Ubuntu package to install Vulkan SDK 1.1.114
OR, you can download the vulkan headers and spirv-headers from GIT, and place them (depending on distro) where your regular headers files are - typically: /usr/include/spirv
PS. Follow the folder structure in the GIT repo : /include/spirv and you should see the same header files. and folders to replace (1.0, 1.1, 1.2 and unified1).
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #13 from Steve Ebey eaglecomputers.ok@gmail.com --- did that, no change. maybe fedora does something different, it looks like it tries to run configure repeatedly, testing for spirv header version, before it gives up. does this change mandate a different driver? I am using 430.34 main driver, should I be running beta driver from vulkan developer site?
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #14 from Sveinar Søpler cybermax@dexter.no --- (In reply to Steve Ebey from comment #13)
did that, no change. maybe fedora does something different, it looks like it tries to run configure repeatedly, testing for spirv header version, before it gives up. does this change mandate a different driver? I am using 430.34 main driver, should I be running beta driver from vulkan developer site?
Driver does not matter when building.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #15 from Steve Ebey eaglecomputers.ok@gmail.com --- is SpvCapabilityDemoteToHelperInvocationEXT supposed to be in one of the files from the spirv header? I could not find it in any of the files, in the unified1 folder.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #16 from Sveinar Søpler cybermax@dexter.no --- (In reply to Steve Ebey from comment #15)
is SpvCapabilityDemoteToHelperInvocationEXT supposed to be in one of the files from the spirv header? I could not find it in any of the files, in the unified1 folder.
Yes. /usr/include/spirv$ grep -rni -e 'SpvCapabilityDemoteToHelperInvocationEXT' unified1/spirv.h:853: SpvCapabilityDemoteToHelperInvocationEXT = 5379,
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #17 from Steve Ebey eaglecomputers.ok@gmail.com --- none of the spirv.h on my computer, even from the github, have that line in them. I have looked at the code on the github site and also can not find it there. Is there another commit that I need to have. I have the latest vulkan sdk and github that you provided I downloaded spirv 1.4.1.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #18 from Sveinar Søpler cybermax@dexter.no --- (In reply to Steve Ebey from comment #17)
none of the spirv.h on my computer, even from the github, have that line in them. I have looked at the code on the github site and also can not find it there. Is there another commit that I need to have. I have the latest vulkan sdk and github that you provided I downloaded spirv 1.4.1.
Well.. i find that very odd.
git clone https://github.com/KhronosGroup/SPIRV-Headers.git cd SPIRV-Headers grep -rni -e 'SpvCapabilityDemoteToHelperInvocationEXT' include/spirv/unified1/spirv.h:854: SpvCapabilityDemoteToHelperInvocationEXT = 5379,
I just did that now.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #19 from Sveinar Søpler cybermax@dexter.no --- (In reply to Sveinar Søpler from comment #18)
(In reply to Steve Ebey from comment #17)
none of the spirv.h on my computer, even from the github, have that line in them. I have looked at the code on the github site and also can not find it there. Is there another commit that I need to have. I have the latest vulkan sdk and github that you provided I downloaded spirv 1.4.1.
Well.. i find that very odd.
git clone https://github.com/KhronosGroup/SPIRV-Headers.git cd SPIRV-Headers grep -rni -e 'SpvCapabilityDemoteToHelperInvocationEXT' include/spirv/unified1/spirv.h:854: SpvCapabilityDemoteToHelperInvocationEXT = 5379,
I just did that now.
https://github.com/KhronosGroup/SPIRV-Headers/blob/master/include/spirv/unif...
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #20 from Steve Ebey eaglecomputers.ok@gmail.com --- (In reply to Sveinar Søpler from comment #16)
(In reply to Steve Ebey from comment #15)
is SpvCapabilityDemoteToHelperInvocationEXT supposed to be in one of the files from the spirv header? I could not find it in any of the files, in the unified1 folder.
Yes. /usr/include/spirv$ grep -rni -e 'SpvCapabilityDemoteToHelperInvocationEXT' unified1/spirv.h:853: SpvCapabilityDemoteToHelperInvocationEXT = 5379,
Commits on Jul 02, 2019 @jeffbolznv jeffbolznv add SPV_EXT_demote_to_helper_invocation dcce859
cloned the git, built and installed the headers, everything compiled now. The link to the 1.4.1 was created May 18th. as shown, the line you are looking for, was added July 2, that is why nothing I had contained it. Thanks for pointing me in the right direction.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #21 from Henri Verbeet hverbeet@gmail.com --- (In reply to Steve Ebey from comment #17)
there. Is there another commit that I need to have. I have the latest vulkan sdk and github that you provided I downloaded spirv 1.4.1.
The version of the SPIR-V headers with SpvCapabilityDemoteToHelperInvocationEXT doesn't have an official release yet. I think that's unfortunate, and probably something we should avoid in the future.
It's kind of ok at the moment because the version of vkd3d that requires those headers isn't a released version either, but it does mean a potential upcoming vkd3d release would be blocked on that.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #22 from Steve Ebey eaglecomputers.ok@gmail.com --- after updating, and building, still not able to move in Nazjatar.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #23 from Sveinar Søpler cybermax@dexter.no --- (In reply to Henri Verbeet from comment #21)
(In reply to Steve Ebey from comment #17)
there. Is there another commit that I need to have. I have the latest vulkan sdk and github that you provided I downloaded spirv 1.4.1.
The version of the SPIR-V headers with SpvCapabilityDemoteToHelperInvocationEXT doesn't have an official release yet. I think that's unfortunate, and probably something we should avoid in the future.
It's kind of ok at the moment because the version of vkd3d that requires those headers isn't a released version either, but it does mean a potential upcoming vkd3d release would be blocked on that.
That kinda depends on what you consider a "release", cos lets face it: NOTHING is really a "release", it all depends on who "releases" it.
LunarG DID release Vulkan SDK 1.1.114 that HAS these headers. Is that NOT a "release"? Or is only releases counted as "distro releases"? Cos then we are in a world of crap, since currently only beta of the "debian/*buntu" flavor is able to consider building vkd3d.
I dunno. "Release" is just an arbitrary consideration seen from a certain viewpoint.
https://bugs.winehq.org/show_bug.cgi?id=47471
Steve Ebey eaglecomputers.ok@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #64865|0 |1 is obsolete| |
--- Comment #24 from Steve Ebey eaglecomputers.ok@gmail.com --- Created attachment 64985 --> https://bugs.winehq.org/attachment.cgi?id=64985 ran with vkd3d debug on
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #25 from Sveinar Søpler cybermax@dexter.no --- Anything you need to troubleshoot this better Józef Kucia? Logs/tests that could help out fixing this.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #26 from Józef Kucia joseph.kucia@gmail.com --- (In reply to Sveinar Søpler from comment #25)
Anything you need to troubleshoot this better Józef Kucia? Logs/tests that could help out fixing this.
The issue is most probably caused by an uninitialized descriptor. Logs aren't detailed enough to pinpoint the culprit. Vulkan validation layers might confirm that this is caused by not updated descriptors. You probably want to run with VKD3D_CONFIG=vk_debug when using validation layers.
https://wiki.winehq.org/Vkd3d#Vulkan_validation_layers
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #27 from Sveinar Søpler cybermax@dexter.no --- Created attachment 65000 --> https://bugs.winehq.org/attachment.cgi?id=65000 Attempt vk_debug log
I am sorry, but trying to log stuff (for me atleast) using this only result in a fatal exeption and a crash/hang before being able to log in.
I have not (yet) figured out how to launch Wow.exe directly WITHOUT using the battle.net launcher app, so i dunno if that comes to play when using these validation layers?
Logging with VKD3D_DEBUG=trace or whatnot still works, and still crashes when zoning in, but using the vulkan validation layers seems to do something iffy that causes a hang at the character select screen.
Attaching what i got from the log before hanging at character select screen in case that could be of any use
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #28 from Steve Ebey eaglecomputers.ok@gmail.com --- (In reply to Sveinar Søpler from comment #27)
Created attachment 65000 [details] Attempt vk_debug log
I am sorry, but trying to log stuff (for me atleast) using this only result in a fatal exeption and a crash/hang before being able to log in.
I have not (yet) figured out how to launch Wow.exe directly WITHOUT using the battle.net launcher app, so i dunno if that comes to play when using these validation layers?
Logging with VKD3D_DEBUG=trace or whatnot still works, and still crashes when zoning in, but using the vulkan validation layers seems to do something iffy that causes a hang at the character select screen.
Attaching what i got from the log before hanging at character select screen in case that could be of any use
There is a command line script, to run WoW with dx12, and not use the launcher. It is on the app db page for wow 8.2 and is what I use to start the game. it includes setting library and environment variables, so adding the vk_debug should be easy. I will also try to capture a log, and if successful, upload it here.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #29 from Sveinar Søpler cybermax@dexter.no --- (In reply to Steve Ebey from comment #28)
(In reply to Sveinar Søpler from comment #27)
Created attachment 65000 [details] Attempt vk_debug log
I am sorry, but trying to log stuff (for me atleast) using this only result in a fatal exeption and a crash/hang before being able to log in.
I have not (yet) figured out how to launch Wow.exe directly WITHOUT using the battle.net launcher app, so i dunno if that comes to play when using these validation layers?
Logging with VKD3D_DEBUG=trace or whatnot still works, and still crashes when zoning in, but using the vulkan validation layers seems to do something iffy that causes a hang at the character select screen.
Attaching what i got from the log before hanging at character select screen in case that could be of any use
There is a command line script, to run WoW with dx12, and not use the launcher. It is on the app db page for wow 8.2 and is what I use to start the game. it includes setting library and environment variables, so adding the vk_debug should be easy. I will also try to capture a log, and if successful, upload it here.
I am able to run Wow.exe directly without launcher if i set the wineprefix to Windows 7 instead of Windows 10. I kinda lived with the impression it was "wiser" to use Windows 10 when using D3D12 (as D3D12 is not really a feature of Windows 7... but wine does perhaps not care much about that).
I can do some more tests to see if that vk_debug thing plays nicer with the wineprefix set to Windows 7 when i get home later.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #30 from Sveinar Søpler cybermax@dexter.no --- Right. When starting Wow.exe directly with: wine "./Wow.exe" "-d3d12" the following happens:
If my wineprefix is set to Windows 10, i get a BLZ51914003 error after typing my password (instead of asking for my authenticator code). If my wineprefix is set to Windows 7, the authenticator code is asked for and i can log in just fine.
Setting it to Windows 7, and running with: export VKD3D_CONFIG=vk_debug export VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_standard_validation export VKD3D_DEBUG=debug
Wow crashes at the character select screen with a Error #132: Fatal exception
The log ends in: fixme:d3d12_command_queue_Wait: Failed to acquire Vulkan semaphore for fence 0x555555f980d0, value 0x1be0, completed value 0x1bdf. fixme:d3d12_command_queue_Wait: Failed to acquire Vulkan semaphore for fence 0x555555f980d0, value 0x1be1, completed value 0x1be0. fixme:d3d12_command_queue_Wait: Failed to acquire Vulkan semaphore for fence 0x555555f980d0, value 0x1be2, completed value 0x1be1. fixme:d3d12_command_queue_Wait: Failed to acquire Vulkan semaphore for fence 0x555555f980d0, value 0x1be3, completed value 0x1be2. 002d:fixme:seh:dwarf_get_ptr unsupported encoding 9b 002d:fixme:seh:dwarf_get_ptr unsupported encoding 8e 002d:fixme:seh:dwarf_get_ptr unsupported encoding 0e 002d:fixme:seh:dwarf_get_ptr unsupported encoding e9 002d:fixme:seh:dwarf_get_ptr unsupported encoding 9b 002d:fixme:seh:dwarf_get_ptr unsupported encoding 8e 002d:fixme:seh:dwarf_get_ptr unsupported encoding 0e 002d:fixme:seh:dwarf_get_ptr unsupported encoding e9 002d:fixme:seh:dwarf_get_ptr unsupported encoding 9b 002d:fixme:seh:dwarf_get_ptr unsupported encoding 8e 002d:fixme:seh:dwarf_get_ptr unsupported encoding 0e 002d:fixme:seh:dwarf_get_ptr unsupported encoding e9 002d:fixme:seh:valid_reg unsupported reg 58 002d:fixme:seh:execute_cfa_instructions 8c5: unknown CFA opcode 2e 002d:fixme:seh:valid_reg unsupported reg 60 002d:fixme:seh:execute_cfa_instructions a64: unknown CFA opcode 2e 002d:fixme:seh:valid_reg unsupported reg 65 ACCESS_VIOLATION : error 132: ERROR #132 (0x85100084) Fatal exception! The instruction at "0x00007fec16ac14f8" referenced memory at "0x0000000000000110". The memory could not be "read".
009b:fixme:heap:GetPhysicallyInstalledSystemMemory stub: 0x33efb4 009b:fixme:heap:GetPhysicallyInstalledSystemMemory stub: 0x33efb4 009b:fixme:ntdll:NtQuerySystemInformationEx Relationship filtering not implemented: 0x3 009b:fixme:ntdll:NtQuerySystemInformationEx Relationship filtering not implemented: 0x3 009c:fixme:ver:GetCurrentPackageId (0xa2feec (nil)): stub
(Basically the same as launching through battle.net launcher).
So i guess there is something else at play here? Some other option i have missed?
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #31 from Sveinar Søpler cybermax@dexter.no --- Just to be clear tho - I can run Wow.exe directly with wineprefix set to Windows 7 like i described but with:
export WINEDEBUG="-all" export VKD3D_DEBUG=none
And it runs d3d12 with vkd3d in eg. Boralus like before.
Ref the Wow/_retail_/Logs/gx.log 8/6 15:15:55.874 LogOpen 8/6 15:15:56.492 Adapter 0: "NVIDIA GeForce RTX 2070" vendor:0x10de device:0x1f07 driver(0x80012, 0xd0fd4) dx11:true dx12:true 8/6 15:15:56.509 Monitor 0 "\.\DISPLAY1" (1920x1080) 8/6 15:15:56.514 D3d12 Device Create 8/6 15:15:56.608 Taking Adapter 0 by name: "NVIDIA GeForce RTX 2070" 8/6 15:15:56.614 Choosing adapter 0 8/6 15:15:56.664 Wine detected, skipping NvAPI/ADL loading 8/6 15:15:56.668 AFR Groups: 1/1 8/6 15:15:56.671 Feature Level: DX=3, MTL=0 8/6 15:15:56.681 NotifyOnDeviceCreate 8/6 15:15:56.684 D3d12 Device Create Successful 8/6 15:15:56.688 <IsGPUDriverOutOfDate> No 8/6 15:15:56.721 CPU Processor Detection: 12 H/W threads 8/6 15:15:56.724 Memory Detection: 16749035520 bytes of physical memory available 8/6 15:15:56.728 Detected Graphics Defaults: 6 (CPU = 6, GPU = 6, MEM = 6) 8/6 15:15:56.814 RenderSettings::NotifyChanged 8/6 15:16:50.300 D3d12 Device Destroy 8/6 15:16:50.304 NotifyOnDeviceDestroy 8/6 15:16:50.630 GxShutdown
PS. I noticed something NEW today: 8/6 15:15:56.664 Wine detected, skipping NvAPI/ADL loading
So WoW being "wine friendly"? :)
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #32 from Steve Ebey eaglecomputers.ok@gmail.com --- Created attachment 65020 --> https://bugs.winehq.org/attachment.cgi?id=65020 Error Log, zoning into Nazjatar from character select screen
When I logged with trace, produced a log of over 4 million lines, before getting to the error messages, just from starting the game, and logging into my account, then loading my character, who is at Nazjatar. This is taken from a fresh git pull, and vkd3d works everywhere except for this new zone. Changed from trace reporting to error reporting, to make a more manageable log file.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #33 from Steve Ebey eaglecomputers.ok@gmail.com --- When I add the vk validation to my script, it also crashed with 132 error, memory could not be read. I can comment out the line for vk validation, and it loads and runs, until I go to Nazjatar.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #34 from Sveinar Søpler cybermax@dexter.no --- I think Mr. Kucia is on vacation... Or he is busy leveling to 120 so he can enter Nazjatar :)
Let us know if there is something else to test, since it seems WoW is not too fond of running with the validation layers.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #35 from Sveinar Søpler cybermax@dexter.no --- Created attachment 65359 --> https://bugs.winehq.org/attachment.cgi?id=65359 debug log
After the passing of Mr. Kucia, i don't know who will take a look at this, but the bug is still there.
I uploaded a log with: +dxgi,+d3d12 VKD3D_DEBUG=trace VKD3D_SHADER_DEBUG=trace
in the hopes that it could provide some clue.
I am (as pointed out a few posts up) not able to run WoW with VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_standard_validation without crashing before being able to enter the world. (Crash at character select screen).
Let me know if there is something else to try.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #36 from Matteo Bruni matteo.mystral@gmail.com --- Sveinar, you said on the mailing list that this bug is not reproducible anymore, correct?
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #37 from Steve Ebey eaglecomputers.ok@gmail.com --- (In reply to Matteo Bruni from comment #36)
Sveinar, you said on the mailing list that this bug is not reproducible anymore, correct?
as far as I know the bug still exists, once i try to go to the zone in question, the game freezes.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #38 from Sveinar Søpler cybermax@dexter.no --- (In reply to Matteo Bruni from comment #36)
Sveinar, you said on the mailing list that this bug is not reproducible anymore, correct?
This was fixed with the root signature update 1.1 patch here: https://source.winehq.org/git/vkd3d.git/commitdiff/c002aee119b638d30eeb7cdc9...
This requires wine-staging patch: https://www.winehq.org/pipermail/wine-devel/2019-October/152356.html
Steve Ebey: Are you sure you have tested latest GIT + that wine patch?
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #39 from Steve Ebey eaglecomputers.ok@gmail.com --- (In reply to Sveinar Søpler from comment #38)
(In reply to Matteo Bruni from comment #36)
Sveinar, you said on the mailing list that this bug is not reproducible anymore, correct?
This was fixed with the root signature update 1.1 patch here: https://source.winehq.org/git/vkd3d.git/commitdiff/ c002aee119b638d30eeb7cdc91099449ccafeafc
This requires wine-staging patch: https://www.winehq.org/pipermail/wine-devel/2019-October/152356.html
Steve Ebey: Are you sure you have tested latest GIT + that wine patch?
yes, to latest on all gits, and now, when I even try to run dx12 the game crashs before it even loads, with error 132. I have to compile without mingw and I do not understand why that is. i used to be able to compile with mingw, but since 4.10 I have had issues with mingw throwing segment faults, when it gets to a certain part of the compile for the 64bit portion of wine. I am starting a new job, so time to test will be sparse for me, until the college I work at takes the Christmas break. During Christmas break, about 2 weeks long, I will have unrestricted access to 20+ computers, that I can test various combinations of hardware and distros, to see what is going on with wine. I run Fedora, as that one seems to give me the least amount of problems. I will try Nvidia and AMD cards, intel and amd cpus, and find what works best.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #40 from Sveinar Søpler cybermax@dexter.no --- (In reply to Steve Ebey from comment #39)
(In reply to Sveinar Søpler from comment #38)
(In reply to Matteo Bruni from comment #36)
Sveinar, you said on the mailing list that this bug is not reproducible anymore, correct?
This was fixed with the root signature update 1.1 patch here: https://source.winehq.org/git/vkd3d.git/commitdiff/ c002aee119b638d30eeb7cdc91099449ccafeafc
This requires wine-staging patch: https://www.winehq.org/pipermail/wine-devel/2019-October/152356.html
Steve Ebey: Are you sure you have tested latest GIT + that wine patch?
yes, to latest on all gits, and now, when I even try to run dx12 the game crashs before it even loads, with error 132. I have to compile without mingw and I do not understand why that is. i used to be able to compile with mingw, but since 4.10 I have had issues with mingw throwing segment faults, when it gets to a certain part of the compile for the 64bit portion of wine. I am starting a new job, so time to test will be sparse for me, until the college I work at takes the Christmas break. During Christmas break, about 2 weeks long, I will have unrestricted access to 20+ computers, that I can test various combinations of hardware and distros, to see what is going on with wine. I run Fedora, as that one seems to give me the least amount of problems. I will try Nvidia and AMD cards, intel and amd cpus, and find what works best.
Wine REQUIRES https://www.winehq.org/pipermail/wine-devel/2019-October/152356.html to not crash. This is a patch not in GIT.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #41 from Steve Ebey eaglecomputers.ok@gmail.com --- (In reply to Sveinar Søpler from comment #40)
(In reply to Steve Ebey from comment #39)
(In reply to Sveinar Søpler from comment #38)
(In reply to Matteo Bruni from comment #36)
Sveinar, you said on the mailing list that this bug is not reproducible anymore, correct?
This was fixed with the root signature update 1.1 patch here: https://source.winehq.org/git/vkd3d.git/commitdiff/ c002aee119b638d30eeb7cdc91099449ccafeafc
This requires wine-staging patch: https://www.winehq.org/pipermail/wine-devel/2019-October/152356.html
Steve Ebey: Are you sure you have tested latest GIT + that wine patch?
yes, to latest on all gits, and now, when I even try to run dx12 the game crashs before it even loads, with error 132. I have to compile without mingw and I do not understand why that is. i used to be able to compile with mingw, but since 4.10 I have had issues with mingw throwing segment faults, when it gets to a certain part of the compile for the 64bit portion of wine. I am starting a new job, so time to test will be sparse for me, until the college I work at takes the Christmas break. During Christmas break, about 2 weeks long, I will have unrestricted access to 20+ computers, that I can test various combinations of hardware and distros, to see what is going on with wine. I run Fedora, as that one seems to give me the least amount of problems. I will try Nvidia and AMD cards, intel and amd cpus, and find what works best.
Wine REQUIRES https://www.winehq.org/pipermail/wine-devel/2019-October/152356.html to not crash. This is a patch not in GIT.
tried using copy and paste to apply the patch, have had no luck, can someone make a zip file, and attach it here, please?
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #42 from Sveinar Søpler cybermax@dexter.no --- Created attachment 65754 --> https://bugs.winehq.org/attachment.cgi?id=65754 Root signature patch for wine-staging
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #43 from Steve Ebey eaglecomputers.ok@gmail.com --- (In reply to Sveinar Søpler from comment #42)
Created attachment 65754 [details] Root signature patch for wine-staging
thank you, but when i apply the patch, and compile, it does not finish compiling. no error messages are presented, but it never shows the message wine build complete, and instead it stops even before the 32 bit compile for the wine shared build, per the shared build instructions from the wiki on winehq.org.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #44 from Sveinar Søpler cybermax@dexter.no --- (In reply to Steve Ebey from comment #43)
(In reply to Sveinar Søpler from comment #42)
Created attachment 65754 [details] Root signature patch for wine-staging
thank you, but when i apply the patch, and compile, it does not finish compiling. no error messages are presented, but it never shows the message wine build complete, and instead it stops even before the 32 bit compile for the wine shared build, per the shared build instructions from the wiki on winehq.org.
What distro are you compiling for?
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #45 from Steve Ebey eaglecomputers.ok@gmail.com --- (In reply to Sveinar Søpler from comment #44)
(In reply to Steve Ebey from comment #43)
(In reply to Sveinar Søpler from comment #42)
Created attachment 65754 [details] Root signature patch for wine-staging
thank you, but when i apply the patch, and compile, it does not finish compiling. no error messages are presented, but it never shows the message wine build complete, and instead it stops even before the 32 bit compile for the wine shared build, per the shared build instructions from the wiki on winehq.org.
What distro are you compiling for?
fedora 31 with nvidia gtx970
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #46 from Sveinar Søpler cybermax@dexter.no --- (In reply to Steve Ebey from comment #45)
(In reply to Sveinar Søpler from comment #44)
(In reply to Steve Ebey from comment #43)
(In reply to Sveinar Søpler from comment #42)
Created attachment 65754 [details] Root signature patch for wine-staging
thank you, but when i apply the patch, and compile, it does not finish compiling. no error messages are presented, but it never shows the message wine build complete, and instead it stops even before the 32 bit compile for the wine shared build, per the shared build instructions from the wiki on winehq.org.
What distro are you compiling for?
fedora 31 with nvidia gtx970
Without knowing any particularities for compiling with Fedora, the wine compile does most likely not "just stop".. If you scroll far enough up and view the output i would bet there is a error some place. It just LOOKS like it just stops for no reason.
You could do a : make -j4 2>&1 | tee build.log and zip/attach the log file here and ill look at it.. PS. Replace "-j4 with whatever amount of cores ofc.. -j12 for my 8700K)
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #47 from Steve Ebey eaglecomputers.ok@gmail.com --- Created attachment 65765 --> https://bugs.winehq.org/attachment.cgi?id=65765 Logs and build script for my issues with the D3D patch
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #48 from Sveinar Søpler cybermax@dexter.no --- (In reply to Steve Ebey from comment #47)
Created attachment 65765 [details] Logs and build script for my issues with the D3D patch
It seems as you do not have a recent vkd3d package (system?) installed, as the linker tries to link to a symbol that does not exist.
/usr/bin/ld: d3d12_main.o: in function `D3D12SerializeVersionedRootSignature': d3d12_main.c:(.text+0xcae): undefined reference to `vkd3d_serialize_versioned_root_signature' collect2: error: ld returned 1 exit status winegcc: gcc failed make[1]: *** [Makefile:223: d3d12.dll.so] Error 2 make[1]: Leaving directory '/home/steve/wine-dirs/wine64-build/dlls/d3d12' make: *** [Makefile:8489: dlls/d3d12] Error 2 make: *** Waiting for unfinished jobs....
This is what fails during build.
I would assume you have libvkd3d-dev installed via some system-dev package perhaps? And even tho you build vkd3d yourself with GIT, something may have failed when installing this, and the old Fedora system version is used
Since i build my own Ubuntu system packages, this build does not fail for me. I tested this on a clean VM of Ubuntu 19.04 with default libvkd3d, and it failed at the same spot, but upon upgrading the vkd3d packages, the compile went fine.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #49 from Sveinar Søpler cybermax@dexter.no --- @Steve Ebay
Example: /usr/include/vkd3d.h
GIT version: cat vkd3d.h | grep -i vkd3d_serialize
vkd3d.h:183:HRESULT vkd3d_serialize_root_signature(const D3D12_ROOT_SIGNATURE_DESC *desc, vkd3d.h:194:HRESULT vkd3d_serialize_versioned_root_signature(const D3D12_VERSIONED_ROOT_SIGNATURE_DESC *desc, vkd3d.h:226:typedef HRESULT (*PFN_vkd3d_serialize_root_signature)(const D3D12_ROOT_SIGNATURE_DESC *desc, vkd3d.h:237:typedef HRESULT (*PFN_vkd3d_serialize_versioned_root_signature)(const D3D12_VERSIONED_ROOT_SIGNATURE_DESC *desc,
Ubuntu Eoan release vkd3d.h: cat vkd3d.h | grep -i vkd3d_serialize
HRESULT vkd3d_serialize_root_signature(const D3D12_ROOT_SIGNATURE_DESC *desc, typedef HRESULT (*PFN_vkd3d_serialize_root_signature)(const D3D12_ROOT_SIGNATURE_DESC *desc,
The vkd3d headers is in (atleast for Ubuntu/debian) the -dev package. If you do not replace the system provided headers with your custom compiled GIT vkd3d headers, the wine compile with the patch will fail.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #50 from Steve Ebey eaglecomputers.ok@gmail.com --- (In reply to Sveinar Søpler from comment #49)
@Steve Ebay
Example: /usr/include/vkd3d.h
GIT version: cat vkd3d.h | grep -i vkd3d_serialize
vkd3d.h:183:HRESULT vkd3d_serialize_root_signature(const D3D12_ROOT_SIGNATURE_DESC *desc, vkd3d.h:194:HRESULT vkd3d_serialize_versioned_root_signature(const D3D12_VERSIONED_ROOT_SIGNATURE_DESC *desc, vkd3d.h:226:typedef HRESULT (*PFN_vkd3d_serialize_root_signature)(const D3D12_ROOT_SIGNATURE_DESC *desc, vkd3d.h:237:typedef HRESULT (*PFN_vkd3d_serialize_versioned_root_signature)(const D3D12_VERSIONED_ROOT_SIGNATURE_DESC *desc,
Ubuntu Eoan release vkd3d.h: cat vkd3d.h | grep -i vkd3d_serialize
HRESULT vkd3d_serialize_root_signature(const D3D12_ROOT_SIGNATURE_DESC *desc, typedef HRESULT (*PFN_vkd3d_serialize_root_signature)(const D3D12_ROOT_SIGNATURE_DESC *desc,
The vkd3d headers is in (atleast for Ubuntu/debian) the -dev package. If you do not replace the system provided headers with your custom compiled GIT vkd3d headers, the wine compile with the patch will fail.
ok, new twist. I do a fresh pull of wine and wine-staging git, and without applying the patch, try to compile, and it dies during compilation, with same message about missing reference. I have tested for the right vkd3d.h with your grep test, and it is there. I have removed the distro version, built vkd3d from git source, and updated the library files with ldtool. i am at a loss as to how to proceed now.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #51 from Sveinar Søpler cybermax@dexter.no --- (In reply to Steve Ebey from comment #50)
ok, new twist. I do a fresh pull of wine and wine-staging git, and without applying the patch, try to compile, and it dies during compilation, with same message about missing reference. I have tested for the right vkd3d.h with your grep test, and it is there. I have removed the distro version, built vkd3d from git source, and updated the library files with ldtool. i am at a loss as to how to proceed now.
Well, there is no indication that d3d12 is touched in wine or wine-staging, so i very much doubt you are running a "clean git". By saying "doing i fresh pull" i MUST assume you are doing a "git clone https://github.com/wine-mirror/wine.git" to a completely empty folder, and not just doing a "pull". (If you have patched files in YOUR local git tree, doing a pull does not replace, unless you go through some hoops of git reset --hard upstream/master and the likes.)
Yeah, you can reset your local git folder in many ways, but if you have "tainted" your local folder by adding patches, the easiest approach when having errors that should not be there is to just simply delete the folder and do a new clone. Unless ofc you have loads of work in local branches and such ofc. Then clone it in a different temp folder of your choosing.
I have not tested the patches on GIT tho, so if you aim to have the same experience as i have, you could also just download the wine-4.20 release and wine-staging-4.20 release file.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #52 from Steve Ebey eaglecomputers.ok@gmail.com --- (In reply to Sveinar Søpler from comment #51)
(In reply to Steve Ebey from comment #50)
ok, new twist. I do a fresh pull of wine and wine-staging git, and without applying the patch, try to compile, and it dies during compilation, with same message about missing reference. I have tested for the right vkd3d.h with your grep test, and it is there. I have removed the distro version, built vkd3d from git source, and updated the library files with ldtool. i am at a loss as to how to proceed now.
Well, there is no indication that d3d12 is touched in wine or wine-staging, so i very much doubt you are running a "clean git". By saying "doing i fresh pull" i MUST assume you are doing a "git clone https://github.com/wine-mirror/wine.git" to a completely empty folder, and not just doing a "pull". (If you have patched files in YOUR local git tree, doing a pull does not replace, unless you go through some hoops of git reset --hard upstream/master and the likes.)
Yeah, you can reset your local git folder in many ways, but if you have "tainted" your local folder by adding patches, the easiest approach when having errors that should not be there is to just simply delete the folder and do a new clone. Unless ofc you have loads of work in local branches and such ofc. Then clone it in a different temp folder of your choosing.
I have not tested the patches on GIT tho, so if you aim to have the same experience as i have, you could also just download the wine-4.20 release and wine-staging-4.20 release file.
clear echo Cleanup and fresh download of repositories needed rm -fr wine rm -fr wine-staging echo WineHQ Devel Source Git git clone https://github.com/wine-mirror/wine.git echo Unoffical Wine Staging Git git clone https://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
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #53 from Sveinar Søpler cybermax@dexter.no --- (In reply to Steve Ebey from comment #52)
clear echo Cleanup and fresh download of repositories needed rm -fr wine rm -fr wine-staging echo WineHQ Devel Source Git git clone https://github.com/wine-mirror/wine.git echo Unoffical Wine Staging Git git clone https://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
This is the script you are using to pull the sources yes? And you still get the same error as before doing that?
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #54 from Steve Ebey eaglecomputers.ok@gmail.com --- (In reply to Sveinar Søpler from comment #53)
(In reply to Steve Ebey from comment #52)
clear echo Cleanup and fresh download of repositories needed rm -fr wine rm -fr wine-staging echo WineHQ Devel Source Git git clone https://github.com/wine-mirror/wine.git echo Unoffical Wine Staging Git git clone https://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
This is the script you are using to pull the sources yes? And you still get the same error as before doing that?
yes, to both questions. it seems, the vkd3d after being built, is not updating the lib file in Fedora. do I need to use libtool to force vkd3d to update the library? if so, what is the command for libtool that I need to use?
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #55 from Sveinar Søpler cybermax@dexter.no --- (In reply to Steve Ebey from comment #54)
yes, to both questions. it seems, the vkd3d after being built, is not updating the lib file in Fedora. do I need to use libtool to force vkd3d to update the library? if so, what is the command for libtool that I need to use?
Chances are that the default install option when building vkd3d is not the same as the Fedora package uses. I do not use fedora, but if you check where the libraries and header files is installed now maybe you can figure it out?
What do you get if you do "sudo updatedb" and then "locate vkd3d.h" You should get one of them in your git source folder and one someplace in the system folders.
eg. /home/steve/vkd3d/include/vkd3d.h (this is your GIT source) /usr/include/vkd3d/vkd3d.h (this is the system folder)
If so, do they match? "diff -u /home/steve/vkd3d/include/vkd3d.h /usr/include/vkd3d/vkd3d.h
If you find them in two "system" places, you could either manually replace them, or find some configure option to fix it.
Two "system places" would mean something like: /usr/include/vkd3d/vkd3d.h /usr/local/include/vkd3d/vkd3d.h
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #56 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
@Steve Ebey & @Sveinar Søpler
Issues with using vkd3d and compiling on Fedora has nothing to do with the WoW freezing issue.
What you're doing is personal troubleshooting and it's boating this bug report.
Could you please move your discussion somewhere else?
Regards.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #57 from Steve Ebey eaglecomputers.ok@gmail.com --- The fixes here allow me to use dx12 in nazjatar, but I have to turn off SSAO to get the screen flash to stop. It still shows distant textures as a solid flashing color. I am running gtx 1050 and it also does it on my gtx 970. Either one needs to have SSAO disabled, to get the screen flash to stop.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #58 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- (In reply to Steve Ebey from comment #57)
The fixes here allow me to use dx12 in nazjatar, but I have to turn off SSAO
Hello,
Thanks for the feedback.
(In reply to Sveinar Søpler from comment #38)
This was fixed with the root signature update 1.1 patch here: https://source.winehq.org/git/vkd3d.git/commitdiff/ c002aee119b638d30eeb7cdc91099449ccafeafc
This requires wine-staging patch: https://www.winehq.org/pipermail/wine-devel/2019-October/152356.html
Note to bug triaggers: The fix above depends on vkd3d 1.2.
This bug shouldn't be closed until version 1.2 of vkd3d gets released, and the patch rebased on that version committed (or staged if the patch gets in wine-staging).
Regards.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #59 from Steve Ebey eaglecomputers.ok@gmail.com --- have that patch, and have stated that SSAO being turned off makes the flashing stop, but I still have textures that are not being drawn. I have tried the cache cleanup and other troubleshooting tips. I have no flashing with SSAO enabled under DX11.
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #60 from Sveinar Søpler cybermax@dexter.no --- (In reply to Olivier F. R. Dierick from comment #58)
Note to bug triaggers: The fix above depends on vkd3d 1.2.
This bug shouldn't be closed until version 1.2 of vkd3d gets released, and the patch rebased on that version committed (or staged if the patch gets in wine-staging).
Regards.
I wonder who is going to release vkd3d_1.2?
WineHQ git of vkd3d has no commits since early december last year. There has been little/few commit-attempts on the mailing list last couple of months.
Yes, i do know of a vkd3d branch that are way past WineHQ branch tho, and things might be happening behind the scenes there perhaps? I dunno. Philip/Hans Kristian have quite a few commits to the vkd3d tree that Steam Proton have implemented along with the 2 wine patches in mention. That does not indicate it becoming mainline tho :)
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #61 from Steve Ebey eaglecomputers.ok@gmail.com --- tried the HK vkd3d, crashed immediately with Error #132. I have the latest vulkan beta nvidia driver, same as what you reference. Clean wine prefix, no dxvk installed, and it does not matter if the version is distro or self compiled.
https://bugs.winehq.org/show_bug.cgi?id=47471
jokeyrhyme@jokeyrhy.me changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jokeyrhyme@jokeyrhy.me
https://bugs.winehq.org/show_bug.cgi?id=47471
Ker noa blue-t@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |blue-t@web.de
--- Comment #62 from Ker noa blue-t@web.de --- This game version is no longer available, we should close this
https://bugs.winehq.org/show_bug.cgi?id=47471
--- Comment #63 from Sveinar Søpler cybermax@dexter.no --- (In reply to Ker noa from comment #62)
This game version is no longer available, we should close this
I am not sure the problem is fixed, even if the game version is no longer available.
I have not been able to get ingame with upstream vkd3d in quite a while, so afaik upstream vkd3d does not work with World of Warcraft >=8.2.0.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla