Dxvk: Path of Exile unplayable stutter

Created on 29 Jun 2018  路  23Comments  路  Source: doitsujin/dxvk

Not sure if I'm the only one but Path of Exile is actually unplayable (leveling/endgame) on linux due to the extreme stuttering experienced when

  • Loading into an area
  • Moving
  • Seeing enemies being hit/attack an enemy/pack of enemies
  • Player being hit
  • Other players loading into an area (town)
  • Skills or effects in general being casted/triggered

Regarding apitrace:
I had two apitraces ready but due to some confusion I believe I recorded them in a prefix I had DXVK installed and I guess that's not how it's supposed to be, I tried running the game on a clean wine prefix with no vulkan or DXVK but wine crashed as soon as the login screen rendered, should an apitrace be recorded anyway until it crashes? should I try to record the apitrace on windows instead? wouldn't that defeat the purpose of showing the stuttering in the situations described above? any guidance would be appreciated.

_Note 1: wine was patched manually trying to replicate this patch in the newest wine source (some syntax differences and the auto patch failed)_
_Note 2: i tested this DXVK patch (more info) and it solved some of the stuttering, maybe worth looking into_

Software information

Path of Exile DX11 mode windowed

  • VSync: off
  • Textures: medium
  • Texture filtering: 16x
  • Engine multithreading: disabled
  • Dynamic resolution: disabled (doesn't seem to work properly on linux anyway)
  • Water detail: low
  • Shadow quality: low
  • Antialiasing: off
  • Lightning quality: off
  • Post processing: off
  • Screen shake: off

System information

Using DXVK_USE_PIPECOMPILER=1 VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_standard_validation DXVK_LOG_LEVEL=trace WINEARCH=win64 WINEPREFIX=~/.wine_vms/PoE wine 'C:\Games\Path of Exile\PathOfExile_x64.exe' --nointro --nologo --noasync --garbage-generation 2

Log files

PathOfExile_x64_d3d11.log
PathOfExile_x64_dxgi.log

performance wontfix

All 23 comments

The game uses a lot of varying combinations of shaders that need to be cached before the game starts to run smoothly. I've leveled a character to maps (endgame), and play just about as smoothly as on Windows. Make sure not to touch your graphics settings as they may require recompiling of a lot of shaders. I run everything on the highest settings (even 8x MSAA) and get a consistent +60FPS aside from the occasional shader compilation stutters that DXVK_LOG_LEVEL=debug will confirm.

My settings:
DXVK_USE_PIPECOMPILER=1
The game doesn't need any args.

I use a RX580 with mesa-git 18.2.0_devel.103089.ff6db94c18-2 using wine-staging-pba-git 3.11.r4.g24f0fcf0+wine.3.11.r35.g85f1a79be8+pba.3.11.r66.7e8d2a5-1 on Arch Linux

Attached is a patch that makes the pipecompiler use 8 threads rather than 1 thread, which helps significantly if you don't have a relatively full shader cache.
tc8.zip

This is an inherent issue with DXVK that cannot be fixed, sadly.

Using "placeholder" shaders or any such hacks that lead to incorrect rendering is obviously not an option.

Do you think contacting the developer about this would be a wise idea? I know they were originally hesitant about their D3D11 renderer, keeping it opt-in for quite a while.

The game does stutter slightly on Windows from what I would conclude to be the same root cause, but not quite as significantly as here - ie. the problem may lie outside of DXVK's scope?

I recorded a 5 minute video here of me running the same map thrice: https://www.youtube.com/watch?v=cKwUT4V3vjM

The video confirms the stuttering, but it is obviously only occuring during new effects that had not been encountered so far. This was from a relatively cold cache, using some relatively lenient encoder settings as to not affect the recording (the game is quite CPU intensive, even moreso with DXVK)

ie. the problem may lie outside of DXVK's scope?

The main difference is that a native D3D11 driver can do all sorts of code transformations when the game calls one of the D3D11Device::Create*Shader methods and save a lot of time when the shader is actually needed for the first time. DXVK can only do the DXBC->SPIR-V translation at that time, but it has to do the time-consuming part when the shader is first used.

The only thing the developers could do to counter this is to "warm up" the shader cache by submitting draw calls with all possible shader configurations before actually starting to run the game. Some games do this, but it's a rare and it's not really needed on Windows.

gonX, it seems much better in your video than here, sure your PC is ages ahead of mine but then again I don't have much problem with this game on windows. I recorded a bit of the stuttering here, gets pretty bad near the end. I'll try your patch out maybe it helps.

doitsujin, I understand why you're against such hacks, I really just mentioned the patch because I saw there was some game-specific options in the DXVK code (fallout4 among others).
If there is anything else I can test in the future let me know and thanks for your time.

You didn't mention what CPU you have, but pipeline compile times in excess of 200ms are normal a lot of games. I know it's annoying but it's just impossible to do anything about it, sorry.

That said, you should check whether your Mesa is compiled with -DNDEBUG, and if not, do so, but if that wasn't the case you would probably see compile times taking several seconds.

My CPU is a FX6300, Regarding mesa, I'm not sure if my mesa is compiled with that arg, I don't compile it myself since I've always used this repo but I'll look into it

Would it be possible to dump the shaders to a cache dir and pre-compile them to native isa on every game start with the drivers shader compiler? I think this is the workaround that cemu and rpcs3 use for this issue. This way the stuttering only occurs the first time you play a game.

This way the stuttering only occurs the first time you play a game

That's what happens with DXVK as well unless you disable your driver's shader cache, but the "first time" experience is exactly the problem...

Yes, if the shaders are in the driver's cache all games run smooth, but if i update my driver the cache is not valid anymore and the stuttering is back. I update my mesa every few days so pre-compiling would be a cool feature.

The way to do that in DXVK would be to cache pipeline state. I did make several attempts in implementing that but it ultimately didn't work.

If the dumped dxbc or spv shaders are compiled once in advance with the driver's shader compiler, the way dxvk does it in runtime, wouldn't this fill up the driver's cache?

You can't compile SPIR-V shaders directly, you need to compile full Vulkan pipelines including all associated state.

RPCS3 has one cache folder for the raw shaders and one for the vulkan pipelines. Maybe it would be helpful to take a look at how the caching is done there?

It doesn't really matter how RPCS3 does it since the theory behind it is trivial. I'm just incapable of implementing it for some reason, and I don't really care since the driver's shader cache works well enough in practice. It doesn't improve the first-time experience anyway.

Dunno if I said this before but is it related to the WIC error? There is a patch.

https://github.com/GloriousEggroll/ge-wine/blob/master/pathofexile.patch (DX11 Mode patch)

@jarrard Unrelated.

(For nvidia people) I think the issue might be linked to nvidia's (soft) maximum limit of 128mb shader cache. This game needs far more. The same problem can be seen with Overwatch currently, even when you have played the game a million times over.

Discussion about it

As for AMD side, I'm not sure. GE seems to have no stutter at all when he previewed his wine/dxvk patch.

If you're a nvidia user like me, then your shader cache is probably tiny enough to not do any actual caching (since it keeps getting overwritten)... In that case, check out this patch: https://github.com/jomihaka/dxvk-poe-hack (releases tab has precompiled). This makes DXVK go from unusable to usable.

Closing since root problem cannot be solved.

ie. the problem may lie outside of DXVK's scope?

The main difference is that a native D3D11 driver can do all sorts of code transformations when the game calls one of the D3D11Device::Create*Shader methods and save a lot of time when the shader is actually needed for the first time. DXVK can only do the DXBC->SPIR-V translation at that time, but it has to do the time-consuming part when the shader is first used.

The only thing the developers could do to counter this is to "warm up" the shader cache by submitting draw calls with all possible shader configurations before actually starting to run the game. Some games do this, but it's a rare and it's not really needed on Windows.

Hi Doitsujin - can you expand on the problem a little more? I tried following the D11 api to find the potential transformations but couldn't find the right section. Where do you think the problem could be solved - does Vulkan need parity transformations for SPIR-V or would recompiling to DXIL and using DXIL > SPIR-V solve the problem?

On one hand, I play PoE a ton and this is really the last remaining big issue with it. I know it also impacts other games, PoE is just shader-heavy, but it seems like it could be such a huge improvement it would be nice if it was scoped out some (even if outside of DXVK's scope).

Where do you think the problem could be solved

It simply can't. The only solution is to write a native driver that supports shader patching (this could be a Gallium state tracker).

Hi all!
For myself, I found this solution:
1) Install dixvk version of poe through lutris
2) Install the latest version of wine staging
3) In the settings of Lutris to POE, turn on the staging wine
4) Download and install this: https://github.com/jomihaka/dxvk-poe-hack/releases (not sure if it works correctly with the latest versions of dixvk)
5) We play. I personally have significantly decreased friezes and stutter, checked on the league delirium.
I hope someone helped. You can see this guide in more detail: https://www.reddit.com/r/pathofexile/comments/9x47or/guide_getting_path_of_exiledx11_to_run_smoothly/?sort=new

Was this page helpful?
0 / 5 - 0 ratings

Related issues

AuroransSolis picture AuroransSolis  路  3Comments

yusdacra picture yusdacra  路  4Comments

Ahmed-E-86 picture Ahmed-E-86  路  4Comments

t14462 picture t14462  路  4Comments

arabcian picture arabcian  路  3Comments