protonscr

Wow 8.1.5 slowing down

dxvkclosed can't reproduce
doitsujin/dxvk#978 · opened 2019-03-22 by jgmao · updated 2019-12-11 · 16 comments · github
Jjgmao 2019-03-22 github

With dxvk 1.0.1, wow 8.1.5 runs without crush. Great job. However, I observe another issue. If I play > 1h, wow will start slowing down (eg. fps drop and freeze several sec). This effect getting worse if keep playing. By quit and restart the game, wow back to normal. I highly suspect this is due to memory leakage.

Software information

World of Warcraft 8.1.5, installed with Lutris using dxvk 1.0.1
System information

GPU: GTX 1060 
Driver: Nvidia 418.43-5
Wine version: 4.2
DXVK version: 0.96 (Also tested on 1.0)

Apitrace file(s)

Put a link here

Log files
will update once I have access to the machine.
d3d11.log:

Ddoitsujin maintainer 2019-03-22 github

Can't reproduce on either my GTX 670 and RX 480, and I need more info.

  • What is the GPU utilization like when that happens?
  • How much VRAM is being used?
  • Does this happen on Windows?
  • Does this happen with the "D3D11 Legacy" renderer?
  • Why doesn't anyone else seem to have this problem?
  • If you suspect "memory leakage", have you actually checked memory usage?
DDehir 2019-03-22 github

Wow can occasionally start slowing down due Agent.Exe leaking backround/other normals processes leaking memory like firefox (pretty common). Also addons like Weakauras (which is the worst btw) can cause major memory leaks over time.

SSveSop 2019-03-23 github

Well tbh i have no clue if this is DXVK related, or "game related", but it has kind of "always" been like this.

I usually play up to 4 maybe 5 hours, and there is no "game breaking issues" when this happens, and there is no real way to pinpoint when or what causes this.

Eg. I log on, zone in i have say 110 fps hanging around in the town. Join a couple of raids, do some dailies and whatnot 2-3 hours or so, and zone back, i would have 95-100 fps. No huge issue, and as i said.. it has more or less "always been like this"... in windows too. Cant say i have experienced any "freezes", but increased "micro-stutter" sure.

Back in the day, before raiding, the usual standard was always to at least exit wow and log on again (preferred reboot of pc) exactly due to random issues like this. Nothing sux more than having a stutter-fest mid-raid. That part has actually gotten better over the years tho :)

The "Not game breaking" thing is more or less due to a lot better hardware than before, but might be more noticable if you run everything at ultra and 8xMSAA and whatnot, so one could experiment with this, and check vram usage over time to spot memory leaks perhaps? It would not be surprising if WoW had a few of them tho.

The new GIT>1.0.1 version is slightly lower performance wise than 1.0.1 tho (2% ish), but have not experienced huge problems with 1.0.1.

PS. I assume by using the Lutris installer, you use the "TKG" wine version with esync and all the bells and whistles?

Ddoitsujin maintainer 2019-03-23 github

@jgmao if you have any addons installed (like @Dehir mentioned), please uninstall them and test with a vanilla client. I cannot provide support for broken third-party software, especially when it's known to cause trouble even on Windows.

Eg. I log on, zone in i have say 110 fps hanging around in the town. Join a couple of raids, do some dailies and whatnot 2-3 hours or so, and zone back, i would have 95-100 fps.

What's limiting, CPU or GPU? If it's the CPU then this kind of makes sense, the game is rather dynamic and creates/destroys a lot of objects, which leads to memory fragmentation and growing lookup tables in DXVK, and probably some extra overhead on the game's side as well.

If it's the GPU, then that can happen too, although a 10% drop is quite substantial. Not sure why this happens, but I've noticed small slowdowns in SotTR as well when running the benchmark multiple times in a row.

Anyway, the original issue makes it sound like the game becomes completely unplayable. I've heard from a few players that they don't have the issue, so I assume it's not a general issue.

The new GIT>1.0.1 version is slightly lower performance wise than 1.0.1 tho (2% ish)

Latest git is expected to be slightly slower unless both your wine build and Vulkan driver support VK_EXT_host_query_reset. Since it's a very new extension you're probably hitting the slow path.

SSveSop 2019-03-23 github

@doitsujin

What's limiting, CPU or GPU? If it's the CPU then this kind of makes sense, the game is rather dynamic and creates/destroys a lot of objects, which leads to memory fragmentation and growing lookup tables in DXVK, and probably some extra overhead on the game's side as well.

I rarely if ever see any cpu/gpu limit, as WoW is rather notorious about "everything else" causing slowdowns tbh. MMO's and whatever package traffic server <-> client and other crap happening. But i must admit i have not checked the gpu utilization when stuff like that happens. Mostly need to look straight into a brick wall if you wanna peg the gpu 100%. The more entities and stuff flying around -> less gpu usage. Difference between windows and linux w/dxvk is that windows have lower gpu usage.

The only tests that CAN be somewhat doable is to fly the same route from a "fresh login" and compare averages between settings.

Latest git is expected to be slightly slower unless both your wine build and Vulkan driver support VK_EXT_host_query_reset. Since it's a very new extension you're probably hitting the slow path.

Ah, i think i mostly tested this with wine 4.4, and not latest git. Did test the 418.49.04 driver and it seemed even slower than the 418.56 driver. (I assume the 418.56 driver does not have this extension). Ill do some retests with the beta driver and a git version of Wine then :)

Ddoitsujin maintainer 2019-03-23 github

The only tests that CAN be somewhat doable is to fly the same route from a "fresh login" and compare averages between settings.

Well, the only thing I care about is whether or not your GPU load is close to 100%. In my experience, WoW performance heavily depends on CPU speed, which is also why there's such a massive difference between the new D3D11 and the D3D11 Legacy renderer in heavy scenes with Quality Preset 10.

SSveSop 2019-03-26 github

Have not had too much time testing this, but i just upgraded my GTX970 -> RTX2070 last night, and when testing various settings/MSAA+++ i found something strange.
I ended up using almost 5GB Vram, and 11GB+ system ram, and the game seemed a wee bit sluggish, so i logged off, and on again, and was down to 1.8'ish GB vram, and 4'ish GB system ram used.

I do not have a windows install to test this with atm, so the "problem" might be there on windows aswell, and that WoW wont release memory if you change settings/MSAA or whatever. I have some vague recollection in the back of my head this has happened in windows too, but as i said, no chance to verify this atm. This COULD be related to various stuff just being loaded the longer you play, and never getting released?

Any idea?

PS. Me upgrading to RTX2070 does also mean i have a spare GTX970 4GB (MSI). Is this of any use for you @doitsujin , or is it featurewise the same as you have and no real point? Cos if it is some features that would be NICE for testing for you, im willing to donate the card "for the cause" :) (Probably not too xpensive shipping from Norway -> Germany).

SSveSop 2019-03-29 github

I will look some more into this, cos it is something weird that happens if you change settings in a manner that causes the "driver to reload". Ie. changing from MSAA2 -> MSAA8, or changing from graphics preset 5 -> 10 and stuff like that. This will cause the game to "reload", and cause a reinitialization of the driver of sorts. (Ref. gx.log you can kinda see the adapter is reloaded).

When this happens, memory is not properly released. Sometimes this also will cause a WoW crash (some error # 132 that ppl experience from time to time). This is also the same thing that i mention in the other thread #977 . By "not released", it seems as both gpu and system memory is slowly eaten away. Just doing this a few times i was at 11-12GB system memory and almost 4GB vram spent. Exit game and log in, and sysmem is down to 6'ish GB and vram just shy of 2GB.

I am not sure WHAT happens, but i will do some more testing and possibly compare dxvk/d3d11 vs vkd3d/d3d12 now that there is a working patch around. It may be game related, as i have mentioned.

If anyone have a working Windows install with WoW, feel free to log both system and gpu memory used after switching between various setting. If the problem is the same in Windows it's ofc game related, and rather pointless troubleshooting under wine... In that case, let me know so i dont spend any time fiddling with this. (It's been a few years since i had a Windows install with WoW, and i dont really have a suited 2nd computer to test this)

Ddoitsujin maintainer 2019-03-29 github

Might be some reference counting issue. That aspect of D3D11 and DXGI is almost completely undocumented so matching native behaviour exactly is very hard, although I've seen completely broken implementations in games as well which I can't do anything about.

SSveSop 2019-03-29 github

@doitsujin
Right. How to troubleshoot this issue then, cos it is DXVK related atleast.

Tests:
D3D12 w/vkd3d:
Login:
System memory usage: 4.17GB
Video memory usage: 2.7GB
--
After switching between various graphics presets and MSAA.. multiple from 1 -> 10
System memory usage: 4.9GB
Video memory usage: 2.7GB

D3D11 w/dxvk:
Login:
System memory usage: 4.76GB
Video memory usage: 1.7GB
--
After switching between various graphics presets and MSAA.. multiple from 1 -> 10
System memory usage: 14.7GB (out of 16GB)
Video memory usage: 7.9GB (out of 8GB)
Result: CRASH/Lockup of wine.

To reproduce: Login to wow, and switch between different graphics presets that will cause the graphics driver to "reload" (ref. World of Warcraft/_retail_/Logs/gx.log)
DXVK does not seem to "release" memory, and just keeps chugging until wine goes tits up (possibly due to either starving system memory, or vram).
VKD3D does not exhibit the same behavior, as ram and vram seems to be released and spent according to current preset. (Lower preset/MSAA = lower VRAM usage as it should be)

This is something that was logged late in the WoW/_retail_/Logs/gx.log file:

3/29 16:26:39.433  RenderSettings::NotifyChanged
3/29 16:26:39.829  Error PresentFailure: 0x887A0020.
3/29 16:26:39.832  GxTexCreate short-circuited due to no device context for texture "" (512x512x1)
3/29 16:26:39.836  GxTexCreate short-circuited due to no device context for texture "" (256x256x1)
3/29 16:26:39.841  GxTexCreate short-circuited due to no device context for texture "" (512x512x1)
3/29 16:26:39.845  GxTexCreate short-circuited due to no device context for texture "" (256x256x1)
3/29 16:26:39.849  Device context was lost. Attempting recovery. Occurrence: 1
3/29 16:26:39.852  GxTexCreate short-circuited due to no device context for texture "" (512x512x1)
3/29 16:26:39.856  GxRestart
3/29 16:26:39.860  GxTexCreate short-circuited due to no device context for texture "" (256x256x1)
3/29 16:26:39.863  D3d11 Device Destroy
3/29 16:26:39.866  NotifyOnDeviceDestroy
3/29 16:26:39.932  D3d11 Device Destroyed

And ending with spam of these lines:

3/29 16:26:55.878  Feature Level: DX=4, MTL=0
3/29 16:26:55.882  Deferred Mode = 1
3/29 16:26:55.886  Driver Command Lists: yes
3/29 16:26:55.897  Error CreateBuffer Failed: 0x80070057.
3/29 16:26:55.901  Error CreateBuffer Failed: 0x80070057.
3/29 16:26:55.904  Error CreateBuffer Failed: 0x80070057.

Last lines probably due to no available vram/system ram.
Anyone with a different adapter care to test this and see if the problem is just as bad? Eg. AMD test would also be preferred i guess :)

SSveSop 2019-03-29 github

As a sidenote in general:
DXVK have more GPU load %, lower CPU load % and higher fps than vkd3d at the same preset.

Ddoitsujin maintainer 2019-03-29 github

Right. How to troubleshoot this issue then

No idea. I genuinely don't know since all the ref counting stuff is so convoluted and checking whether a function doesn't get called at any given point just happens to be extremely hard.

SSveSop 2019-04-05 github

Kinda hard to pinpoint, but i am fairly sure the two are related - ie. "non-released memory/resources" of sorts.

I just did a 2 hour session with some worldquests and a couple of mythics. When i logged on in Boralus, i had 90'ish fps, and 2 cpu cores around 65%. Vram was about 1800.
When i HS'ed back to Boralus after my "session", i had around 75 fps, 2.3GB vram, and 1 core at 73%, next at 70%.. (the others lower tho).

Not a HUGE jump, but kinda indicating things not being released and just keeps on spending resources. I rarely play more than 1 maybe 2 hours these days, so i have not been horribly plagued by this, but i can imagine someone with lesser hardware would notice this faster.

WoW might not be "following the rules" tho, and vkd3d is kinda "hacked together to work with WoW", so its kind of a unfair comparison, but nevertheless, the problem does not seem this apparent there. Some movement is being made towards wined3d<->vulkan atm it seems, so i wonder what will be the result there.

PS. Performance of vkd3d is about 70% of DXVK tho.

Ddoitsujin maintainer 2019-04-05 github

Keep in mind that you might be observing intended behaviour, i.e. the game might just not release resources if you have more than enough memory anyway. This isn't necessarily related to the device destruction issue.

Also, keep in mind that DXVK does not free VRAM, the only way to actually monitor its memory utiltization properly is through the HUD.

SSveSop 2019-04-06 github

Yeah, i have thought about this, and that the more textures/shaders/whatever you "see during gameplay" does not need to be "released", as you just might end up seeing it again in a little while, and "if memory available"...

The performance degrading is the problem here tho. Loading more stuff in vram/system ram should not necessary mean 10% more cpu usage?

Will see if i can do some comparison sessions with vkd3d. My kid no longer plays wow, or else i might have convinced him to do some logging during his 8+ hours gaming sessions in windows as a comparison... but alas..

HHamdor 2019-05-28 github

@doitsujin
Right. How to troubleshoot this issue then, cos it is DXVK related atleast.

Tests:
D3D12 w/vkd3d:
Login:
System memory usage: 4.17GB
Video memory usage: 2.7GB
--
After switching between various graphics presets and MSAA.. multiple from 1 -> 10
System memory usage: 4.9GB
Video memory usage: 2.7GB

D3D11 w/dxvk:
Login:
System memory usage: 4.76GB
Video memory usage: 1.7GB
--
After switching between various graphics presets and MSAA.. multiple from 1 -> 10
System memory usage: 14.7GB (out of 16GB)
Video memory usage: 7.9GB (out of 8GB)
Result: CRASH/Lockup of wine.

To reproduce: Login to wow, and switch between different graphics presets that will cause the graphics driver to "reload" (ref. World of Warcraft/_retail_/Logs/gx.log)
DXVK does not seem to "release" memory, and just keeps chugging until wine goes tits up (possibly due to either starving system memory, or vram).
VKD3D does not exhibit the same behavior, as ram and vram seems to be released and spent according to current preset. (Lower preset/MSAA = lower VRAM usage as it should be)

This is something that was logged late in the WoW/_retail_/Logs/gx.log file:

3/29 16:26:39.433  RenderSettings::NotifyChanged
3/29 16:26:39.829  Error PresentFailure: 0x887A0020.
3/29 16:26:39.832  GxTexCreate short-circuited due to no device context for texture "" (512x512x1)
3/29 16:26:39.836  GxTexCreate short-circuited due to no device context for texture "" (256x256x1)
3/29 16:26:39.841  GxTexCreate short-circuited due to no device context for texture "" (512x512x1)
3/29 16:26:39.845  GxTexCreate short-circuited due to no device context for texture "" (256x256x1)
3/29 16:26:39.849  Device context was lost. Attempting recovery. Occurrence: 1
3/29 16:26:39.852  GxTexCreate short-circuited due to no device context for texture "" (512x512x1)
3/29 16:26:39.856  GxRestart
3/29 16:26:39.860  GxTexCreate short-circuited due to no device context for texture "" (256x256x1)
3/29 16:26:39.863  D3d11 Device Destroy
3/29 16:26:39.866  NotifyOnDeviceDestroy
3/29 16:26:39.932  D3d11 Device Destroyed

And ending with spam of these lines:

3/29 16:26:55.878  Feature Level: DX=4, MTL=0
3/29 16:26:55.882  Deferred Mode = 1
3/29 16:26:55.886  Driver Command Lists: yes
3/29 16:26:55.897  Error CreateBuffer Failed: 0x80070057.
3/29 16:26:55.901  Error CreateBuffer Failed: 0x80070057.
3/29 16:26:55.904  Error CreateBuffer Failed: 0x80070057.

Last lines probably due to no available vram/system ram.
Anyone with a different adapter care to test this and see if the problem is just as bad? Eg. AMD test would also be preferred i guess :)

I just tested this with lastest master (1e0fe36c) and was not able to reproduce this with an AMD RX580.
AMD RADV POLARIS10 (LLVM 8.0.0)
Driver: 19.0.4

I switched between various graphic presets and msaa.

Error codes