I took a closer look at all the shader compiling for Overwatch, I don't see anything wrong with how it's done in dxvk. That's just the way things are, also on Nvidia and Windows. These cpu frametime spikes either produce stutter in low latency environments or produce very noticeable input lag when frames are rendered buffered.
@ZeusThundr You may want to take a look at my new low-latency framepacer, possibly getting you the best input you ever had in this game. It can't prevent stuttering but I took care they are handled in a way it's not too disturbing.
https://github.com/netborg-afps/dxvk/releases
PS: A common thing to do in Overwatch is to switch Reduce buffering to off and on again. Not sure which bug this is, but it helps to reset performance.
DXVK_ASYNC=1`x1 2024-01DXVK_HUD=pipelines`x1 2024-01__GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1`.x1 2024-01
Related issues: 3813 Valves Proton Repo issue.
Update March 21, 2024
The slow shader compilation is linked to using LatencyFlex when disabled compilation is much faster and fps is higher overall and when compiling shaders using GPL but mouse input latency is increased quite drastically from what I remember from my last test a few months ago. This does not happen when using async patched dxvk.
Update Feb 8, 2024
Since Switching to using ULWGL (commit: ff5d7c15) on lutris (commit: 777de5dd) and using Proton-GE-30 without
DXVK_ASYNC=1the time it takes to compile shaders is on par with DXVK Async 2.0. Also worth mentioning the issue mentioned before this update about GPU clock speeds, is now fixed by using lactd or corectrl and manually setting clock speeds on kver 6.7.1 patched with tkg's utility. Though it seems that most of the issues have been fixed DXVK Async 2.0 still outperforms DXVK 2.3 in terms of FPS.My apologies for this issue feel free to close this issue though other users might be still be experiencing these issues since they might not be running the bleeding edge of the aforementioned pieces of software. Hence why I haven't closed it myself.
Misc: With this new setup a new issue has arisen when tabbing out and going to tab back in the game is still running as I hear the in game noises of a fight still going on but no input is received in game and the screen is black. I have to close out of the game and relaunch to be able to play again. I can't reproduce this reliably so do with this information what you will. This has happened over the years of playing with different setups on many different titles. This is probably not a DXVK issue just don't know who where to report this to. I'm hoping you can pass this on to where it belongs as you more likely than not know more than I do when it comes to these sort of issues than me.
Update Feb 10, 2024
The issue of long shader compilation and sporadic gpu freqs until its is done compiling seems to be fixed in Proton-GE-29 and Proton-GE-30 but still occurs on wine-ge-8-26 and below.
Update Feb 13, 2024
Same issue occurs as stated originally in Proton-GE-31 and Proton-GE-32 on lutris but not on Proton-GE-29 worth maybe noting that Latency Flex works on these version as if environment variables as set properly on Proton-GE-31 and Proton-GE-32 but no on Proton-GE-29. I'm really starting to think this is no longer a dxvk issue. Any advice on how to properly describe this behavior and who to report it to would be greatly appreciated.
Software information
Game: Overwatch 2 - Lutris
Graphic Settings: Low
Display Protocol: Xorg
DE: KDE 5.27.10
Distro: Arch
System information
Behavior
VK_EXT_graphics_pipeline_libraryis much slower than DXVK ASync 2.0 at compiling shaders whenDXVK_ASYNC=1is set.When using GPL the first 20k graphic shaders in
DXVK_HUD=pipelinestake just a couple of seconds and the rest until 96k take about 4-5 minutes for it to compile even when using__GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1. I read somewhere that env-var is only really useful for NVIDIA GPU's. Essentially the game unplayable for up to 5 minutes on each game launch, since your GPU clock speeds go from 30Mhz to a few hundred until it is all done compiling shaders; At which point the GPU will boost over 2 Ghz unlike when Using async the game is virtually immediately playable.DXVK 2.3 also has the odd behavior of not detecting Overwatch as a game. If I ever decide to tab out for any reason I have to spam alt+enter while looking at MangoHud to see if my GPU clock speed is being set properly. Note I don't have this issue with DXVK async 2.0.
By not detecting as a game I mean it's running at lowest GPU clock speeds and or alternates between deciding if its a game or not by ramping up the GPU clocks slowly and ramping them back down again to lowest GPU clock going back and forth indefinitely even if I use corectrl or lactd for setting my clock speeds manually.
I'm lead to believe that it might be related to a window focus issue since this only happens once I tab out at any given moment to open another application. The GPU clock speeds are respected as long as I don't tab out. Though I can't get this behavior to happen with DXVK async 2.0. This issue isn't desktop environment specific as the same problem occurs in Gnome, DWM, and KDE.
Benchmarking
Overwatch Workshop benchmark gamecode:
HEZHJ(Custom game -> Create -> Import code).In benchmarks DXVK async out performs DXVK 2.3. Though I mainly focus on 0.1% lows
Here are some benchmarks I conducted to compare FPS. The best 0.1% lows were from the benchmarks named "2.0 LFX OFF RB OFF" and "2.3 LFX OFF RB OFF" respectively their is a character limit on how long names can be on https://flightlessmango.com so I had to abbreviate them using acronyms, defined in the description of the benchmark itself.