Shader Compiling stutters when playing Guild Wars 2 on Windows 11 with AMD GPU

[brittyazel]

I understand that Windows 11 is not one of the tested platforms, but I figured I would report this anyhow.

Generally, DXVK on Windows works very well when playing Guild Wars 2, even better for AMD GPUs than the native DX11 implementation, but there is one area where the experience is non-optimal. Shader compiler stuttering is still a very big issue in Guild Wars 2, even despite AMD drivers supporting VK_EXT_GRAPHICS_PIPELINE_LIBRARY for the better part of 2024. Eventually, the game will calm down after the bulk of the shaders are compiled and cached, but for many minutes the game stutters constantly when panning the camera. Likewise, the hard stutter that happens every now and again is very distracting and it feels like something is not working quite right, particularly with what I've heard about the Graphics Pipeline Library supposedly fixing these sorts of stutters.

My question is why Guild Wars 2 is not seeing the benefits of the Graphics Pipeline Library, and whether or not it is addressable. Despite the frame stuttering, DXVK runs beautifully and renders the game flawlessly. Fixing this issue is the only thing holding DXVK back from being the premiere Guild Wars 2 experience for AMD users on Windows.

Software information

Guild Wars 2, Full Screen Windowed, 3840x1440 resolution, all settings set to max

System information

• GPU: AMD RX 7900 XT
• Driver: 24.10.1
• DXVK version: 2.5.0

Logs: Gw2-64_d3d11.log Gw2-64_dxgi.log

[mbriar]

Eventually, the game will calm down after the bulk of the shaders are compiled and cached

Does the game not stutter at all when not using dxvk on amd windows? If it does stutter with native d3d11 as well, that indicates that the game creates shaders just before using them in draw calls and dxvk can't fix that even with GPL.

Will it also calm down when you just stand in a corner doing nothing until shader compilation is done (look at the dxvk hud)? If yes, than that just means the game has a bunch of shaders that need to be compiled and AMD's windows compiler - especially since rdna3 - is quite slow.

[brittyazel]

Using native d3d11, the frame timing is all over the place but the stuttering is significantly less. There will be momentary hitches, but nothing as severe as the stutters that happen with DXVK. That being said, once the shaders are compiled the experience on DXVK is MILES better than on d3d11. Likewise, I have not tested using a Nvidia GPU, but the people that I've talked to state that the experience with Nvidia is very smooth without any hitching/stuttering whatsoever with d3d11.

And yes, when I just stand in the city and let the shaders compile, it will eventually calm down and be very smooth. I had the HUD enabled for a while, and there was not constant compiling. The compiling would just suddenly happen at the same time as one of the stutters, and then it would be over a few milliseconds later. I don't think it's the case that there is constant compiling happening or anything like that.

Other than that, I don't have any insights into the operation of the engine itself. I'm not sure exactly how it handles presenting the shaders during play time. I will try to capture a video of the HUD so you can see what I mean.

[mbriar]

And yes, when I just stand in the city and let the shaders compile, it will eventually calm down and be very smooth.

Than that just means that there are a bunch of shaders needing to be compiled and AMD's compiler is too slow. I doubt there is anything DXVK can possibly improve here.

[brittyazel]

https://drive.google.com/file/d/174YVSYFDRKntb2QwuRNKbVXMUeQHVQCh/view?usp=sharing

There is a demonstration of what I'm seeing. Yes the slow shader compiler could explain it, and that could also explain why the native d3d11 experience is also unsmooth. That's unfortunate.

[mbriar]

From the video it also looks like the game is creating the shaders just before draw for every new object, and not all at once in advance on the e.g. loading screen (number of graphics shaders continuously goes up with every new object/effect appearing for the first time). That will also cause stuttering on native drivers that are just more noticeable the slower the drivers shader compiler is.

[brittyazel]

Well damn. So then it's an engine implementation issue then? I guess we can't do anything about that short of getting a job at ArenaNet.

[brittyazel]

Interestingly, this seems like a time when asynchronous shader compilation would be beneficial to smooth out the hard stuttering. Are there still no plans whatsoever to do asynchronous shader compilation and/or something similar?

Fwiw, I tried using the dxvk-gplasync fork, and it renders seemingly perfectly without any hitching whatsoever. I understand that there's reasons to not merge in those patches, but as the end-user, the experience feels much nicer.

[K0bin]

Interestingly, this seems like a time when asynchronous shader compilation would be beneficial to smooth out the hard stuttering. Are there still no plans whatsoever to do asynchronous shader compilation and/or something similar?

Yes. There are no plans for that whatsoever.

[brittyazel]

Roger. Not being argumentative, but is there a resource you can link me to that explains the rationale as to why? I understand that the purpose of DXVK is to accurately represent the d3d pipeline, but afaik even with the out-of-tree asynchronous patches, the async features are all locked behind options flags. I guess my question is why keep all those patches out-of-tree, rather than just making the async functionality user opt-in only.

[Blisto91]

The async patch is hack that the devs don't believe is the correct way to handle the issue. It trades off visual glitches while compiling shaders for for the smoothness achieved. See also responses here https://github.com/doitsujin/dxvk/issues/4221

I'm curious you are seeing much stuttering at all with this game. I've played it quite a lot on Linux and don't recall that the game is particularly bad or have that many shaders to compile. While the shader compiler for mesa's amd Vulkan driver on Linux is much faster than amd's own i don't recall this being much of an issue on Nvidia either. Maybe i have just forgotten or started to ignore it or my 7950x is making it not too noticable.

[brittyazel]

Certainly, I won't argue that it's not a hack, but it also provides a much better experience for the gamer in the case of a situation like this one where the only solution is for the game engine itself to be fixed. Albeit, with the tradeoff being the occasional flicker due to a missing shader. I would not advocate for making it the default in any way, but it is extremely effective in making a game go from borderline unplayable to totally playable (with some visual tradeoffs). I have no horse in this race, but the results really are night and day with the async patch. I guess from end, I don't see the harm in providing it as an optional config as a worse case scenario where there are no other options for the gamer.

Yeah I've read the stuttering could be caused by a change to the AMD Windows driver when they introduced a technology called "dxnavi" or something of the sort. I also don't experience the stutter nearly as bad on Linux, it's specifically something with the Windows driver.

Also, using the async patches I can now actually "see" the little white flash as the shader gets compiled in real-time, and I can confirm that it appears the engine is seemingly creating the shaders just as their needed, rather than ahead of time. But it's for mostly small things, like gear/weapon/mount effects on other players, not so much the world itself. I.e. stuff that the engine can't predict ahead of time will be present in a scene. So the stuttering ends up being the worse in a dense area like a city, and calms down significantly out in the world.

[Blisto91]

Providing a async option isn't on the table for this version of dxvk. Just use the fork instead.

In regards to GW2 then unless it is something that has regressed in dxvk compared to previous dxvk versions then i don't think there is much for dxvk to do. At least not anything simple that i am aware of (tester not a dev).

[mbriar]

Yeah I've read the stuttering could be caused by a change to the AMD Windows driver when they introduced a technology called "dxnavi" or something of the sort. I also don't experience the stutter nearly as bad on Linux, it's specifically something with the Windows driver.

It would probably stutter just as bad on linux, or worse, if you used AMD's official vulkan driver, AMDVLK, which has a much slower shader compiler backend based on LLVM. As far as I heard, AMD also switched the windows vulkan/dx12 driver over to the LLVM-based backend for RDNA3 from their older proprietary backend, which was quite a bit faster.

[brittyazel]

Well, for what it's worth, I cleared out my shader cache and set dxvk.enableGraphicsPipelineLibrary = False, and the experience was WAY worse than with the Graphics Pipeline Library enabled. The game was effectively frozen after logging in for multiple seconds, and it took 20+ seconds before I could finally start moving around. So I can confirm that the Graphics Pipeline Library is definitely doing its job for the most part, and the only thing I'm experiencing with it enabled are frequent micro-stutters. Given that, I'm not sure what else there is to do besides have a faster shader compiler and/or have the engine change how it creates textures.

I am using RDNA3 on my 7900 XT GPU, and I have a 5800X3D. So neither my GPU or CPU are top end, but they're not slow by any means.

And yeah, on Linux I use Mesa/Radv, so I'm using the Aco compiler afaik.

[Blisto91]

ACO is quite a beast yea and so is probably the best case scenario.