Not really a bug or an issue, just how GPL inherently works.
We compile we compile a very large number of shaders up front, extra memory usage is fully expected. Can be mitigated by setting dxvk.trackPipelineLifetime = True in the config file, which we already do by default for 32-bit games for this reason, but this may reintroduce some stutters since we now have to go through the driver's disk cache to compile pipelines on the fly.
High CPU usage when compiling optimized pipelines in the background also isn't unexpected at least for some time after loading into a new area. Again, can be mitigated by setting dxvk.enableGraphicsPipelineLibrary = True which disables those optimized pipelines, but this will come at the cost of GPU-bound performance.
All of this is exacerbated by the fact that Nvidia's compiler just isn't very fast compared to e.g. RADV, and pipeline objects are for some reason also significantly larger than on other drivers, but that is outside of our control.
I have also noticed that my mouse's polling rate affects the game significantly, roughly like this:
This is not our problem, and most likely related to wineserver sitting at 100% CPU.
and every subsequent run just does "Compiling Shaders" with no number.
This means the individual compile batches complete fast enough that computing a percentage isn't meaningful. Again, normal. Keep in mind that the game actually has to load its D3D shaders as well, which is not free, they don't magically fall from the sky.
Replying to https://github.com/doitsujin/dxvk/issues/3813#issuecomment-1907934772
Thanks for the response! I didn't know about the trackPipelineLifetime config option and I'll definitely test it.
I still have some questions though:
High CPU usage when compiling optimized pipelines in the background also isn't unexpected at least for some time after loading into a new area.
Indeed, that is expected, but I might have made a mistake in not mentioning that this happens when you open the game itself (i.e., the main menu, hero list, etc.) and is independent of any actions like loading a map or previewing a hero.
I also forgot to mention that the CPU usage isn't particularly high, it just takes a long time and the FPS is unstable while it's happening. This is an issue that has been in the game since it was released and is probably an engine quirk.
> I have also noticed that my mouse's polling rate affects the game significantly, roughly like this:
This is not our problem, and most likely related to wineserver sitting at 100% CPU.
I test the mouse issue after the compilation and benchmarking/forcing more shaders to compile, my CPU usage is ~15 to 30% when not moving the mouse in-game and it goes up to ~55% when moving while looking at the sky in the practice range.
Finally, performance was better before the game came to Steam, that's why I say I get ~50% of the expected FPS while my laptop didn't change specs. I suspect this may be caused by a game update along the way, but I can't tell.
About the mouse issue: In the past (5 years ago?) , I had a similar issue with about the same setup as you (desktop nvidia, not laptop). The solution I found was disabling polling for drm_kms_helper. I took this solution from:
https://superuser.com/questions/528727/how-do-i-solve-periodic-mouse-lag-on-linux-mint-mate
It solved weird lag for me when looking around in OW and WoW at that time. I still have this set, but perhaps the issue is still present and this will help. Should be easy enough to test.
Replying to https://github.com/doitsujin/dxvk/issues/3813#issuecomment-1913127205
Thanks for the recommendation, but unfortunately, this didn't help. It looks like they all say that they have problems in the desktop or random lag which I don't have, the module isn't loaded and doesn't load (I can't even find info about it), and they all use Ubuntu while I'm on Arch (EOS).
I only have a problem with OW2, so It's probably either a Wine issue or an DXVK issue. Also, they are all from around 2013 to 2018 and a lot has changed since then.
I also know that people have been complaining a lot about high polling rate mice in Wine causing lag since time immemorial, so maybe it's just Wine devs not caring or smth.
I'm on Arch, I set it on Arch in 2018. I set it because my 1000hz mouse was causing lag in Wine when looking around in WoW and OW. This was the solution. I never changed a thing since then, and it is still there, well, at least for me. Here is a link to ArchWiki KMS page that still talks about setting this (though in context that polling simple can lag you).
It used to be needed by nvidia_drm, which loaded drm_kms_helper. However, it does seem that module isn't loading indeed or at least no longer needed for nvidia_drm, I do not know at what point that changed. But! I still can toggle it with /sys/module/drm_kms_helper/parameters/poll. Though at this point I'm unsure what is providing it, perhaps nvidia_drm? I'm loading with nvidia_drm.modeset=1 nowadays, so that is most likely the change. However I also have a intel gpu on my processor, even though I don't use it at all, so perhaps it has something to do with that.
In your case: I also assumed you had intel + nvidia. Rereading your specs I'm slightly confused to what you have. Is MX350 your normal gpu in your laptop, and 1650 your 2nd gpu? What is your GPU? Does your CPU not have a igpu?
Oh, and did you have this issue with 535 driver as well? 545 has had some issues for multiple people. And 550 is also available now in beta.
Replying to https://github.com/doitsujin/dxvk/issues/3813#issuecomment-1913294380
In your case: I also assumed you had intel + nvidia. Rereading your specs I'm slightly confused to what you have. Is MX350 your normal gpu in your laptop, and 1650 your 2nd gpu? What is your GPU? Does your CPU not have a igpu?
I have two laptops with Intel + Nvidia, one with an MX350 and one with an 1650
Oh, and did you have this issue with 535 driver as well? 545 has had some issues for multiple people. And 550 is also available now in beta.
Yeah, I'll wait until 550 hits stable and maybe it'll fix some of the issues. Plasma 6 might also help. Thanks for the recommendation though!
Ah, that makes sense again!
Some quick thoughts:
/sys/module/drm_kms_helper/parameters/poll? If yes, try to set it to "N". If no, leave this train of thought.dxgi.useMonitorFallback was added till the QueryDisplayConfig optimization hits proton. Have you tried setting it to false?Oh and side note: I disabled GPL for OW myself. The old cache stutters during game-play till it fills up, but for me it always used less CPU and felt faster on my rig. Make sure you have big enough __GL_SHADER_DISK_CACHE_SIZE so it doesn't get cleaned out on subsequent starts (then dxvk has to use dxvk_cache to recompile it every time you start up the game).
Replying to https://github.com/doitsujin/dxvk/issues/3813#issuecomment-1913332044
I tested setting the parameter before you even commented, actually, but unfortunately it had no effect; the dxgi setting also had no effect; NVAPI and spoofing AMD also had no effect.
Oh and side note: I disabled GPL for OW myself....
Yeah, I'm doing the same and setting __GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1. Still, thanks for the suggestions!
might not be the same issue but on nvidia (driver 550, 545 also the same) using latest proton (proton-experimental or proton-ge), if I disable steam's shader precompilation I end up having 5-10 minutes of low fps/stutters and maxed out cpu (~100% load on every core) each and every time I launch overwatch. __GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1 had no effect.
this is on a 13600k + 4080 running arch
Have the same issue.
But i'll describe it with my own words.
I have 16GB of RAM and an NVIDIA GPU. v555 driver.
And have tried all of the Tricks on ProtonDB.
The game starts with 6.5 GB of memory and runs wonderfully smooth - until the memory usage hits ~11.5GB
You can watch it go up at every stage of playing.
(Lowest Settings btw. at 120fps)
Then it begins to jitter, slow down ~30 frames and speed up ~30 frames again.
Makes it unplayable.
Turning on PROTON_USE_WINED3D=1 makes the game even more unplayable but not related to a memory leak.
Can we do anything to force clear memory, without restarting the game?
End of the year update on this issue:
I made this "update" since there have been several major updates to the game, even optimization ones, but nothing seems to have improved on the Linux front, the game even crashed for the first time in a year for me.
While I have no hope of this being fixed at this point, here's an update as of May 2025 on GE-Proton10-1:
All the issues still persist; I recently got an OOM since the game decided to use more than 15GB of RAM while I had swap off. What I can only imagine is that shaders for everything just stay in memory and never get freed.
While I have no hope of this being fixed at this point, here's an update as of May 2025 on GE-Proton10-1:
All the issues still persist; I recently got an OOM since the game decided to use more than 15GB of RAM while I had swap off. What I can only imagine is that shaders for everything just stay in memory and never get freed.
Overwatch's minimum RAM and CPU requirements on Linux are completely different to Windows. From my testing, the minimum you require to play is the following:
If you don't have the minimum required memory, you must add a swap partition or swap file that gets you to 32GB RAM+swap. This is non-negotiable. The most effective ways to compile shaders are to either watch a relatively long replay in your recent history from any of the players' perspective (ideally at the highest speed so it's over fast), then go to the hero gallery and wait it out, or alternatively go to the practice range, change into every hero once, and then wait it out. Compilation speed depends on how powerful your CPU is. If it's relatively old, you may be waiting upwards of 30 minutes or an hour.
As for this particular issue with low performance and excessive shader compilation, I'm certain it will never be fixed. In fact, I only think it's going to get worse and worse over time considering Blizzard keeps adding hundreds of new items to the game every season, which equals hundreds of extra shaders to compile.
The reason I know this will never be fixed is because no one seems to have any idea on how to even approach dealing with this, not even Valve. I know this because the game runs awful not only on Bottles and Lutris, but also both on Steam with official Proton builds, and on the SteamDeck.
The only way this could ever be solved is if Blizzard decided to officially start supporting Linux by adding an OpenGL or Vulkan renderer, but I don't think this will ever be the case, especially because Overwatch is almost 10 years old (Overwatch 2 being simply a balance patch, not a new game), and Blizzard being owned by Microsoft now.
@3DMicks could you give this a go again with current master?
Note, ow2 always had the bug (maybe linux-only, not sure), that you sometimes need to toggle "reduce buffering" off and on again, if it gets into a low fps state, which fixes this. This option probably is also responsible for various reports that certain dxvk/Proton versions are causing performance regressions.
@3DMicks could you give this a go again with current master?
@Blisto91 I've replaced the current GE-Proton10-15's dxvk with e83650fdf7e64444a166ab0488ab16cae63dcb48 and personally noticed this:
I haven't been keeping track of all the changes to DXVK/Proton, so if there was something else that should've changed, please tell me. Hope this helps.
I have a similar computer setup to the author's, and the option dxvk.trackPipelineLifetime = True helped me reduce RAM usage and stutters caused by running out of memory and swapping (16 GB physical + 8 GB zram swap). There are still occasional stutters due to having to recompile shaders more often, but they are nowhere near as jarring as memory-related stutters.
@3DMicks, have you tried putting a dxvk.conf file with that option in the same directory as Overwatch.exe and test the game?
I forgot to mention, the RAM consumption hovers around 12-13 GB + 1 GB swap with dxvk.trackPipelineLifetime = True and 16 GB + 5-7 GB swap without it.
See https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-4063362431, which mentions DXVK problems with Overwatch specifically and a workaround
There is no "memory leak" as that issue implies, it's just that Vulkan pipelines use up a lot of memory (esp. on Nvidia, it's not exactly news that things take up ~3x as much memory as on RADV) and the game creates something like 70k of them on startup.
I kind of want to avoid enabling that option by default for anything because with this many shaders there's a high chance that it's just going to exceed the driver's shader cache limits and you're going to get stutter again, making the game unplayable.
The game is perfectly playable with the option enabled even when the occasional stutters from hitting the cache limits occur. It makes more sense to enable that option for Overwatch than to disable it.
Edit: I say this as a frequent player of this game on Linux.
Edit 2: Made my statement clearer.
[...] making the game unplayable.
Ever since the "season 1" update a month or so ago, the game has already been unplayable because it takes up ~14gigs of memory just in main menu and OOMs under a min or so in when you join a match. This is on nvidia and with 16gigs of memory.
dxvk.trackPipelineLifetime = True was the only option to make the game playable (memory usage drops down around 7~9gigs) with dx11/dxvk. I haven't noticed any stuttering so far.
I won't comment on whether it should be enabled by default or not as you're better equipped to judge that. So I'm just giving you some data point that for me (and many others reporting it on protondb and elsewhere) the game is already unplayable without this option.
The game might be unplayable with an Nvidia+16GB RAM configuration, but that's not everyone. I don't see the point in making everyone on Mesa drivers or with more RAM enabled suffer.
Unconditionally enabling it on NV also just seems like a bad idea because there's plenty of games where RAM usage isn't a problem but missing shader cache would be.
And yes, >7GB of RAM usage for pipelines is insane, but that's not really something we can solve inside DXVK, that's a driver problem. Of course we could cache to disk ourselves with recent Vulkan extensions, but that's going to be weeks of work to give everyone else an objectively worse experience.
Edit: For reference, the game uses ~8GB of RAM in total on my AMD setup after loading all shaders.
im now also havign the game use 100% of my cpu and spike its temps to 90C for the first 5 minutes of the game being open
im now also havign the game use 100% of my cpu and spike its temps to 90C for the first 5 minutes of the game being open
Great, this means shader pre-compile is working entirely as intended! Maybe invest in a better CPU cooler though if that's an issue.
Anyway, nothing actionable here really.
@doitsujin though, is it compatible with steam shader pre-caching, so it can done before launching the game?
Steam might not have up to date shaders currently because we've been making a bunch of changes in that area. Also DXVK will always have to run its own compiler on the game's shaders, but it also does some caching of its own and it only takes a fraction of the time spent inside the Nvidia driver anyway.
Solved for me.
ge-proton10-15x1 2025-09ge-proton10-1x2 2025-07proton experimentalx1 2024-02proton 8.0-5x1 2024-01PROTON_USE_WINED3D=1x1 2024-07__GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1`x1 2024-02__GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1`.x1 2024-01__GL_SHADER_DISK_CACHE_SIZEx1 2024-01
Software information
Overwatch 2 on Steam (https://store.steampowered.com/app/2357570/Overwatch_2/)
Any graphical preset, mainly tested on Low
System information
Log files
The game's logs are hundreds of megabytes due to spam:
warn:seh:dispatch_exception unknown exception (code=6ba) raised5 times, thenwarn:seh:dispatch_exception EXCEPTION_PRIV_INSTRUCTION exception (code=c0000096) raisedonce, thenwarn:seh:dispatch_exception EXCEPTION_SINGLE_STEP exception (code=80000004) raised~140k times, then finallywarn:seh:dispatch_exception EXCEPTION_ILLEGAL_INSTRUCTION exception (code=c000001d) raisedwhen I close the game.So here is a version that cuts it off after a few of them (from ~400 MB). Let me know if I trimmed anything important:
steam-2357570-trim.log
steam-2357570-trim-nogpl.log
Description
OW2 suffers from high RAM utilization with GPL enabled
With GPL enabled, the game initially uses ~5 GB of RAM and after around 7 minutes of "Compiling Shaders" the game settles on 8.5 to 9 GB of RAM. Without GPL, "Compiling Shaders" still occurs for several minutes but RAM utilization only gets close to 6 GB. On Windows, the game uses only 5 GB.
Steam does compile shaders and all of that, but it has no effect; the game still compiles shaders every time you open it, with the first time going from 0% to 100% and every subsequent run just does "Compiling Shaders" with no number.
In-game FPS drops to roughly half of whats expected, even for Linux
With the system I tested on Low, the game previously (before coming to Steam) ran at around ~180 FPS on the Practice Range, and currently it sits at around ~90 FPS with its latest version.
That 90 FPS is not stable, however. After loading a map, the game does run slightly above that 50% FPS range, but shortly after drops and becomes unstable.
I have also noticed that my mouse's polling rate affects the game significantly, roughly like this:
1000 Hz ~35% FPS drop, 500 Hz ~12%, and 250 Hz is negligible. In other Wine games this doesn't happen.
Two ways I know how to force shaders to compile and stress the game to help tests are: playing the 1 dad vs 11 kids custom game mode which switches everybody's heroes every minute, and the
HEZHJbenchmark workshop code (Custom game -> Create -> Import code).On my more powerful machine the FPS issues are less noticeable overall but still a massive downgrade.