I have a problem with game not registering input from mouse. From keyboard only ESC key works - nothing else. Tried Proton 8.0-3, Experimental and Hotfix - all the same behaviour. Sometimes it works though and I have no idea why.

Performance is way lower than on Windows - on Linux I'm geting only around 80-90 fps on 6800 xt.

Performance is pretty good for me. I'm at around 144 fps at 1440p with FSR 2.2 and it looks great. (3060ti, 3700x)

Only issues for me:

• Game can flicker the alt+tabbing or in the gnome activity view
• Cursor sometimes not displaying but still being able to select items (usually fixed by going into esc menu and back out)
• Random FPS lag down to ~70 FPS for like 1 second (very rarely happens)
• Voice chat didn't work for me but started working with the latest Proton GE
• Unable to export highlights or POTGs as video files (even with proton GE)
  • Finished when exporting as webm format but resulted in a corrupted file that can't be played

idk why this hasnt been reported yet but using either proton experimental (bleeding edge) or proton 8.0-4 the fps is stuck at 40fps but with proton-ge-8-16 the fps is fine

as you can see here the fps is good here with proton-ge
running fedora 39 beta with kde plasma with mesa 23.2.1

I have a problem with game not registering input from mouse. From keyboard only ESC key works - nothing else. Tried Proton 8.0-3, Experimental and Hotfix - all the same behaviour. Sometimes it works though and I have no idea why.

Performance is way lower than on Windows - on Linux I'm geting only around 80-90 fps on 6800 xt.

Don't have input problem anymore, but performance is still below expectations with stock proton (only about 90-100 fps on 6800xt radv 23.2.1).

Has anyone managed to get valid .webm saved highlights?

I can see the CPU doing work while the video is encoded, but the resulting files are only ~770KiB. They won't play in any player, and mediainfo says they are only 1ms long.

@foresto it used to work, but I also tried recently and also got 770 kb broken file

I have a problem with game not registering input from mouse. From keyboard only ESC key works - nothing else. Tried Proton 8.0-3, Experimental and Hotfix - all the same behaviour. Sometimes it works though and I have no idea why.
Performance is way lower than on Windows - on Linux I'm geting only around 80-90 fps on 6800 xt.

Don't have input problem anymore, but performance is still below expectations with stock proton (only about 90-100 fps on 6800xt radv 23.2.1).

Performance is within expectations on proton-ge 23 (maybe it worked in earlier versions - didn't test), so that's what I'm using now. I have no more problems.

The mouse sens via proton is way off from windows. It's sad that valve doesn't invest in input consistency of games played via proton. Vanilla proton doesn't even support raw imput, my KDE mouse sens impacts in-game sens, which is not right. Proton GE fixes that, but the sens is still off from that on windows.

The mouse sens via proton is way off from windows. It's sad that valve doesn't invest in input consistency of games played via proton. Vanilla proton doesn't even support raw imput, my KDE mouse sens impacts in-game sens, which is not right. Proton GE fixes that, but the sens is still off from that on windows.

X11 or wayland?

The mouse sens via proton is way off from windows. It's sad that valve doesn't invest in input consistency of games played via proton. Vanilla proton doesn't even support raw imput, my KDE mouse sens impacts in-game sens, which is not right. Proton GE fixes that, but the sens is still off from that on windows.

X11 or wayland?

KDE Wayland

The mouse sens via proton is way off from windows. It's sad that valve doesn't invest in input consistency of games played via proton. Vanilla proton doesn't even support raw imput, my KDE mouse sens impacts in-game sens, which is not right. Proton GE fixes that, but the sens is still off from that on windows.

X11 or wayland?

KDE Wayland

If you try x11 its way better

On kde plasma 6 dev they changed how it works under wayland and its a lot better aswell

If you try x11 its way better

On kde plasma 6 dev they changed how it works under wayland and its a lot better aswell

Well, in my opinion games like Overwatch 2 and Apex Legends that support raw mouse input should behave the same everywhere no matter what OS or DE you use. The only way it to be better is to be 1:1 compared to windows with no interference from the system settings. And input inconsistency won't attract FPS enthusiasts to Linux.

If you try x11 its way better

On kde plasma 6 dev they changed how it works under wayland and its a lot better aswell

Well, in my opinion games like Overwatch 2 and Apex Legends that support raw mouse input should behave the same everywhere no matter what OS or DE you use. The only way it to be better is to be 1:1 compared to windows with no interference from the system settings. And input inconsistency won't attract FPS enthusiasts to Linux.

Yes i agree, i play competitive fps games and i am masters in apex, masters on overwatch

Whenever i want the closest mouse input i use x11 or now im using kde plasma 6 wayland, i can easily keep up with my friends who are gm in overwatch and i got a 4k badge today on the new mouse input under plasma 6 wayland on apex. i guess i prefer mouse input on x11 or kdes new approach for mouse input on wayland under plasma 6

Has anyone managed to get valid .webm saved highlights?

I can see the CPU doing work while the video is encoded, but the resulting files are only ~770KiB. They won't play in any player, and mediainfo says they are only 1ms long.

Its an overwatch issue. Not a proton issue. webm doesnt work on windows natively

webm doesnt work on windows natively

In that case, has anyone managed to get valid .mp4 saved highlights?

Is the game really supposed to be using 10GB+ of RAM? After the game loads initially, it uses ~5GB but after the "Compiling shaders" step finishes, it sits at least above 11GB of RAM.
The game itself is playable (with a performance hit) before this, so I can't imagine it being correct behavior.
I vaguely remember this not being an issue a couple of months ago. I tested Proton 8, Experimental, GE and TKG.

INFO:
Steam Flatpak
Kernel: 6.6.10-arch1-1
DE: KDE Plasma 5.27.10
WM: KWin (Wayland), X11 is the same
NVIDIA: 545.29.06

Htop shows 4720MB reserved, max settings, FSR2.2 to 4k max quality. Arch, KDE Wayland, Mesa RADV.

Here are some screenshots of how it behaves:

Right after loading the game, the game does actually use 5GB, but I forgot to screenshot the exact moment

Compiling Shaders

Finished compiling shaders

In the middle of a match (Suravasa)

After the match

After closing the game, it takes a while for it to fully exit; longer sessions do end up using a little more memory. The game also does this with swap if you don't have enough memory, in this test it used no swap.

Forgot to mention in the last post that I am using __GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1 and an NVIDIA Prime system.

Edit: Just checked, and the env var for skipping cleanup does not make a difference; it still behaves the same with and without it.

Is the game really supposed to be using 10GB+ of RAM? After the game loads initially, it uses ~5GB but after the "Compiling shaders" step finishes, it sits at least above 11GB of RAM. The game itself is playable (with a performance hit) before this, so I can't imagine it being correct behavior. I vaguely remember this not being an issue a couple of months ago. I tested Proton 8, Experimental, GE and TKG.

INFO: Steam Flatpak Kernel: 6.6.10-arch1-1 DE: KDE Plasma 5.27.10 WM: KWin (Wayland), X11 is the same NVIDIA: 545.29.06

I have the same issue, using Proton Experimental, Proton-GE and Proton 8. On htop "Overwatch.exe" uses 5 GB when opening the game but then after a couple of minutes it drops even under 10 MB, while the memory is in reality being clogged out (using around 20 GB+ being the only open app, 2 GB used on idle) making the game going 2 FPS and the system totally unstable, with difficulties to close the game too. Right now is unplayable. Also, during the brief time of normal usage, Proton-GE achieves 120 FPS+ with no problems while Proton Experimental and Proton 8 are stuck on 20 FPS with the exact settings.

GPU: NVIDIA GTX 1660 Super with 545.29 driver
RAM: 8 GB + 16 GB swap
OS: Fedora Workstation 39 using X11 with GNOME 45
Kernel: 6.6.9
Steam RPM

Replying to https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-1890753226

I can confirm that I also experience a brief period where it hits high frame rates before plummeting down to around 50% of the expected FPS, not thermal or map-related.

Regarding the 20 FPS I can also confirm that, depending on the Proton version, the game gets locked at around 44–47 FPS for me, with the only fix being to delete the prefix. Switching versions also causes this problem. One way I replicated this issue was to use Experimental/GE and then switch to Proton 8.

Another issue I experience is extremely high CPU usage when moving the mouse if I have a high polling rate. With 1000 Hz I get ~35% less FPS, with 500 Hz ~12% less, and with 250 Hz I see almost no difference.

Since "Compiling Shaders" appears for the entire period where the RAM usage increases I tested the game without GPL by using DXVK_CONFIG="dxvk.enableGraphicsPipelineLibrary = False" as an environment variable and the RAM issue was mostly gone. Stutters get predictably worse.

Without GPL, the game starts at around 2.5 GB of RAM and increases after playing some matches to around 4.8 GB. The mouse polling rate issue persists.
Since this could be an DXVK issue, I'll try to make an issue on their repo when I can if this isn't Proton/Wine related.

Also, the game's PROTON_LOG=1 are hundreds of megabytes (370 MB at 15 minutes of play) due to a spam that goes like this:
warn:seh:dispatch_exception unknown exception (code=6ba) raised 5 times, then
warn:seh:dispatch_exception EXCEPTION_PRIV_INSTRUCTION exception (code=c0000096) raised once, then
warn:seh:dispatch_exception EXCEPTION_SINGLE_STEP exception (code=80000004) raised ~140k times, then finally
warn:seh:dispatch_exception EXCEPTION_ILLEGAL_INSTRUCTION exception (code=c000001d) raised when I close the game.

Another issue I have is that, sometimes, when the mouse cursor is unlocked (hero selection, pinging, emoting, etc.) the moment it locks again my aim moves all the way up or down, meaning I can't use voice lines in the middle of a fight without the fear of getting completely lost.

Replying to https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-1901743831

I just tested GE-Proton 8-27, 25, 20, 15, 10, 5, and TKG, and they all have the same problems. I also tested GE-Proton 7-55, but the game didn't launch because it couldn't detect Steam.

Given how all of these versions have the same issues, I suspect it was probably a game update that causes them.

After the Wine 9 rebalance of Proton Experimental the game looses window focus after a match and you can't regain it. I can load up the game fine, play a game normally and on the play of the game screen the game just looses focus on its own with no way to get it back.

Proton Experimental was working totally fine before the rebase to wine 9.

I feel like we had a similar problem in the past .. maybe a game specific patch got missed in the rebase?

Still works as expected under Proton 8.

Am using the steam version of the game.

@TerohsLab I played a quickmatch in proton experimental and couldn't reproduce your focus loss issue, does it only happen with specific game modes?

@TerohsLab I've been playing OW2 with Proton 9 beta and experimental for 4 days now without any difference to previous experimental.

Yeah i can't reproduce it currently. Played 10 quickplay games with logging turned on and it didn't reoccur.

I swear it happened multiple times ( in comp tho ) and through restarts .. and it felt like the same bug that we had before .. the one where would loose window focus on hero death from like 2 years ago.

Hopefully it was just some hickup in Tumbleweed. Once i can nail it down more i will report back.

@kisak-valve https://gist.github.com/TerohsLab/f3a5e1391899eec510909b07a78390fe in case it will become relevant later.

i see that with the latest proton experimental(bleeding edge) the fps is back to normal on mesa 24 under arch,
let me know if anyone else is also getting normal fps without using proton-ge under an amd card on latest mesa with latest proton experimental(bleeding edge)

Got the crash on camera :
Uploading steam-2357570.zip…

https://filetransfer.io/data-package/FHUFZDHH#link

Another

https://filetransfer.io/data-package/8lPVideP#link

Had two more crashes mid comp games. reverting to proton 8 now.

Unless you want specifics .. im out.

@TerohsLab you originally talked about a focus issue, are you talking about a different issue now? and how reproducible were those crashes? were those the first games in a given session? or did you instead play several times before those crashes?

First one was a focus issue, the last 3 straight up crashed the game mid match. I could still hear sound, but graphics froze and i had the force close the game mid comp match.

This happened after having the game open for at least 3-4 hours and many perfectly fine games in comp and open queue.

@Redhawk18 Have you noticed if the crashes always happen when performing specific actions or being in certain game modes? How many crashes have you encountered? And I see from the logs that you're using proton experimental, have you seen if the crashes still happen on proton 8?

@Redhawk18 Have you noticed if the crashes always happen when performing specific actions or being in certain game modes? How many crashes have you encountered? And I see from the logs that you're using proton experimental, have you seen if the crashes still happen on proton 8?

True be told these crashes have been happening 2021, long before I even used proton. I believe it has something to do with AMD's RDNA1 drivers and I've reached out on their forums and heard nothing back. Historically what would happen is my entire computer would freeze due my graphics card firmware crashing on both Windows and Linux. However more recently Overwatch itself just crashes, not my entire computer. So that's an improvement for sure, but I've never had a smooth time with this game. I'm sure its related to hardware or maybe I just have a lost the silicon lottery with my gpu.

Same freezes, but on Nvidia gpu. Sometimes game just freezes (in game music continues to play) and freezes steam UI (I can't move cursor to Steam window, cursor goes behind it

@E-D-W-I-N in what proton versions? Is this a new behavior? I assume there's some variability, but roughly how long does it take for these to occur? It would also be helpful for you to share your specifications and proton log.

Please add PROTON_LOG=1 %command% to the game's launch options and attach the generated $HOME/steam-$APPID.log to this issue report as a file.
You can retrieve a full system information report by clicking Help > System Information in the Steam client on your machine. Then upload it to Gist

@E-D-W-I-N in what proton versions? Is this a new behavior? I assume there's some variability, but roughly how long does it take for these to occur? It would also be helpful for you to share your specifications and proton log.

Please add PROTON_LOG=1 %command% to the game's launch options and attach the generated $HOME/steam-$APPID.log to this issue report as a file. You can retrieve a full system information report by clicking Help > System Information in the Steam client on your machine. Then upload it to Gist

It's started to happen for me with a mid-season patch last week. It's usually happens within first 3 games so, around a 30 min mark? Although I had it freeze on a very first match in competetive mode, which tend to be prone to crashes even on windows. I've captured proton log just now, but it's 33 Mb compressed (1.7GiB uncompressed with 20mil lines).

Last lines before the end of the log:

17283.327:0128:0290:trace:unwind:dump_unwind_info unwind info at 000000009E183798 flags 3 prolog 0x4f bytes function 000000009E17F540-000000009E17F93F
17283.327:0128:0290:trace:unwind:dump_unwind_info     frame register rbp offset 0x80(%rsp)
17283.327:0128:0290:trace:unwind:dump_unwind_info     0x4f: leaq 0x80(%rsp),rbp
17283.327:0128:0290:trace:unwind:dump_unwind_info     0x47: subq $0x98,%rsp
17283.327:0128:0290:trace:unwind:dump_unwind_info     0x40: pushq %rbx
17283.327:0128:0290:trace:unwind:dump_unwind_info     0x3f: pushq %rdi
17283.327:0128:0290:trace:unwind:dump_unwind_info     0x3e: pushq %rsi
17283.327:0128:0290:trace:unwind:dump_unwind_info     0x3d: pushq %r12
17283.327:0128:0290:trace:unwind:dump_unwind_info     0x3b: pushq %r13
17283.327:0128:0290:trace:unwind:dump_unwind_info     0x39: pushq %r14
17283.327:0128:0290:trace:unwind:dump_unwind_info     0x37: pushq %r15
17283.327:0128:0290:trace:unwind:dump_unwind_info     0x35: pushq %rbp
17283.327:0128:0290:trace:unwind:dump_unwind_info     handler 000000009E1714A0 data at 000000009E1837B8
17283.327:0128:0290:trace:unwind:call_unwind_handler calling handler 000000009E1714A0 (rec=00000000179DB5F0, frame=00000000179DB8F0 context=00000000179DAB50, dispatch=00000000179DA2D0)
17283.327:0128:0290:trace:unwind:call_unwind_handler handler 000000009E1714A0 returned 1
17283.327:0128:0290:trace:seh:RtlRestoreContext returning to 000000009E17F813 stack 00000000179DB8F0
17283.330:0128:0290:trace:seh:RtlDeleteFunctionTable 000000009E186000
17288.304:0128:012c:err:sync:RtlpWaitForCriticalSection section 0000000015CC0048 (null) wait timed out in thread 012c, blocked by 0290, retrying (60 sec)
17291.543:0128:0178:err:sync:RtlpWaitForCriticalSection section 0000000015CC0048 (null) wait timed out in thread 0178, blocked by 0290, retrying (60 sec)
17336.028:0150:0154:trace:mscoree:DllMain (00006FFFFC340000, 0, 0000000000000000)
17336.028:0150:0154:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\mscoree.dll" : builtin
17336.028:0150:0154:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\ole32.dll" : builtin
17336.028:0150:0154:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\coml2.dll" : builtin
17336.028:0150:0154:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\combase.dll" : builtin
17336.028:0150:0154:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\rpcrt4.dll" : builtin
17336.028:0150:0154:trace:loaddll:free_modref Unloaded module L"Z:\\mnt\\ssd\\SteamLibrary\\steamapps\\common\\Overwatch\\ErrorReporting\\x64\\dbghelp.dll" : builtin
17336.028:0150:0154:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000011FEB0
17336.031:00e4:0328:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
17336.050:0030:032c:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
17336.051:0030:0330:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
17336.052:0030:0338:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
17336.052:0030:0334:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
17336.052:0030:033c:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
pid 109456 != 109455, skipping destruction (fork without exec?)

Full log here: https://drive.proton.me/urls/9NXRH89QAM#tN34zNvXpxMv

System info here: https://gist.github.com/agurenko/5d0fbc28b11723092c1c30d410535f02

@E-D-W-I-N in what proton versions? Is this a new behavior? I assume there's some variability, but roughly how long does it take for these to occur? It would also be helpful for you to share your specifications and proton log.

Please add PROTON_LOG=1 %command% to the game's launch options and attach the generated $HOME/steam-$APPID.log to this issue report as a file. You can retrieve a full system information report by clicking Help > System Information in the Steam client on your machine. Then upload it to Gist

Got some logs just a few minutes ago. Game just turns to completely black screen and won't close even through Steam's library (stop button).

Last lines before the end of the log:

16257.444:0120:01c4:warn:seh:dwarf_virtual_al_unwind next function rip=0000739ada396a3c
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind   rax=0000000000000000 rbx=0000739ada3191e0 rcx=0000739ad9a3df50 rdx=00007397d255f7c0
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind   rsi=0000000000000002 rdi=0000739a51a5d740 rbp=0000000000000000 rsp=0000000100d42950
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind    r8=0000000000000000  r9=00000000ffffffff r10=0000000000000000 r11=0000739ad85e82d0
16257.444:0120:01c4:trace:unwind:dwarf_virtuunwind backtrace: 0x739ada396a3c: /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libc.so.6 + 0x108a3c.
16257.444:0120:01c4:trace:unwind:execute_cfa_instructions 739ada396a35: DW_CFA_def_cfa %rsp, 8
16257.444:0120:01c4:trace:unwind:execute_cfa_instructions 739ada396a35: DW_CFA_offset %rip, -8
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind fde 0x739ada45352c len 10 personality (nil) lsda (nil) code 739ada396a35-739ada396a46
16257.444:0120:01c4:trace:unwind:execute_cfa_instructions 739ada396a35: DW_CFA_undefined %rip
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind   r12=fffffffffffffb68 r13=0000000000000002 r14=00000001000ff880 r15=0000000100a00000
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind function 739ada396a3c base 0x739ada396a35 cie 0x739ada43a7a0 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip
16257.444:0120:01c4:warn:seh:dwarf_virtual_unwind backtrace: 0x739ada396a3c: /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libc.so.6 + 0x108a3c.
16257.444:0120:01c4:trace:unwind:execute_cfa_instructions 739ada396a35: DW_CFA_def_cfa %rsp, 8
16257.444:0120:01c4:trace:unwind:execute_cfa_instructions 739ada396a35: DW_CFA_offset %rip, -8
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind fde 0x739ada45352c len 10 personality (nil) lsda (nil) code 739ada396a35-739ada396a46
16257.444:0120:01c4:trace:unwind:execute_cfa_instructions 739ada396a35: DW_CFA_undefined %rip
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind next function rip=0000739ada396a3c
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind   rax=0000000000000000 rbx=0000739ada3191e0 rcx=0000739ad9a3df50 rdx=00007397d255f7c0
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind   rsi=0000000000000002 rdi=0000739a51a5d740 rbp=0000000000000000 rsp=0000000100d42958
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind    r8=0000000000000000  r9=00000000ffffffff r10=0000000000000000 r11=0000739ad85e82d0
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind   r12=fffffffffffffb68 r13=0000000000000002 r14=00000001000ff880 r15=0000000100a00000
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind function 739ada396a3c base 0x739ada396a35 cie 0x739ada43a7a0 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip
16257.444:0120:01c4:warn:seh:dwarf_virtual_unwind backtrace: 0x739ada396a3c: /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libc.so.6 + 0x108a3c.
16257.444:0120:01c4:trace:unwind:execute_cfa_instructions 739ada396a35: DW_CFA_def_cfa %rsp, 8
16257.444:0120:01c4:trace:unwind:execute_cfa_instructions 739ada396a35: DW_CFA_offset %rip, -8
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind fde 0x739ada45352c len 10 personality (nil) lsda (nil) code 739ada396a35-739ada396a46
16257.444:0120:01c4:trace:unwind:execute_cfa_instructions 739ada396a35: DW_CFA_undefined %rip
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind next function rip=0000739ada396a3c
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind   rax=0000000000000000 rbx=0000739ada3191e0 rcx=0000739ad9a3df50 rdx=00007397d255f7c0
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind   rsi=0000000000000002 rdi=0000739a51a5d740 rbp=0000000000000000 rsp=0000000100d42960
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind    r8=0000000000000000  r9=00000000ffffffff r10=0000000000000000 r11=0000739ad85e82d0
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind   r12=fffffffffffffb68 r13=0000000000000002 r14=00000001000ff880 r15=0000000100a00000
16257.444:0120:01c4:trace:unwind:dwarf_virtual_unwind function 739ada396a3c base 0x739ada396a35 cie 0x739ada43a7a0 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip
16257.444:0120:01c4:warn:seh:dwarf_virtual_unwind backtrace: 0x739ada396a3c: /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libc.so.6 + 0x108a3c.
pid 18929 != 18928, skipping destruction (fork without exec?)

As I can see there's the same last line as in @agurenko's logs, pid's is the only difference

I've noticed that game is freezing way more often when I switch my workspaces (I'm using tiling WM) for example to change the music while I search for the match or smth. But sometimes game can freeze even if it's the only opened app in my system

I can attach the full log to Google drive or another service if you need it. GitHub is allowing only 25MB file, but my logs are 790MB :)

Here's my system info: https://gist.github.com/E-D-W-I-N/a90f9cabc4406a813d8fb4cbfd07bb82

I recently experienced some freezes also in multiple games and found out that kernel 6.7 and 6.8 both freeze my computer with my amd card, using 6.6 LTS i havent experienced a single crash on any game yet and its been 2 days. Every time I go back to 6.7 or 6.8 i experience the same crashes

Just a quick update from my side, I've forced Proton 8 after posting my logs and have not had any freezes since then

so you're both on amd and 6.8 kernel, one had luck with downgrading the kernel and the other with proton.
@polluxau have you tried using proton 8 with kernel 6.8 to see if the issue still happens there?

so you're both on amd and 6.8 kernel, one had luck with downgrading the kernel and the other with proton.
@polluxau have you tried using proton 8 with kernel 6.8 to see if the issue still happens there?

I'm third here 😂 on Nvidia. I'll try proton 8 today. Hope it helps

so you're both on amd and 6.8 kernel, one had luck with downgrading the kernel and the other with proton. @polluxau have you tried using proton 8 with kernel 6.8 to see if the issue still happens there?

ill have a try, give me a couple of minutes

i have tested overwatch 2 for 30 minutes under kernel 6.8.1 with proton-ge8-32 as normal proton 8 has fps issues with amd cards

this was also tested under gnome 46 wayland, while the crashes i mentioned were on plasma 6 wayland so the cause of the problem could be plasma 6 wayland, not to do with the kernel or it could be a proton 9 issue, unsure still

also tested halo infinite under gnome 46 and latest proton experimental(bleeding edge) and it hasn't crashed, so the issue im talking about could be entirely different from the crashes you guys are getting, my conclusion is its kde plasma 6 wayland crashing randomly not the kernel or proton, ill be waiting for plasma 6.0.3 to come out in a few days to see if this occurs once again

Ever since about maybe 2 weeks ago, I've been experiencing the same issue as @agurenko and @E-D-W-I-N. I haven't encountered it again, though, after switching from the bleeding edge branch of Proton Experimental to GE-Proton9-1. I'll update this if the issue does happen again.

UPDATE 1: I'm now using GE-Proton9-2, and still haven't encountered the issue again after a freakishly long time of playing. I would recommend switching to this to anyone who has the same issue.

UPDATE 2: I encountered the issue again. It could be possibly related to me upgrading from GNOME 45 to GNOME 46. I'm also wondering if it's an issue specific to RDNA 2.

Yesterday I tried OW2 for around an hour and a half with proton 9 and linux 6.8.1 and couldn't get the game to freeze or crash, this was with a RDNA2 card.

Just tried this myself and got a hang with kernel write watch disabled, so looks like that's not the culprit.

Latest bleeding-edge and hang after a few hours after playing on 6.6.23-1-lts, so 6.6 isn't immune here.

Caught another freeze on Proton 9 and Arch 6.8.2

Here's some Proton logs

1806.795:0120:027c:trace:unwind:dump_unwind_info unwind info at 00006FFFFFFD7C18 flags 0 prolog 0x0 bytes function 00006FFFFFF4F23C-00006FFFFFF4F267
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x0: movq %r15,0xf0(%rsp)
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x0: movq %r14,0xe8(%rsp)
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x0: movq %r13,0xe0(%rsp)
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x0: movq %r12,0xd8(%rsp)
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x0: movq %rdi,0xb0(%rsp)
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x0: movq %rsi,0xa8(%rsp)
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x0: movq %rbp,0xa0(%rsp)
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x0: movq %rbx,0x90(%rsp)
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x0: subq $0x590,%rsp
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x0: PUSH_MACHFRAME 0
1806.795:0120:027c:trace:unwind:RtlVirtualUnwind type 2 rip ee799580 rsp 17bbb760
1806.795:0120:027c:trace:unwind:dump_unwind_info **** func 94c0-96cf
1806.795:0120:027c:trace:unwind:dump_unwind_info unwind info at 00000000EE7A5408 flags 0 prolog 0x40 bytes function 00000000EE7994C0-00000000EE7996CF
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x40: subq $0x60,%rsp
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x3c: pushq %rbx
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x3b: pushq %rbp
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x3a: pushq %rdi
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x39: pushq %rsi
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x38: pushq %r12
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x36: pushq %r14
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x34: pushq %r15
1806.795:0120:027c:trace:unwind:RtlVirtualUnwind type 2 rip ee79359a rsp 17bbb800
1806.795:0120:027c:trace:unwind:dump_unwind_info **** func 3570-35b4
1806.795:0120:027c:trace:unwind:dump_unwind_info unwind info at 00000000EE7A5B78 flags 0 prolog 0x7 bytes function 00000000EE793570-00000000EE7935B4
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x7: subq $0x20,%rsp
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x3: pushq %rbx
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x2: pushq %rdi
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x1: pushq %rsi
1806.795:0120:027c:trace:unwind:RtlVirtualUnwind type 2 rip ee79908f rsp 17bbb840
1806.795:0120:027c:trace:unwind:dump_unwind_info **** func 8c70-90f0
1806.795:0120:027c:trace:unwind:dump_unwind_info unwind info at 00000000EE7A53BC flags 3 prolog 0x4e bytes function 00000000EE798C70-00000000EE7990F0
1806.795:0120:027c:trace:unwind:dump_unwind_info     frame register rbp offset 0x80(%rsp)
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x4e: leaq 0x80(%rsp),rbp
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x46: subq $0xe8,%rsp
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x3f: pushq %rbx
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x3e: pushq %rdi
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x3d: pushq %rsi
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x3c: pushq %r12
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x3a: pushq %r13
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x38: pushq %r14
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x36: pushq %r15
1806.795:0120:027c:trace:unwind:dump_unwind_info     0x34: pushq %rbp
1806.795:0120:027c:trace:unwind:dump_unwind_info     handler 00000000EE791000 data at 00000000EE7A53DC
1806.795:0120:027c:trace:unwind:call_unwind_handler calling handler 00000000EE791000 (rec=0000000017BBB530, frame=0000000017BBB840 context=0000000017BBAA90, dispatch=0000000017BBA210)
1806.795:0120:027c:trace:unwind:call_unwind_handler handler 00000000EE791000 returned 1
1806.795:0120:027c:trace:seh:RtlRestoreContext returning to 00000000EE798FD0 stack 0000000017BBB840
1806.805:0120:027c:trace:seh:RtlDeleteFunctionTable 00000000EE7A7000
1811.788:0120:0124:err:sync:RtlpWaitForCriticalSection section 000000000F0A0048 (null) wait timed out in thread 0124, blocked by 027c, retrying (60 sec)
1816.650:0120:0170:err:sync:RtlpWaitForCriticalSection section 000000000F0A0048 (null) wait timed out in thread 0170, blocked by 027c, retrying (60 sec)
1825.347:0148:014c:trace:mscoree:DllMain (00006FFFFC680000, 0, 0000000000000000)
1825.347:0148:014c:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\mscoree.dll" : builtin
1825.347:0148:014c:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\ole32.dll" : builtin
1825.347:0148:014c:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\coml2.dll" : builtin
1825.347:0148:014c:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\combase.dll" : builtin
1825.347:0148:014c:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\rpcrt4.dll" : builtin
1825.347:0148:014c:trace:loaddll:free_modref Unloaded module L"Z:\\home\\edwin\\.local\\share\\Steam\\steamapps\\common\\Overwatch\\ErrorReporting\\x64\\dbghelp.dll" : builtin
1825.348:0148:014c:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000011FEB0
1825.360:00dc:0334:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
1825.580:0030:0338:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
1825.581:0030:033c:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
1825.582:0030:0340:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
1825.582:0030:0344:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
1825.582:0030:0348:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
pid 3485 != 3484, skipping destruction (fork without exec?)

Having some issues with mouse capturing in a few games, Overwatch2 being one of them, I noticed that when i start the game the mouse gets stuck in a invisible line around 20% of the menu feels like i am hitting the end of a wall, I can move it up and down but not to the right side, if I alt tab and mouse the cursor to the other side it fixes, but once i pass the "invisible line" it gets stuck again.

This started once I upgraded to Gnome 46, I also noticed this only happens in multi-monitor setups, with just one monitor it does not happen.
Kernel: ArchLinux 6.8.2-zen2-1-zen
Mesa 24.0.3-2
GPU: 6800XT

Replying to https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2027724723

This didnt occur with me under gnome 46 wayland with 2 monitors on arch with an amd gpu

What proton version?

Replying to [#7033 (comment)](https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2027724723)

This didnt occur with me under gnome 46 wayland with 2 monitors on arch with an amd gpu

What proton version?

Proton Experimental

Replying to https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2027724723

You can try going wayland native. It helped me and other people with mouse capture in THE FINALS.

https://github.com/ValveSoftware/Proton/issues/7317#issuecomment-2016941829

Tested a few more things... besides the reinstalling of the game and redoing the prefix.

Xorg: runs perfectly in multi-monitor not issues there.
Wayland: 1 monitor runs perfectly.

Wayland with multi-monitor: Problems!! - Only when the game is on Fullscreen.
On 1st monitor mouse gets stuck around 20% of the screen, hit an "invisible wall" where I can only move the mouse vertically.
If i change to 2nd monitor mouse gets stuck around 20% of the screen hit an "invisible wall" where I can only move the mouse horizontally!

On borderless window the game runs perfectly, in wayland and xorg.

I only noticed this only on Gnome 46 and found another game with the exact same issue: Ghost Recon Breakpoint, using wine-ge 8-26.

All these issues are happening on the game menus, once I get into the game the mouse gets captured correctly. Very strange

FIXED: Unchecked "Allow the window manager to control the windows" using protontricks, now the mouse is free again :)

Hi, the game is regularly crashing, had 3 in less than 30minutes, got banned for 15minutes, usually in fights, if there is any workaround until a fix come up i'd like to know

I'm still rocking Proton 8.0-5, no issues for weeks now

I'm still rocking Proton 8.0-5, no issues for weeks now

+1. No issues at all on Proton 8. So, I guess crashing and freezing problems starts with Proton 9 version

I'm having huge performance issues when someone speaks on the voice chat, comparable to what i was experiencing with proton 9 except with this one it crashes
I immediatly disabled voice chat and everything was fine again, at least with proton-ge 8.32

I'm getting crashes on Proton 9.0 which seem to happen after compiling shaders for a new patch after about 20-30 minutes. It's been a consistent pattern for the last 3-4 Overwatch patches.

I'm running an AMD 7900 XTX. Proton 9.0.

Here are what appear to be the relevant logs:

86173.492:0124:0128:err:sync:RtlpWaitForCriticalSection section 000000000EFC0048 (null) wait timed out in thread 0128, blocked by 026c, retrying (60 sec)
86177.810:0124:0174:err:sync:RtlpWaitForCriticalSection section 000000000EFC0048 (null) wait timed out in thread 0174, blocked by 026c, retrying (60 sec)

All of the logs before these lines are trace logs which look like this:

86168.517:0124:026c:trace:unwind:dump_unwind_info **** func be40-c240
86168.517:0124:026c:trace:unwind:dump_unwind_info unwind info at 00000000225655AC flags 3 prolog 0x43 bytes function 000000002255BE40-000000002255C240
86168.517:0124:026c:trace:unwind:dump_unwind_info     frame register rbp offset 0x80(%rsp)
86168.517:0124:026c:trace:unwind:dump_unwind_info     0x43: leaq 0x80(%rsp),rbp
86168.517:0124:026c:trace:unwind:dump_unwind_info     0x3b: subq $0xb8,%rsp
86168.517:0124:026c:trace:unwind:dump_unwind_info     0x34: pushq %rbx
86168.517:0124:026c:trace:unwind:dump_unwind_info     0x33: pushq %rdi
86168.517:0124:026c:trace:unwind:dump_unwind_info     0x32: pushq %rsi
86168.517:0124:026c:trace:unwind:dump_unwind_info     0x31: pushq %r12
86168.517:0124:026c:trace:unwind:dump_unwind_info     0x2f: pushq %r13
86168.517:0124:026c:trace:unwind:dump_unwind_info     0x2d: pushq %r14
86168.517:0124:026c:trace:unwind:dump_unwind_info     0x2b: pushq %r15
86168.517:0124:026c:trace:unwind:dump_unwind_info     0x29: pushq %rbp
86168.517:0124:026c:trace:unwind:dump_unwind_info     handler 0000000022551DA0 data at 00000000225655CC
86168.517:0124:026c:trace:unwind:call_unwind_handler calling handler 0000000022551DA0 (rec=00000000166AB870, frame=00000000166ABAF0 context=00000000166AADD0, dispatch=00000000166AA550)
86168.517:0124:026c:trace:unwind:call_unwind_handler handler 0000000022551DA0 returned 1

And the logs after only appear when I hit the button to kill the unresponsive process:

86233.492:0124:0128:err:sync:RtlpWaitForCriticalSection section 000000000EFC0048 (null) wait timed out in thread 0128, blocked by 026c, retrying (60 sec)
86237.808:0124:0174:err:sync:RtlpWaitForCriticalSection section 000000000EFC0048 (null) wait timed out in thread 0174, blocked by 026c, retrying (60 sec)
86244.954:014c:0150:trace:mscoree:DllMain (00006FFFFC390000, 0, 0000000000000000)
86244.954:014c:0150:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\mscoree.dll" : builtin
86244.954:014c:0150:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\ole32.dll" : builtin
86244.954:014c:0150:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\coml2.dll" : builtin
86244.954:014c:0150:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\combase.dll" : builtin
86244.954:014c:0150:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\rpcrt4.dll" : builtin
86244.954:014c:0150:trace:loaddll:free_modref Unloaded module L"Z:\\home\\joey\\.local\\share\\Steam\\steamapps\\common\\Overwatch\\ErrorReporting\\x64\\dbghelp.dll" : builtin
86244.955:014c:0150:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000011FEB0
86244.958:00e0:02bc:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
86244.976:0030:02c0:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
86244.978:0030:02c4:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
86244.978:0030:02c8:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
86244.978:0030:02cc:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
86244.979:0030:02d0:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
pid 40444 != 40443, skipping destruction (fork without exec?)

Very challenging to reproduce the issue. Running the game with the DXVK_STATE_CACHE=reset or DXVK_STATE_CACHE=disable flags did not appear to induce the crashes.

@Jafner I tried deleting mesa's shaders, then the game's dxvk cache, played an hour of unranked matches on proton 9 and I had no issues. Do you crash during compilation? Or running into the compilation makes the game crash at a later point? I ask because the game started fast for me, so I don't think it should normally spend a lot of time compiling shaders.

Also, provide the full log file, it can be important to have the whole thing.

@Jafner I tried deleting mesa's shaders, then the game's dxvk cache, played an hour of unranked matches on proton 9 and I had no issues. Do you crash during compilation? Or running into the compilation makes the game crash at a later point? I ask because the game started fast for me, so I don't think it should normally spend a lot of time compiling shaders.

When I experience crashes it is usually 20-30 minutes after compiling shaders for the first time after a new patch.

It doesn't crash during compilation, which Steam seems to do before launching the game executable.

Crashes are very unpredictable, sometimes I can play 6 hours strait and the other day I can get crashes after 10 minutes of playing 6 times strait so I get banned from games.

I second this : The crashes are completely unpredictable.

Played for 2 days ( 10+ hours ) without any issues and then crashed out of 3 games getting a big temp ban from competitive play.

For me it tends to happen towards or after the play of game for like 70% and then just pure random 30%.

The crashes have been consistent for at least 2 months now on proton experimental after the rebase to proton 9.

Only known workaround for me is using proton 8 on overwatch .. which works. While i literally play all my other games stable on proton experimental.

A tentative fix for the hangs (at least those I saw the logs for) is in the just updated Proton Experimental ([bleeding-edge] branch; that can be selected in BETAS tab in Proton Experimental properties; if the Steam is running it is better to restart it to make sure the updated version is picked up). It was not extensively tested yet but I hope it will do it.

For me, performance with Proton 9/Experimental with bleeding-edge is horrible

And for some reason the GPU is heavily underused.

I have no crashes or performance issues with GE-Proton-25.

Having the same issue with Proton 9. I generally use bleeding edge but reverted back to the recommend proton 8 to resolve the issue. I would be interested to know if the issue was identified and corrected so I can return to bleeding edge. Given the new penalties for "leaving a game" (unpredictable hard freeze), I am hesitant to dive back in.

And we are crashing again even on proton 8.

And we are crashing again even on proton 8.

Based on discussions on steam, it's not linux specific after yesterday's Season 10 release. However I didn't have any issues yesterday.

Played 5 games in a row tonight, proton 8.0-5. No issues.

When playing on the current experimental I get only about 55 fps at the best of times, while on a 6800 xt, 8 and 9 give me over 250 fps.
It seems that attempting to fix one regression exposed or caused another one
Also the processing of vulkan shaders for OW2 always seems to start at 50% when it shows the popup when starting the game

When playing on the current experimental I get only about 55 fps at the best of times, while on a 6800 xt, 8 and 9 give me over 250 fps.
It seems that attempting to fix one regression exposed or caused another one

That issue has been present for a while now on normal proton, i always use proton-ge for overwatch as each time i try regular proton under amd it has this issue, could be something to do with radv in mesa or some hack or certain patch that is applied on ge that normal proton doesn't apply

When playing on the current experimental I get only about 55 fps at the best of times, while on a 6800 xt, 8 and 9 give me over 250 fps.
It seems that attempting to fix one regression exposed or caused another one

That issue has been present for a while now on normal proton, i always use proton-ge for overwatch as each time i try regular proton under amd it has this issue, could be something to do with radv in mesa or some hack or certain patch that is applied on ge that normal proton doesn't apply

huh, I run mesa-git and proton-ge, that's why I never experienced it, thanks for clarifying that
hopefully the regression fix gets backported to GE

@polluxau @Jelgnum the game is capped at 60 fps by default for me, but going to the settings and changing framerate from automatic to custom allows it go higher. Is this not the case for you? Note that the framerate change is only visible in game, not in the menu.

@simifor my settings are set correctly to my 1440p 240hz monitor, the game just doesnt go above 55fps, even in gamescope where I have it set to 240hz in my gamescope args, works fine with proton ge 8 and 9. I haven't tried it with stable 8 or 9 yet, GE just usually runs better with OW 2.

@Jelgnum Well, I compared bleeding edge against GE 9-4, and I'm getting the same performance with both. I'd also recommend to keep in mind deleting a prefix if you see a strange behavior when switching proton versions (though note that you'll likely have to set your video settings again). This was with a RX 6600 and a freshly built mesa-git.

@Jelgnum Well, I compared bleeding edge against GE 9-4, and I'm getting the same performance with both. I'd also recommend to keep in mind deleting a prefix if you see a strange behavior when switching proton versions (though note that you'll likely have to set your video settings again).

I'll give that a try when I get off of work, thanks!

@polluxau @Jelgnum the game is capped at 60 fps by default for me, but going to the settings and changing framerate from automatic to custom allows it go higher. Is this not the case for you? Note that the framerate change is only visible in game, not in the menu.

Yes it is not the case for me on experimental bleeding edge last time i tried it, it did fix itself a while on bleeding edge but then it came back, it could be fixed again, if you scroll back through the bug report you'll see screenshots that i posted comparing experimental bleeding edge vs proton-ge, you'll see that on bleeding edge there is a utilisation issue when going into anything that isnt the menu while on proton-ge there is no problem

@Jelgnum Well, I compared bleeding edge against GE 9-4, and I'm getting the same performance with both. I'd also recommend to keep in mind deleting a prefix if you see a strange behavior when switching proton versions (though note that you'll likely have to set your video settings again). This was with a RX 6600 and a freshly built mesa-git.

So regenerated my prefix last night and it did fix the performance issue, but I still crashed on experimental, I'm going to give it a try on 8.0-5 tonight to see if I crash on stable 8

@Jelgnum by crash do you mean that the game closes itself? A hang/freeze had been reported previously, and that should have hopefully been fixed in proton experimental, I personally haven't had any freeze or crash in ~5 hours since the experimental fix was added. What were you doing when it happened (in a menu, mid-match, just after a game ended)? And how long would you say it took to happen?

If possible, add PROTON_LOG=1 %command% to the game's launch parameters and if you run into the issue again with proton experimental bleeding edge, then grab the log it'll create in your home folder, called steam-2357570.log, compress it as a zip if it's too big. Also, the output of dmesg after crashing, running sudo dmesg > ~/dmesg.log will create a dmesg.log file in your home folder as well.

Replying to https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2075459462

yeah turns out I found a bug between kernel 6.9rc-4 and rc-5, wasn't a proton issue

as you can see here under a rx 6700, proton experimental bleeding edge, it is behaving weird

then when i use proton-ge-9-4 the issue goes away

dont know the specific cause or what patch proton-ge is using

When discussing frame time for this game using DXVK_HUD=pipelines and confirming that the game has loaded all 102k shaders is a must. Otherwise the game stutters even on Windows.

When discussing frame time for this game using DXVK_HUD=pipelines and confirming that the game has loaded all 102k shaders is a must. Otherwise the game stutters even on Windows.

Yes it did load it fully, even the main menu cant hold 60fps properly after, proton-ge on the other hand has been able to use the fps properly, this doesnt occur under nvidia

FWIW experimental bleeding edge is completely fine on my end (also RADV), so this needs to be something that is setup related. It probably doesn't hurt wiping your prefix just in case.

FWIW experimental bleeding edge is completely fine on my end (also RADV), so this needs to be something that is setup related. It probably doesn't hurt wiping your prefix just in case.

after deleting the prefix and having to reinstall the game it is now fixed, thank you for the suggestion

I'm still crashing on the new Proton Experimental build.

This is on a full updated KDE Tumbleweed with 16 GB of ram, a 2060 and proprietary NVIDIA drivers 550.76.

I've played PoE for about 8 hours before that and poe love to only keep 2gb of vram allocated, but flood your ram. I was 12.6GB of ram on a cold start.

When the crash happened, the game froze for like 15s but kept playing sound. Then i was playing in 0.2 FPS while i usually have 138. I then visually saw my char teleporting around the map and then i pulled the manual reset on my PC.

I also saw that the KDE 6 update notifier now has new stuff. I've seen that before after crashes. So maybe the KDE 6 update notifier is the problem?

Played many games of OW2 after the Proton fix and had no issues before.

Huh .. maybe its the official KDE discover update warning :thinking:

Since the new patch came out, my game closes itself after some time, happening in all proton versions

Since the new patch came out, my game closes itself after some time, happening in all proton versions

what hardware, what distro? and how long is after some time?

Since the new patch came out, my game closes itself after some time, happening in all proton versions

are you on Kernel 6.8.9? if so you might be experiencing https://gitlab.freedesktop.org/drm/amd/-/issues/3343

Since the new patch came out, my game closes itself after some time, happening in all proton versions

are you on Kernel 6.8.9? if so you might be experiencing https://gitlab.freedesktop.org/drm/amd/-/issues/3343

I'm on 6.8.7-2 liquorix, but it seems like it's the same problem

Just a quick update on my issue :

Operating System: openSUSE Tumbleweed 20240506
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.1.0
Qt Version: 6.7.0
Kernel Version: 6.8.8-1-default (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Xeon® CPU E3-1231 v3 @ 3.40GHz
Memory: 15.6 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 2060/PCIe/SSE2
Manufacturer: ASUS
Product Name: All `Series

The issue seems to be when the RAM fills up.

I have a swap file and its in use, but i can reproduce the crashed desktop stuff now by just filling up my RAM with firefox tabs.

So while the KDE notifier is not out of the picture yet .. it seems to be related to memory issues and/or incorrect handling of swap .. instead of it being a Proton issue.

I can confirm that is a memory problem, i opened ow and monitored the RAM usage, when it hit the limit, the game crashed

(i have 12gb of ram but in reality 10,1gb)

Question is .. where is the memory problem then?

OW itself, dxvk, kernel, kde or still maybe proton itself ?!

I had Path of Exile Vulkan instances crash literally 10min after launch ( PoE loves to hug 10gb+ ram from the get go ), but i also have a ESO dx11 session on my second monitor thats been running under exceptionally high trial load for 10 hours without any issues .. also consuming 10gb of ram.

Question is .. where is the memory problem then?

OW itself, dxvk, kernel, kde or still maybe proton itself ?!

I had Path of Exile Vulkan instances crash literally 10min after launch ( PoE loves to hug 10gb+ ram from the get go ), but i also have a ESO dx11 session on my second monitor thats been running under exceptionally high trial load for 10 hours without any issues .. also consuming 10gb of ram.

The answer is kernel. There's a patch in that issue thread that fixes the problem.

Amazing news: the bug where the mouse clicks through the window on fullscreen does not occur with Wine's Wayland driver! And the performance is very impressive.

Also, a miscellaneous tip for anyone that may have a Focusrite Scarlet 4i4 3rd Gen USB Audio Interface— the game does not pick up any audio from the microphone by default if you use Pipewire. The fix is to simply use protontricks to change the audio driver in Overwatch 2's WINEPREFIX from winepulse.drv (Pulseaudio) to winealsa.drv (ALSA):

protontricks 2357570 sound=alsa

Yeah, there are a few kernel versions affecting people with amd cards that have rebar disabled.

As far as OW2 memory leaking, I didn't find anything weird on my testing. It needs to be noted that when you launch the game it's going to compile a lot of shaders, these take memory and also take a few minutes to compile, so if you play as these compile it might seem like the game is leaking memory.

Making my measurements in the title screen, and the initial one being done after the shaders were compiled, I saw a memory usage increase of 1GB in both windows and linux after playing several matches.

Played on linux for 2 hours with proton 9 and the memory usage seemed stable, with the last two measurements actually being slightly lower (so it wasn't growing). Windows 10 was tested for half an hour with similar results. So there was a memory increase after having the game load maps, but it wasn't some constant growth.

Well i have a NVidia GPU with a Intel CPU, so the patch will probably not help, but we will see. Skimming through the thread tho .. it seems pretty similar that it crashes around 10gb ram used.

Is there a way to check if i have rebar enabled or if its even supported.

Well i have a NVidia GPU with a Intel CPU, so the patch will probably not help, but we will see. Skimming through the thread tho .. it seems pretty similar that it crashes around 10gb ram used.

Is there a way to check if i have rebar enabled or if its even supported.

Yes check your bios, you need rebar and 4g decoding both enabled

On Intel CPU and Nvidia GPU, the game keeps taking up RAM till it crashes after occupying all available memory. Even after shader compilation is complete(progress tracked via DXVK_HUD), the game continues to use up more memory and eventually crashes. I was previously able to play 2 or 3 games before having to restart but since last week, I can barely play 1 game without crashing, after shaders have been compiled. Restarting no longer works either as the game uses almost the entire available memory at the main menu now. I have swap memory disabled so the crashes occur regularly

You really just need to create a swap partition or swapfile. The memory usage will increase until the game fully loads all shaders which takes around 10 minutes. There is no memory leak as far as I know and the excessive amount of shader in this game simply makes it reliant on swap to function properly on low memory systems.

You really just need to create a swap partition or swapfile. The memory usage will increase until the game fully loads all shaders which takes around 10 minutes. There is no memory leak as far as I know and the excessive amount of shader in this game simply makes it reliant on swap to function properly on low memory systems.

Well yeah .. thats what you think it would do.

Here is me starting Overwatch 2 after using my PC for 10h for random office work and using about 3gb of ram before launched.

• 30 min into the loading screen .. no games played no nothing, just waiting for shaders to be done ( which they where 20min ago as of taking this picture )
• Memory overview 1 with 2gb of swap
• Memory overview 2 with 2gb of swap

Its an issue with overwatch.

Operating System: openSUSE Tumbleweed 20240512
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.0
Kernel Version: 6.8.8-1-default (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Xeon® CPU E3-1231 v3 @ 3.40GHz
Memory: 15.6 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 2060/PCIe/SSE2
Manufacturer: ASUS
Product Name: All Series

The tool used is Mission Center.

Yes check your bios, you need rebar and 4g decoding both enabled

Is there a way to check from inside the OS?

I can also confirm this behaviour after a full cold reset of the system.

• Power down for 20min
• Boot
• Swap at 200mb / 2 gb
• Launch OW2 as the only program ( with proton experimental )
• Within 1 min swap is sitting at 1.7gb / 2gb and ram is 10 gb out of 16 gb

@ishitatsuyuki Unfortunately i dont have the drive space to allocate for swap.

After shader compilation is complete i have around 13gb ram used but joining a match takes me to 14 - 14.8gb used. after the match this goes down to 13.5 - 13.8gb but not restarting will cause OOM and crash the game in the next match. The game appears to leak memory slowly during and after matches.

@ishitatsuyuki Unfortunately i dont have the drive space to allocate for swap.

After shader compilation is complete i have around 13gb ram used but joining a match takes me to 14 - 14.8gb used. after the match this goes down to 13.5 - 13.8gb but not restarting will cause OOM and crash the game in the next match. The game appears to leak memory slowly during and after matches.

You could try zRam (basically compressed swap in ram), perhaps it will save you some ram. But 13.5gb in ram is not normal at all, I've got only 4.4GB at 4k max settings +hdr enabled with my rx7800xt

Had a major crash again :

• Using Proton Experimental with lasted KDE Tumbleweed
• Play Overwatch 2 for 2-3 hours without any issues after the system has been up for 10 hours or so
• Overwatch 2 running in 2k in windowless boarder thingy on my main monitor
• Had overwatch 2 still running on my main monitor when
• I had do do stuff on my second one which took about an hour ( so the main OW2 window went out out of focus )
• OW2 took up all my RAM and zRAM and SWAP and brought the system to a hold

The system didn't crash, but it was very clearly struggling with RAM. I reset my system because it became the faster choice.

I did get a "System Monitor" view of the system before the omega slowdown to 1 frame per 10s and it had my RAM at 98% | 100% swap.

I do have 4G and rebar enabled.

My kernel updated to 6.8.10 and now i dont have any issues

Does anyone know what causes this error Steam?
Debian12 Kernel 6.8
R7-1800x
1060-6GB NvidiaDrivers

You could try zRam (basically compressed swap in ram), perhaps it will save you some ram. But 13.5gb in ram is not normal at all, I've got only 4.4GB at 4k max settings +hdr enabled with my rx7800xt

i should have clarified: 13.5gb with steam and discord running in the background. total ram usage by steam, discord, DE comes upto around 3.8 - 4(rarely) gb. so OW 2 is taking up almost 10gb(and rising) after shader compilation.

Does anyone know what causes this error Steam? Debian12 Kernel 6.8 R7-1800x 1060-6GB NvidiaDrivers

Im having this as well
OS: Solus resilience 4.5 x86_64
Kernel: Linux 6.9.8-294.current
DE: GNOME 46.3.1
WM: Mutter (Wayland)
GPU: NVIDIA GeForce RTX 4070 SUPER
Nvidia driver 555.58.02 Beta

iv always wondered why overwatch cant read my temp on the amd rx 6700 but when i was on my nvidia rtx 2060 it could read it?

nvidia must use the same type of driver for reading temps on both windows and linux or proton has something hooked up for nvidia

overwatch cant read my temp on the amd rx 6700 but when i was on my nvidia rtx 2060 it could read it?

I have an Nvidia card and it can't read the temperature. How long ago did you see it work on your 2060?

overwatch cant read my temp on the amd rx 6700 but when i was on my nvidia rtx 2060 it could read it?

I have an Nvidia card and it can't read the temperature. How long ago did you see it work on your 2060?

Would have been around a year ago or so, this would have been on the 535 driver and through the blizzard launcher

Actually it might have been before overwatch 2 entirely now that i think of it lol

Maybe thats why it doesnt work anymore

I am unable to save replays. Ends up in an unknown error 6-04.
I have checked the directory permissions. I'm also running Steam version 1724453533 and running Overwatch 2 with stable proton 9.
https://gist.github.com/roope242/e9728beb33240afdb5d4fcb8d810b49e
https://gist.github.com/roope242/d37cdc84d23547fd3a90fc0a823c4bd5

The current proton experimental seems to have broken performance in Overwatch. The GPU clock is fluctuating a lot and I can't get above unstable 60fps on a high end system.
(ProtonGE 13 has the problem as well, 12 is fine)

I will post logs later when I'm back at my pc.

The current proton experimental seems to have broken performance in Overwatch. The GPU clock is fluctuating a lot and I can't get above unstable 60fps on a high end system.
(ProtonGE 13 has the problem as well, 12 is fine)

I will post logs later when I'm back at my pc.

Have you tried clearing your wine prefix just to make sure its not proton-ge conflicting with something?

I had a performance issue also and clearing the prefix solved it

And i said the same thing about proton-ge having no issues

Crashing a lot on the last update ( today ), played yesterday just fine, tried proton-ge, proton experimental , I can enter the menus just fine when I start a match it crashes instantly, even on training mode. Also clean the proton prefix a few times, seems I am stuck until it gets fixed

My current config:

OS: Arch Linux
KERNEL: 6.10.10-zen1-1-zen
CPU: AMD Ryzen 7 5800X3D 8-Core
GPU: AMD Radeon RX 6800 XT (radeonsi, navi21, LLVM 18.1.8, DRM 3.57, 6.10.10-zen1-1-zen)
GPU DRIVER: 4.6 Mesa 24.2.2-arch1.1
RAM: 32 GB

Edit: Fixed the issue! Package adwaita-icon-theme-legacy 46.2-2 was causing crashes, rolling back to 46.2-1 fixed.

Replying to https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2356930438

Jup, that fixed it. Thank you!

Does anyone else have a problem when entering the emote or voice line wheel on gnome? The mouse is not centered. It works fine in KDE.

Cachyos
6.11

I've recently encountered a new issue: after about 15 to 20 minutes a few games or map changes the game begins stuttering. The frame drops are severe enough to make the game unplayable. What's unique about this issue is that it's tied to input events from both mouse and keyboard (so it's not fixed by reducing the mouse polling rate for example).
The frame rate only drops when the mouse is moved or any button or key is pressed, it's otherwise perfectly stable and as high as it always has been on my setup. I've tried Proton 9.0-3, ProtonGE 9.18 and Proton Experimental, clearing the prefix and the shader cache.
The only solution right now is to restart the game, but the issue always comes up again.

System information
Log for Proton 9.0-3

In this thread, two other users have reported the same issue on different hardware, distributions and desktop environments, however they ran into it 20 days ago while I'm certain I didn't until today.

EDIT:

I also tried:

• Rolling back all system packages to a date I know the game worked
• Re-installing (not verifying) the game
• Running the game as new user, so a new Steam installation with default settings
• Disabled the new Steam Recording feature, Shader Pre-Caching, Steam Input and Steam Overlay

Finally, I added the Battle.net launcher as a Non-Steam game and ran the game from there with Proton 9.0-3 and it works fine. So whatever the issue is, it's specific to the Steam version of the client.

well guess it gives me a reason to play ow lol, ill see if i get the same issue

edit: so far no issues

arch, rx 6700, proton experimental,

It appears the issue is not specific to Overwatch 2, other games are affected too. It's being tracked here: ValveSoftware/steam-for-linux#11446. In the mean time, clearing LD_PRELOAD solves the issue.

Replying to https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2406105198

I need to confirm for other people, this turned out to be a problem with my desktop environment window manager, in this case, mutter from GNOME. And it was fixed in a very recent update. I updated all my system and it just works fine now. I send video proving it:
Working now!

So this was never a problem with proton, steam or overwatch. This was happening in other games too.

currently in the game it is not possible to reduce the screen resolution because the mouse position not coincides with the one used in the game, hopefully at some point it will be solved, it would be useful to be able to reduce a little the resolution of the game.

Question have you tried using a newer kernel instead?

I haven't tried it yet, but I followed advice from this thread https://github.com/ValveSoftware/steam-for-linux/issues/11446#issue-2647902036 in short to set LD_PRELOAD="" in the launch settings for each game then it should stop the issue of constant crashes and audio glitches that I mentioned (https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2526202899). It appears to be a problem with the new steam recording feature though I don't understand the specifics.

Edit: After the update on 10/12/2024 it seemed to come back and I have fully disabled steam game recording but kept the launch command

Note: This is currently just a workaround

Edit 2: This workaround appears to have stopped working, at least for myself and may no longer be reliable

Has anyone else encountered trouble with Overwatch 2 fullscreen since yesterday's Season 14 patch?

My symptoms:

• In the settings under Video -> Video -> GPU, I have my (one and only) GPU listed twice. Once as AMD RADEON RX 7900 XTX and again as AMD RADEON RX 7900 XTX (RADV NAVI31)*. It defaults to the former and changing to the latter doesn't "stick" upon game restart (supposed to apply on restart).
• The "Windowed" and "Borderless Windowed" display modes do not offer any resolution options.
• The "Fullscreen" display mode (my preferred), is meant to offer dropdown selectors for "Display", "Resolution", and "Aspect ratio", the first two of which are broken in some way:
  1. "Display" has only one option; "Best Match".
  2. "Resolution" has no options.
• When in fullscreen mode, my cursor is offset (visual vs. effective) in a way that feels like it's scaling a 1080p window to a 1440p display. Smaller disparity near the top-left, greater disparity near the bottom-right.

I don't think this is caused by Proton, since the issue presents the same regardless of whether I'm using Proton9-3, GE-Proton9-20, Proton Hotfix, Proton Experimental, or Proton8-5.

@Jafner Doesn't happen on my machine, my gpu is listed once, resolution list is populated, and display has a "display 1". Borderless and windowed indeed do not have a resolution list, but I think this is intended and was that way before this update.
The cursor offset can be manually reproduced by setting a lower than native resolution, so the game might be running at the wrong resolution (and then you are unable to change this as you get no options in the resolution dropdown).

Run the game with the following launch parameter:PROTON_LOG=1 %command%, navigate to the graphics settings and then close the game, this will create the file steam-2357570.log in your home folder. Upload this file, it might give us some more information about what's going wrong.

Note that despite my uncommon setup, I was not seeing any issues before yesterday's patch. Ran like native.

Computer Information:
Manufacturer: ASUSTeK COMPUTER INC.
Model: PRIME X470-PRO
Form Factor: Desktop
No Touch Input Detected
Processor Information:
CPU Vendor: AuthenticAMD
CPU Brand: AMD Ryzen 7 5700X 8-Core Processor
CPU Family: 0x19
CPU Model: 0x21
CPU Stepping: 0x2
CPU Type: 0x0
Speed: 4865 MHz
16 logical processors
8 physical processors
Hyper-threading: Supported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Supported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
AVX2: Supported
AVX512F: Unsupported
AVX512PF: Unsupported
AVX512ER: Unsupported
AVX512CD: Unsupported
AVX512VNNI: Unsupported
SHA: Supported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported
BMI1: Supported
BMI2: Supported
F16C: Supported
FMA: Supported
Operating System Version:
"NixOS 24.11 (Vicuna)" (64 bit)
Kernel Name: Linux
Kernel Version: 6.11.10
X Server Vendor: The X.Org Foundation
X Server Release: 12401004
X Window Manager: KWin
Steam Runtime Version: steam-runtime_0.20241024.105847
Client Information:
Version: 1733265492
Browser GPU Acceleration Status: Enabled
Browser Canvas: Enabled
Browser Canvas out-of-process rasterization: Enabled
Browser Direct Rendering Display Compositor: Disabled
Browser Compositing: Enabled
Browser Multiple Raster Threads: Enabled
Browser OpenGL: Enabled
Browser Rasterization: Enabled
Browser Raw Draw: Disabled
Browser Skia Graphite: Disabled
Browser Video Decode: Enabled
Browser Video Encode: Disabled
Browser Vulkan: Disabled
Browser WebGL: Enabled
Browser WebGL2: Enabled
Browser WebGPU: Disabled
Browser WebNN: Disabled
Video Card:
Driver: AMD AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 18.1.8, DRM 3.59, 6.11.10)
Driver Version: 4.6 (Compatibility Profile) Mesa 24.2.6
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 239 Hz
VendorID: 0x1002
DeviceID: 0x744c
Revision Not Detected
Number of Monitors: 3
Number of Logical Video Cards: 1
Primary Display Resolution: 2560 x 1440
Desktop Resolution: 7680 x 1440
Primary Display Size: 23.50" x 13.23" (26.97" diag), 59.7cm x 33.6cm (68.5cm diag)
Primary VRAM: 24576 MB
Sound card:
Audio device: ATI R6xx HDMI
Memory:
RAM: 32000 Mb
VR Hardware:
VR Headset: None detected
Miscellaneous:
UI Language: English
LANG: en_US.UTF-8
Total Hard Disk Space Available: 952340 MB
Largest Free Hard Disk Block: 488790 MB
Storage:
Number of SSDs: 2
SSD sizes: 0B,0B
Number of HDDs: 0
Number of removable drives: 0

steam-2357570.log

Searching for the string err in that file reveals several lines seemingly related to failing to get X display information.

51033.987:00e4:00e8:err:xrandr:xrandr14_get_adapters Failed to get adapters
51034.013:00e4:00e8:err:xrandr:xrandr14_get_adapters Failed to get adapters
51056.601:0148:014c:err:xrandr:xrandr14_get_adapters Failed to get adapters
51117.581:0148:014c:err:x11drv:xinerama_get_fullscreen_monitors Failed to get xinerama fullscreen monitor indices.
51117.581:0148:014c:err:x11drv:update_net_wm_fullscreen_monitors Failed to find xinerama monitors at (-32000,-32000)-(-31840,-31976)

Can you take logs while using proton experimental?

On Wed, Dec 11, 2024, 5:02 PM Jafner @.***> wrote:

Searching for the string err in that file reveals several lines seemingly
related to failing to get X display information.

51033.987:00e4:00e8:err:xrandr:xrandr14_get_adapters Failed to get adapters
51034.013:00e4:00e8:err:xrandr:xrandr14_get_adapters Failed to get adapters
51056.601:0148:014c:err:xrandr:xrandr14_get_adapters Failed to get adapters
51117.581:0148:014c:err:x11drv:xinerama_get_fullscreen_monitors Failed to get xinerama fullscreen monitor indices.
51117.581:0148:014c:err:x11drv:update_net_wm_fullscreen_monitors Failed to find xinerama monitors at (-32000,-32000)-(-31840,-31976)

—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2537168998,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQZQ4ECNTSXKUMDJ75F2QQT2FCR65AVCNFSM6AAAAAA3XXK5RSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZXGE3DQOJZHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

With Proton Experimental:

steam-2357570.log

it appears you have both radv and amdvlk installed and both seem to be
getting loaded, can you try uninstalling the latter and see if the issue
still happens?

On Wed, Dec 11, 2024, 5:44 PM Jafner @.***> wrote:

With Proton Experimental:

steam-2357570.log
https://github.com/user-attachments/files/18102733/steam-2357570.log

—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2537256093,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQZQ4EDYUTAJ67DE4KQIOHL2FCW5FAVCNFSM6AAAAAA3XXK5RSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZXGI2TMMBZGM
.
You are receiving this because you were mentioned.Message ID:
@.***>

Great intuition. I disabled amdvlk (in NixOS via hardware.amdgpu.amdvlk.enable = false;) and ran Overwatch.

It correctly detected only the radv GPU device (AMD RADEON RX 7900 XTX (RADV NAVI31)*) and all fullscreen options worked as expected. Back in business.

Edit: It's worth noting that simply prepending the AMD_VULKAN_ICD="RADV" variable to my game launch options did not prevent the game from seeing both devices.

Replying to https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2526278399

This issue I mentioned here has reappeared and I'm not sure why. I had my system monitor up and slowly saw the memory go up to max before starting to stutter and crash. The log file is given below:
steam-2357570.log

Will try the newest kernel and see if there is any difference

Using the newest kernel (6.12.4) the same think happens except now I have constant stuttering and when it maxes out memory it immediately crashes instead of slowly dying. I will stick with the lts kernel for now and see if I can find anything else. This is the log for it:
steam-2357570(stable+9-0-4).log

Edit: It appears to be a memory leak or possibly a race condition (poking into the dark here). I forgot I hadn't updated in a week and decided to do so and that seems to fix the issue, not sure exactly what was causing the issue.

So I cannot run this game without it crashing, most of the time those crashes freezing up my entire pc and I end up needing to hard power off my whole computer. It works for a couple games at least in debug mode, but I can't run it on steam normally without it crashing and I have to reboot. I can't even run PROTON_LOG=1 in launch options, the game won't start up. What commands do I need to run to get help troubleshooting? I'm still quite new to this, so I apologize for providing so little information up front. Just tell me what you need and I'll provide it. I'm on EndeavourOS.

Don't worry I am very new to all this as well (on that note if you think I am giving wrong advice correct me and I will fix my messages)

First always check that everything is updated, as that fixed my issue originally.

A proton log would be good, but if you can't even get that working, the issues may be somewhere else. Still I would try disable the screen recording:

To disable it globally

1. Open Steam
2. Go to the top right to Steam
3. Steam > Settings > Game Recording > Recording Off

Per game

1. Open Steam
2. Go to game
3. Settings > Game Recording > Background Recording > Disabled

Set Launch commands

1. Open Steam
2. Go to game
3. Settings > General > Launch Options > PROTON_LOG="1" LD_PRELOAD="" [any extras you may have]

Try launch the game and see if a log appears in ~ and send the .log file

If this fails, I would try run steam from the command line and see if anything pops up immediately, if nothing happens then try run a game and see what error appears and try store it in a file and send it here if there is an issue.

If there are still no problems then I would check dmesg after boot to see there aren't any issues with the kernel.

Otherwise I am not to sure and it may be up to someone more experienced to give better advice. Good luck though.

To give more information about your issue you should give information about
your setup: cpu, gpu, amount of ram, driver and kernel version as well as
proton version.
It can help to know how many times it has crashed and roughly how long it
takes for the game to crash.

Regarding PROTON_LOG=1, you have to put %command% after it, otherwise
it shouldn't be doing anything (it shouldn't be preventing the game from
launch either).

Also, if the game is taking down the whole system with it, I would expect
it to be logged. You can use the following command to get the kernel logs
for the previous boot: journalctl -k -b -1.

From my side the game still seems to work fine, rx 6600, mesa 24.3.1,
proton 9.0-4 and no crash after a few matches.

El jue, 19 dic 2024 a la(s) 3:03 p.m., matthoward123 (
@.***) escribió:

So I cannot run this game without it crashing, most of the time those
crashes freezing up my entire pc and I end up needing to hard power off my
whole computer. It works for a couple games at least in debug mode, but I
can't run it on steam normally without it crashing and I have to reboot. I
can't even run PROTON_LOG=1 in launch options, the game won't start up.
What commands do I need to run to get help troubleshooting? I'm still quite
new to this, so I apologize for providing so little information up front.
Just tell me what you need and I'll provide it. I'm on EndeavourOS.

—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2555573616,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQZQ4EEUKPBB7UUEWSU2S2D2GMKB5AVCNFSM6AAAAAA3XXK5RSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJVGU3TGNRRGY
.
You are receiving this because you were mentioned.Message ID:
@.***>

Output for uname -a

Linux ephraimsstick 6.12.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Mon, 09 Dec 2024 14:31:57 +0000 x86_64 GNU/Linux

Output for inxi -Ga

Graphics:
Device-1: Intel TigerLake-H GT1 [UHD Graphics] vendor: Micro-Star MSI
driver: i915 v: kernel alternate: xe arch: Gen-12.1 process: Intel 10nm
built: 2020-21 ports: active: HDMI-A-1,eDP-1 empty: none bus-ID: 00:02.0
chip-ID: 8086:9a68 class-ID: 0300
Device-2: NVIDIA GA107M [GeForce RTX 3050 Mobile] vendor: Micro-Star MSI
driver: nvidia v: 565.77 alternate: nouveau,nvidia_drm non-free: 550.xx+
status: current (as of 2024-09; EOL~2026-12-xx) arch: Ampere code: GAxxx
process: TSMC n7 (7nm) built: 2020-2023 pcie: gen: 4 speed: 16 GT/s
lanes: 8 link-max: lanes: 16 bus-ID: 01:00.0 chip-ID: 10de:25a2
class-ID: 0302
Device-3: Bison HD Webcam driver: uvcvideo type: USB rev: 2.0
speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 3-10:3 chip-ID: 5986:211b
class-ID: 0e02
Display: x11 server: X.Org v: 21.1.15 with: Xwayland v: 24.1.4
compositor: kwin_x11 driver: X: loaded: modesetting,nvidia dri: iris
gpu: i915 display-ID: :0 screens: 1
Screen-1: 0 s-res: 3840x1080 s-dpi: 75 s-size: 1301x366mm (51.22x14.41")
s-diag: 1352mm (53.21")
Monitor-1: HDMI-A-1 mapped: HDMI-1-1 pos: primary,right model: HP VH240a
serial: 6CM0340877 built: 2020 res: 1920x1080 hz: 60 dpi: 93 gamma: 1.2
size: 527x296mm (20.75x11.65") diag: 604mm (23.8") ratio: 16:9 modes:
max: 1920x1080 min: 720x400
Monitor-2: eDP-1 mapped: eDP-1-1 pos: left model: ChiMei InnoLux 0x1521
built: 2020 res: 1920x1080 hz: 144 dpi: 142 gamma: 1.2
size: 344x193mm (13.54x7.6") diag: 394mm (15.5") ratio: 16:9
modes: 1920x1080
API: EGL v: 1.5 hw: drv: nvidia platforms: device: 0 drv: nvidia gbm:
drv: nvidia surfaceless: drv: nvidia x11: drv: nvidia inactive: wayland
API: OpenGL v: 4.6.0 vendor: nvidia v: 565.77 glx-v: 1.4
direct-render: yes renderer: NVIDIA GeForce RTX 3050 Laptop GPU/PCIe/SSE2
memory: 3.91 GiB
API: Vulkan v: 1.4.303 layers: 5 device: 0 type: discrete-gpu name: NVIDIA
GeForce RTX 3050 Laptop GPU driver: N/A device-ID: 10de:25a2
surfaces: xcb,xlib

Here's my steam log
steam-2357570.log

Correct me if I'm wrong, but it seems like "Overwatch_loader.dll" is the thing that is the problem. Something missing or not working.

@matthoward123 first I would try to verify the game files, if it still crashes after that, try to change your launch parameters to this PROTON_DISABLE_NVAPI=1 %command%

@matthoward123 first I would try to verify the game files, if it still crashes after that, try to change your launch parameters to this PROTON_DISABLE_NVAPI=1 %command%

I verified my game files and used the launch parameter requested, and the game still crashed.

@matthoward123 first I would try to verify the game files, if it still crashes after that, try to change your launch parameters to this PROTON_DISABLE_NVAPI=1 %command%

I verified my game files and used the launch parameter requested, and the game still crashed.

Any other ideas? I have a console so it's not urgent necessarily, but playing on pc would be vastly preferred so I'm hoping to figure out what's going on.

UPDATE: I've had to hard reboot my system twice now when testing OW2, and when I ran journalctl -k -b -1 for both times I discovered that it crashed because:
Out of memory: Killed process 3827 (Overwatch.exe) total-vm:20556556kB, anon-rss:12037260kB, file-rss:166320kB, shmem-rss:139156kB, UID:1000 pgtables:26192kB oom_score_adj:200
I'm also seeing a lot of messages after that about "split lock detection"
I've tried finding other posts about this but it doesn't seem like an definitive solutions have been found that I can duplicate. Does anyone know how to deal with this memory issue?

that out of memory message is about your system, the game and what you're
running is locking up your system because you're using all of your ram, you
might have to tweak the game's settings to prevent it. The split lock
message should not be coming from overwatch, the only game off the top of
my head that is known to trigger it is god of war, but that would only have
an effect while god of war is running

On Mon, Dec 23, 2024, 7:21 PM matthoward123 @.***>
wrote:

UPDATE: I've had to hard reboot my system twice now when testing OW2, and
when I ran journalctl -k -b -1 for both times I discovered that it crashed
because:
Out of memory: Killed process 3827 (Overwatch.exe) total-vm:20556556kB,
anon-rss:12037260kB, file-rss:166320kB, shmem-rss:139156kB, UID:1000
pgtables:26192kB oom_score_adj:200
I'm also seeing a lot of messages after that about "split lock detection"
I've tried finding other posts about this but it doesn't seem like an
definitive solutions have been found that I can duplicate. Does anyone know
how to deal with this memory issue?

—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2560421598,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQZQ4EDIV6CMKMHQJYL6AKL2HCLG5AVCNFSM6AAAAAA3XXK5RSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRQGQZDCNJZHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Replying to https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2563118711

Do you mean tweaking settings in-game? I am unable to do that because the game will crash just when I'm looking at in-game video settings for only seconds. I don't understand how the game is using up so much ram when I'm not even playing, how do I fix this out of game, since I can't do it in-game?

I still have this "fixed, and fixed multiple times" out of focus thingy, somehow. As a last resort, I tried Proton-GE and I have the very same problem with it too. The game is freshly installed, so the prefix.

Note: I tried different mouse grab / mouse capture options, nothings changed.

OS: Arch Linux
Desktop environment: GNOME 47
CPU: Ryzen 5 3600
GPU: RTX 3060 12GB
NVIDIA driver version: 565.77

To the people who don't know what it is; the game doesn't capture the cursor and the game window is acts like it is transparent(not visually). If there is a window behind the game window then that window will get to the front, therefore gets the window focus. If there is no window behind the game window, nothing happens but you still don't have the focus inside of your game window. So I can literally right-click on my desktop while seeing the game window. Keyboard works.

Last time it happened to me, it was because of a gnome update. Did you
check the issue tracker on gnome-shell or mutter?

El vie, 17 de ene de 2025, 7:52 a. m., Dhizaes @.***>
escribió:

I still have this "fixed, and fixed multiple times" out of focus thingy,
somehow. As a last resort, I tried Proton-GE and I have the very same
problem with it too. The game is freshly installed, so the prefix.

Note: I tried different mouse grab / mouse capture options, nothings
changed.

OS: Arch Linux
Desktop environment: GNOME 47
CPU: Ryzen 5 3600
GPU: RTX 3060 12GB
NVIDIA driver version: 565.77

To the people who don't know what it is; the game doesn't capture the
cursor and the game window is acts like it is transparent(not visually). If
there is a window behind the game window then that window will get to the
front, therefore gets the window focus. If there is no window behind the
game window, nothing happens but you still don't have the focus inside of
your game window. So I can literally right-click on my desktop while seeing
the game window. Keyboard works.

—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2598658302,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJE3UIAUHHE3LAUPIMLJYIT2LERLBAVCNFSM6AAAAAA3XXK5RSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJYGY2TQMZQGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

Last time it happened to me, it was because of a gnome update. Did you
check the issue tracker on gnome-shell or mutter?

El vie, 17 de ene de 2025, 7:52 a. m., Dhizaes @.***>
escribió:
…

Wasn't it for 45 and 46, if I remember it correctly? After a minor update of 46, I believe, it should've been fixed. It also should've been fixed in Proton, and it should've been "extra" fixed in Proton-GE which had a special version for it back then. I remember I played it before 47 came out, without any issues, when one of this fixes applied to me too (I don't remember if it was the Battle.net version of it, in Bottles app, or Steam version) after a year of struggle, which is the exact year of when Overwatch 2 released. Somehow, after I go back and forth between Windows and Linux multiple times, this bug came back to me. I don't know which issues you are referring but I'm going to search for this so called "fixed" issue in issue tracker. It shouldn't take this much effort to broke something fixed after a year of work.

Play game, after certain amount of time, frame rate drops drastically. Happens every time, easily reproducible.

Very interesting, I commented a few days ago about experiencing the exact same thing in Marvel Rivals, but didn't get any response yet: https://github.com/ValveSoftware/Proton/issues/8300#issuecomment-2646346805

So this is a general issue with Proton in combination with some hardware/software, I thought this was just a Marvel Rivals thing.

Edit: The only things I see our hardware/software setups have in common is a pretty recent NVIDIA GPU and a pretty recent kernel version, it might have to do with that

@Latecloser @julius-boettger You can try adding LD_PRELOAD="" to your launch parameters in steam, e.g.:

LD_PRELOAD="" %command%

This will break the steam overlay though.
Seems to be a widespread issue. I've also read that enabling/disabling the overlay in steam fixes it for some people.

You can try adding LD_PRELOAD="" to your launch parameters in steam

Thank you, that works for me!

The lag timebomb is a know issue acknowledged by Valve. Its related to their rollout of the steam recording feature. See here : https://github.com/ValveSoftware/steam-for-linux/issues/11446

If you want manguhud or gamemode : https://github.com/doitsujin/dxvk/issues/4436#issuecomment-2466646597

@Latecloser @julius-boettger You can try adding LD_PRELOAD="" to your launch parameters in steam, e.g.:

LD_PRELOAD="" %command%

This will break the steam overlay though. Seems to be a widespread issue. I've also read that enabling/disabling the overlay in steam fixes it for some people.

Tested this workaround and it works for me! Although, I don't understand why. I don't know what this launch parameter does. And I already had the steam overlay disabled in my global settings. Also checked per game, wasn't enabled.

I tried both Overwatch 2 and Path of Exile 2, and neither exhibited the problem I was experiencing while using this workaround. I guess I have to add it to every game I play.

Thanks for the suggestion.

Been experimenting with this for a day or so and am at the point that I can play my fav high aim heroes like soj, ashe and ana on linux mint no problem. Biggest thing that helped it feel right was turning on "nvidia reflex", just enabled not boost.

BUT after a while of playing all of a sudden it starts stammering and chugging (identical to what I saw in kovaaks/aim trainer but not in other non-FPS games).

steam-2357570.log

Replying to https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2727107045

You probably need to add the LD_PRELOAD="" fix (add LD_PRELOAD="" to the beginning of your launch params).
Sounds like this problem: https://github.com/ValveSoftware/steam-for-linux/issues/11446

I have to add this to every game at the moment or I get the stuttering after 25 minutes of gameplay.

I've been experiencing large amounts of shader compilation during gameplay. It will happen randomly/when models are being loaded in. Usually happens when starting the game up anew, loading new characters in, loading new maps in. After having everything load in and compile shaders, the game runs flawlessly. This is including the fact that it "compiles shaders" before boot up, according to Steam.

My current mess of parameters is: DXVK_ASYNC=1 __GL_SHADER_DISK_CACHE=1 __GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1 __GL_SHADER_DISK_CACHE_SIZE=1000000000 LD_PRELOAD="" PROTON_USE_XALIA=0 LFX=1 DXVK_HUD=compiler __GL_SHADER_DISK_CACHE_PATH=/home/user/.steam/debian-installation/steamapps/shadercache/2357570 gamemoderun %command%

Also using Proton GE, it supposedly solved this issue (it did not).
Linux 6.11.0-19, Ubuntu 24.04, Ryzen 9 5950X, RX 7800XT

Replying to https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2737958713

Considering those of us without those parameters are not having this problem, you should probably try removing them.

Considering those of us without those parameters are not having this problem, you should probably try removing them.

I added the parameters specifically because I had the shader compilation problems, removing them won't solve the issue. I've had it on NVIDIA and AMD cards. Maybe it's a distro issue?

I've noticed similar stuff on a up to date Tumbleweed KDE with 570 nvidia drivers and proton experimental. I only use the LD_PRELOAD="" and not this wall of text as parameters.

Basically download the 16gb shader precache, let steam cook the shaders in the background, launch the game and the first 2-3 matches still stutter while loading new textures. Even with wild pop in's from stuff like my weapon models and stuff.

After those first few matches its fine for hours until i restart the game.

It reminds me of that DXVK bug we had like 2 years ago where it would precache invalid shaders and would override them everytime no matter what.

Found the bug report : https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/GE-Proton7-47

The current launch-option setup I use is LD_PRELOAD="" DXVK_HUD=compiler gamemoderun %command%, (DXVK_HUD=compiler is for personal preference) based on the advice I got. At first this did nothing to alleviate the issue, but after removing the~/.steam/debian-installation/shadercache/2357570/ folder, it never tried compiling shaders again (in-game or on bootup) and it now runs flawlessly. Maybe because of leftover NVIDIA driver compatability from before I switched GPUs?
Running GE-Proton9-25, Ubuntu 24.04, RX7800XT, Ryzen 5950X

Maybe because of leftover NVIDIA driver compatability from before I switched GPUs?

I mean maybe .. if .. looking at your old command line .. you changed some other parameters of your system like this, then .. maybe. But generally no it should not.

Your new command line looks good tho. Could replace the compiler stuff with mangohud and default gamemode does nothing anymore for most games, so could remove that if you run the default config.

Glad its working for you now tho!

In order to isolate issues with DXVK/shader cache you might try the DirectX 12 backend in Overwatch. This will run on VKD3D but I'm not sure if the result shader compile pipeline is different.

In order to isolate issues with DXVK/shader cache you might try the DirectX 12 backend in Overwatch. This will run on VKD3D but I'm not sure if the result shader compile pipeline is different.

How can I enable DirectX 12 in Overwatch? I only have DirectX 11 option when I run game inside Proton
Running Overwatch from Windows (via dualboot) gives me DirectX 12 Beta option, but on Linux I have only DirectX 11 in game's settings

Is there any necessary command line stuff?

How can I enable DirectX 12 in Overwatch? I only have DirectX 11 option when I run game inside Proton Running Overwatch from Windows (via dualboot) gives me DirectX 12 Beta option, but on Linux I have only DirectX 11 in game's settings

Is there any necessary command line stuff?

The option is definitely present on the latest version, using GE and Ubuntu 24.04. I tried it, but the game wouldn't start up again after selecting it so I avoid using it. Maybe use a specific Proton or Linux version, it could be detecting that something in your system isn't DX12 compatible.

In order to isolate issues with DXVK/shader cache you might try the DirectX 12 backend in Overwatch. This will run on VKD3D but I'm not sure if the result shader compile pipeline is different.

How can I enable DirectX 12 in Overwatch? I only have DirectX 11 option when I run game inside Proton Running Overwatch from Windows (via dualboot) gives me DirectX 12 Beta option, but on Linux I have only DirectX 11 in game's settings

Is there any necessary command line stuff?

I don't know if there is a parameter to force it but in the blog it says it is not DirectX 12, it is DirectX 12 Ultimate, which needs a compatible GPU. If your GPU doesn't compatible with that you probably can't see it. I have RTX 3060, I can see the option and it works without any problem. Maybe you can try to set your VKD3D level to 12.2, even I don't think it will help in this situation.

Replying to https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2764549257

yep, only rtx 20 series, rdna2, arc a series or above support ultimate, my mate on windows who has a 1660ti doesn't have the dx12 option but my rx 6700 and rtx 2060 has the option to use it :P

Is anyone else here experiencing issues with the game freezing after last season started?

Like a year ago (https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2016565859) , I'm facing game freezing on Proton-Experimental and Proton-9. I'm on Nvidia with 570.133.07 driver

Here's my proton logs from start of the game to game freeze. I closed the game after 2-3 minutes of freeze through Steam "Stop" button in library

steam-2357570.log

I have the same freezing problem on two new(-ish) full AMD systems (7900 GRE + 7800x3D, and a Notebook with 7745HS). I now restart the game after 3 games, as a precaution. The freeze happens after playing for 1-2 hours and it sometimes takes the full system(KDE Plasma) down, becoming fully unresponsive and I need to restart my system. If it doesn't take the whole system down then it closes the game after ~20 seconds and also causes all other applications I had running (Firefox, Steam, Discord) to crash. Restarting the game afterwards works, but it has to reload all shaders while playing the game, meaning for 10-20 seconds you won't see much ingame.

I am on Arch/CachyOS KDE Plasma + Wayland always with newest drivers.

OpenGL renderer string: AMD Radeon Graphics (radeonsi, phoenix, LLVM 19.1.7, DRM 3.61, 6.14.2-2-cachyos)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 25.0.3-cachyos1.2

Replying to https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2812152540

Try Proton 8, I had no problem since I switched to it. I guess the freezing problem starts from Proton 9 version

I have the same freezing issue too, for about 1-2 months, usually when loading into match, can randomly happen after 1 game or after 10 games or not happen at all.
1 times game unfreezed and recovered, but often it's crashing all my system.
I am on Arch + Wayland (tested Sway and Hyprland)
Kernel: Linux 6.14.3-zen1-1-zen (tested 6.13 too)
CPU: AMD Ryzen 5 5600G
GPU: AMD Radeon RX 6700 XT
mesa: 25.0.4
Proton: Proton-GE 9_27
journalctl errors:

Apr 22 16:10:46 castor kernel: amdgpu 0000:03:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:3 pasid:32797)
Apr 22 16:10:46 castor kernel: amdgpu 0000:03:00.0: amdgpu:  in process Overwatch.exe pid 44184 thread dxvk-submit pid 442>
Apr 22 16:10:46 castor kernel: amdgpu 0000:03:00.0: amdgpu:   in page starting at address 0x00000001007a1000 from client 0>
Apr 22 16:10:46 castor kernel: amdgpu 0000:03:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00301431
Apr 22 16:10:46 castor kernel: amdgpu 0000:03:00.0: amdgpu:          Faulty UTCL2 client ID: SQC (data) (0xa)
Apr 22 16:10:46 castor kernel: amdgpu 0000:03:00.0: amdgpu:          MORE_FAULTS: 0x1
Apr 22 16:10:46 castor kernel: amdgpu 0000:03:00.0: amdgpu:          WALKER_ERROR: 0x0
Apr 22 16:10:46 castor kernel: amdgpu 0000:03:00.0: amdgpu:          PERMISSION_FAULTS: 0x3
Apr 22 16:10:46 castor kernel: amdgpu 0000:03:00.0: amdgpu:          MAPPING_ERROR: 0x0
Apr 22 16:10:46 castor kernel: amdgpu 0000:03:00.0: amdgpu:          RW: 0x0
Apr 22 16:10:46 castor kernel: amdgpu 0000:03:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:3 pasid:32797)
Apr 22 16:10:46 castor kernel: amdgpu 0000:03:00.0: amdgpu:  in process Overwatch.exe pid 44184 thread dxvk-submit pid 442>
Apr 22 16:10:46 castor kernel: amdgpu 0000:03:00.0: amdgpu:   in page starting at address 0x00000001007a1000 from client 0>
Apr 22 16:10:51 castor kernel: retire_capture_urb: 15 callbacks suppressed
Apr 22 16:10:56 castor kernel: amdgpu 0000:03:00.0: amdgpu: Dumping IP State
Apr 22 16:10:56 castor kernel: amdgpu 0000:03:00.0: amdgpu: Dumping IP State Completed
Apr 22 16:10:56 castor kernel: amdgpu 0000:03:00.0: amdgpu: ring gfx_0.0.0 timeout, signaled seq=9870196, emitted seq=9870>
Apr 22 16:10:56 castor kernel: amdgpu 0000:03:00.0: amdgpu: Process information: process Overwatch.exe pid 44184 thread dx>
Apr 22 16:10:56 castor kernel: amdgpu 0000:03:00.0: amdgpu: Starting gfx_0.0.0 ring reset
Apr 22 16:10:56 castor kernel: amdgpu 0000:03:00.0: amdgpu: Ring gfx_0.0.0 reset failure

Will try Proton-8, will update after 1-2 days, if it will work.

P.S.: No crashes for 2 days, ofc it may be pure luck
P.P.S.: No crashes for a week, so Proton-8 fixes the problem. Hope to see a solution to this regression in Proton-10, really want to play natively in wayland :(

I managed to get 2 hangs with my rx 6600, on linux 6.14.2, mesa 25.0.3 and proton 9.0-4.
The first one was while loading into a match, this was the second match of the session, and it only affected the game, there was no issue with amdgpu. After that it took about 15 games across two sessions to get another hang, this one was mid-game and it caused a gpu hang

I haven't yet seen this issue happen with proton experimental bleeding edge, but considering the second one took 15 games, it might be down to luck, has anyone tried this version and gotten it to hang?

I confirm I also have the same issue of Overwatch randomly freezing since last season (I'm on Proton Experimental). I initially tough it was my system or Nvidia driver but I stumble into this thread: https://www.reddit.com/r/linux_gaming/comments/1k7e6bj/overwatch_randomly_crashing_fix/ where AMD users are also affected. And then I found this one https://www.reddit.com/r/SteamDeck/comments/1k655np/overwatch_2_season_16_stadium_crashing_aid_for/ where Steam Deck users are also affected and which talk about this thread also: https://steamcommunity.com/app/2357570/discussions/0/598523502186737670/ were multiple Steam Deck users also report the issue. And then I came here obviously. I think there is enough evidence that this is a widespread issue, even if the freezes don't happen very often.

I guess I'll try Proton 8 to see if the issue still happens but that means no Nvidia Reflex (I'm off for a week, so I might only update about this in two weeks).

I guess I'll try Proton 8

You can also try new Proton 10 beta. Yesterday I played for 6 hours without any issues, no freezes, stutters or anything. Feels great. It will be even better with wayland driver enabled and NTSync support, but we have to wait for it a bit longer

@E-D-W-I-N We also cannot reproduce any freeze/stutter on 10.0... fingers crossed this is fixed! @Nyamiou @korsilyn @Cantfirmed Please let me know if you still see any freeze/stutter on Proton 10?

No blizzard games work anymore on Tumbleweed 20250501 KDE Nvidia 570.144 with current Proton Experimental.

• WoW ( added via other games on steam )
• OW2
• Hearthstone

Proton experimental added wine mono 10 on top of proton 10, which broke all of your shit.

The games work fine on the proton 10 beta and on proton 9 on steam. @alasky17

@alasky17 i am currently on proton bleeding-edge (10.0-200), no crashes so far. Looking at patchnotes, this regression also fixed in proton 9.0-rc2, but I'm playing through battlenet, which now works only on Proton 10 (fix in Proton 10-1 beta) so I can't confirm.

I'm also trying Proton 10 (10c) for the last two days and no crashes so far.

@alasky17 I have tried it out, and indeed the crashing issue seems to be fixed. Sadly now my fps seems to be locked to <70 fps when I have had 165+ FPS with Proton GE 8.32 (with normal Proton 8.x I couldn't even launch it). I have tried both Proton 10 Beta branch and Proton Experimental Bleeding Edge. With Bleeding Edge I get around 5 FPS more.

@E-D-W-I-N We also cannot reproduce any freeze/stutter on 10.0... fingers crossed this is fixed! @Nyamiou @korsilyn @Cantfirmed Please let me know if you still see any freeze/stutter on Proton 10?

I personnally, and some others still do on THE FINALS! Seems related to 2 instances of EAC launching instead of 1.
https://github.com/ValveSoftware/Proton/issues/7317#issuecomment-2847975547

@alasky17 I have tried it out, and indeed the crashing issue seems to be fixed. Sadly now my fps seems to be locked to <70 fps when I have had 165+ FPS with Proton GE 8.32 (with normal Proton 8.x I couldn't even launch it). I have tried both Proton 10 Beta branch and Proton Experimental Bleeding Edge. With Bleeding Edge I get around 5 FPS more.

Read through this and see if it fixes the problem

https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2080418541

https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2080377079

I can only get the game to launch once every 20 attempts. The Overwatch.exe process seems to die before I even get to see the window spawning.

System information:

• OS: EndeavourOS
• Kernel: 6.14.4-arch1-2
• DE: KDE Plasma
• WM: KWin (X11)
• CPU: Ryzen 7 9800X3D
• GPU: AMD Radeon RX 9070 XT
• Mesa version: 25.0.4-1
• Proton version: from 8.0-5 to experimental, including Proton-GE

Here's my launch parameters:

DXVK_FILTER_DEVICE_NAME="RADV GFX1201" DXVK_LOG_PATH="/home/claymore/.logs/dxvk" DXVK_LOG_LEVEL="warn" DXVK_HUD="pipelines" PROTON_LOG="1" LD_PRELOAD="" %command%

DXVK log is empty, so I'll attach the one from proton

steam-2357570.log

@Cantfirmed i had to recreate prefix to fix fps issue, try this
Also, if you want to backup graphics settings, be sure to copy PFX_DIR/drive_c/Users/steamuser/Documents/Overwatch/

Replying to https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2849380843

Overwatch 2 doesn't use EAC.

Replying to [#7033 (comment)](https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-2849380843)

Overwatch 2 doesn't use EAC.

Fair enough then, but just answering this wasn't taking so much more time, and doesn't bring any toxic vibes, I just take it and glad to be informed. Thumbing down just feels childish and doesn't carry any worthy value...
Thanks for your information.
Others are still dumbasses, I didn't start they deserve this. Better to say they might be not, yet they behaved as. Sorry for saying it wrongly.

Have a great day @Dhizaes

@korsilyn @pollux78 after deleting the prefix I got the same performance on my PC as with Proton 8. Stadium mode still has some lag spikes but afaik that also happens on Windows. I don't really know why it seems to be worse on my notebook with onboard graphics, may be a bad driver update or something else on my side.

But I am glad to see that I don't need to use an older Proton version anymore to play Overwatch.

My game runs fine with GE-10-4 as long as I use LD_PRELOAD="" to stop the huge lag spike after a few games. However when I try using PROTON_ENABLE_WAYLAND=1 because I want to get HDR working again without Gamescope, the game completely freezes after a few seconds. Has anyone been able to get this working? I know I'll need PROTON_ENABLE_HDR=1 for actual HDR but I figured I'd limit the variables until just using Wayland over X11 works.

steam.sh[25780]: Running Steam on bazzite 42 64-bit
steam.sh[25780]: STEAM_RUNTIME is enabled automatically
setup.sh[25829]: Steam runtime environment up-to-date!
steam.sh[25780]: Log already open
steam.sh[25780]: Using supervisor /var/home/user/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-supervisor
steam.sh[25780]: Steam client's requirements are satisfied
CProcessEnvironmentManager is ready, 6 preallocated environment variables.
[2025-06-02 10:29:48] Startup - updater built May 19 2025 19:50:58
[2025-06-02 10:29:48] Startup - Steam Client launched with: '/var/home/user/.local/share/Steam/ubuntu12_32/steam' '-srt-logger-opened'
[2025-06-02 10:29:48] Opted in to client beta 'publicbeta' via beta file
You are in the 'publicbeta' client beta.
Looks like steam didn't shutdown cleanly, scheduling immediate update check
CProcessEnvironmentManager is ready, 6 preallocated environment variables.
[2025-06-02 10:29:48] Loading cached metrics from disk (/var/home/user/.local/share/Steam/package/steam_client_metrics.bin)
[2025-06-02 10:29:48] Using the following download hosts for Public, Realm steamglobal
[2025-06-02 10:29:48] 1. https://client-update.fastly.steamstatic.com, /, Realm 'steamglobal', weight was 900, source = 'update_hosts_cached.vdf'
[2025-06-02 10:29:48] 2. https://client-update.akamai.steamstatic.com, /, Realm 'steamglobal', weight was 100, source = 'update_hosts_cached.vdf'
[2025-06-02 10:29:48] 3. https://client-update.steamstatic.com, /, Realm 'steamglobal', weight was 1, source = 'baked in'
06/02 10:29:48 minidumps folder is set to /tmp/dumps
[2025-06-02 10:29:48] Checking for update on startup
[2025-06-02 10:29:48] Checking for available updates...
[2025-06-02 10:29:48] Downloading manifest: https://client-update.fastly.steamstatic.com/steam_client_publicbeta_ubuntu12
[2025-06-02 10:29:48] Manifest download: send request
[2025-06-02 10:29:48] Process started with command-line: '/var/home/user/.local/share/Steam/ubuntu12_32/steam' '-child-update-ui' '-child-update-ui-socket' '8' '-srt-logger-opened'
06/02 10:29:48 minidumps folder is set to /tmp/dumps
[2025-06-02 10:29:48] Using update UI: console
06/02 10:29:48 Init: Installing breakpad exception handler for appid(steam)/version(0)/tid(25879)
[2025-06-02 10:29:48] Create window
[2025-06-02 10:29:48] Set percent complete: 0
[2025-06-02 10:29:48] Set status message: Checking for available updates...
[  0%] Checking for available updates...
[2025-06-02 10:29:48] Set percent complete: -1
[2025-06-02 10:29:49] Manifest download: waiting for download to finish
[2025-06-02 10:29:49] Manifest download: finished
[2025-06-02 10:29:49] Download skipped: /steam_client_publicbeta_ubuntu12 version 1747701111, installed version 1747701111, existing pending version 0
[2025-06-02 10:29:49] Nothing to do
[2025-06-02 10:29:49] Verifying installation...
[2025-06-02 10:29:49] Verifying all executable checksums
[2025-06-02 10:29:49] Set percent complete: -1
[2025-06-02 10:29:49] Set status message: Verifying installation...
[----] Verifying installation...
[2025-06-02 10:29:50] Verification complete
UpdateUI: skip show logo
[2025-06-02 10:29:50] Destroy window

Steam logging initialized: directory: /var/home/user/.local/share/Steam/logs

[2025-06-02 10:29:50] ProcessNextMessage: socket disconnected
[2025-06-02 10:29:50] No more messages are expected - exiting
XRRGetOutputInfo Workaround: initialized with override: 0 real: 0xf60bbf90
XRRGetCrtcInfo Workaround: initialized with override: 0 real: 0xf60ba670
06/02 10:29:51 minidumps folder is set to /tmp/dumps
06/02 10:29:51 Init: Installing breakpad exception handler for appid(steamsysinfo)/version(1747701111)/tid(25887)
Running query: 1 - GpuTopology
Response: gpu_topology {
  gpus {
    id: 1
    name: "NVIDIA GeForce RTX 3060 Ti"
    vram_size_bytes: 8589934592
    driver_id: k_EGpuDriverId_NvidiaProprietary
    driver_version_major: 570
    driver_version_minor: 153
    driver_version_patch: 2
  }
  gpus {
    id: 2
    name: "llvmpipe (LLVM 20.1.3, 256 bits)"
    vram_size_bytes: 3221225472
    driver_id: k_EGpuDriverId_MesaLLVMPipe
    driver_version_major: 25
    driver_version_minor: 1
    driver_version_patch: 0
  }
  default_gpu_id: 1
}

Exit code: 0
Saving response to: /tmp/steamMPPDld - 104 bytes
steamwebhelper.sh[25890]: Using supervisor /home/user/.steam/root/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-supervisor
steamwebhelper.sh[25890]: Starting steamwebhelper under bootstrap steamrt steam runtime via: /var/home/user/.local/share/Steam/steamrt64/steam-runtime-steamrt/_v2-entry-point
steamwebhelper.sh[25890]: Using CEF sandbox \(try with -no-cef-sandbox if this fails\)
steamwebhelper.sh[25890]: Starting steamwebhelper with steamrt steam runtime at /var/home/user/.local/share/Steam/steamrt64/steam-runtime-steamrt/_v2-entry-point
Steam Runtime Launch Service: starting steam-runtime-launcher-service
Steam Runtime Launch Service: steam-runtime-launcher-service is running pid 25959
bus_name=com.steampowered.PressureVessel.LaunchAlongsideSteam
exec ./steamwebhelper -nocrashdialog -lang=en_US -cachedir=/var/home/user/.local/share/Steam/config/htmlcache -steampid=25878 -buildid=1747701111 -steamid=0 -logdir=/var/home/user/.local/share/Steam/logs -uimode=7 -startcount=0 -steamuniverse=Public -realm=Global -clientui=/var/home/user/.local/share/Steam/clientui -steampath=/var/home/user/.local/share/Steam/ubuntu12_32/steam -launcher=0 -use_xcomposite_workaround -no-restart-on-ui-mode-change --valve-initial-threadpool-size=4 --valve-enable-site-isolation --enable-smooth-scrolling --password-store=basic --ignore-gpu-blocklist --log-file=/var/home/user/.local/share/Steam/logs/cef_log.txt --disable-quick-menu --enable-features=PlatformHEVCDecoderSupport --disable-features=SpareRendererForSitePerProcess,DcheckIsFatal,BlockPromptsIfIgnoredOften,ValveFFmpegAllowLowDelayHEVC
/usr/share/themes/Adwaita/gtk-2.0/main.rc:733: error: unexpected identifier 'direction', expected character '}'
/usr/share/themes/Adwaita/gtk-2.0/hacks.rc:28: error: invalid string constant "normal_entry", expected valid string constant
Desktop state changed: desktop: { pos:    0,   0 size: 3440,1440 } primary: { pos:    0,   0 size: 3440,1440 }
Caching cursor image for , size 24x24, serial 49, cache size = 0
ProtonFixes[26423] WARN: [CONFIG]: Parent directory "/home/user/.config/protonfixes" does not exist. Abort.
ProtonFixes[26423] WARN: Skipping fix execution. We are probably running an unit test.
fsync: up and running.
Fossilize INFO: Overriding serialization path: "/var/home/user/.local/share/Steam/shader_cache_temp_dir_d3d11_64/fozpipelinesv6/steamapprun_pipeline_cache".
ProtonFixes[26720] WARN: [CONFIG]: Parent directory "/home/user/.config/protonfixes" does not exist. Abort.
ProtonFixes[26720] WARN: Skipping fix execution. We are probably running an unit test.
fsync: up and running.
Fossilize INFO: Overriding serialization path: "/var/home/user/.local/share/Steam/shader_cache_temp_dir_d3d12_64/fozpipelinesv6/steamapprun_pipeline_cache".
reaping pid: 25879 -- steam
chdir "/var/home/user/.local/share/Steam/steamapps/common/Overwatch"
ERROR: ld.so: object '/var/home/user/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
Game Recording - would start recording game 2357570, but recording for this game is disabled
Adding process 26882 for gameID 2357570
WARNING: discarding _NET_WM_PID 3 as invalid for X11 window - use specialized XCB_X11_TO_PID function!
ProtonFixes[27042] WARN: [CONFIG]: Parent directory "/home/user/.config/protonfixes" does not exist. Abort.
ProtonFixes[27042] INFO: Running protonfixes on "GE-Proton10-4", build at 2025-06-02 02:00:53+00:00.
ProtonFixes[27042] INFO: Running checks
ProtonFixes[27042] INFO: All checks successful
ProtonFixes[27042] INFO: Using global defaults for "Overwatch® 2" (2357570)
ProtonFixes[27042] INFO: No global protonfix found for "Overwatch® 2" (2357570)
[2025-06-02 10:31:51] Background update loop checking for update. . .
[2025-06-02 10:31:51] Checking for available updates...
[2025-06-02 10:31:51] Downloading manifest: https://client-update.fastly.steamstatic.com/steam_client_publicbeta_ubuntu12
[2025-06-02 10:31:51] Manifest download: send request
[2025-06-02 10:31:52] Manifest download: waiting for download to finish
[2025-06-02 10:31:52] Manifest download: finished
[2025-06-02 10:31:52] Download skipped by HTTP 304 Not Modified
[2025-06-02 10:31:52] Nothing to do
Game Recording - game stopped [gameid=2357570]
Removing process 26882 for gameID 2357570

Nothing glaringly looks wrong but I am not very familiar with these logs. I do see it say ProtonFixes[27042] WARN: [CONFIG]: Parent directory "/home/user/.config/protonfixes" does not exist. Abort., is this an issue?

PROTON_ENABLE_WAYLAND=1 works great for me here and has since GE-Proton 10 came out. I didn't have raw mouse for a while, but GE fixed that in a later version.

I have Overwatch 2 starting in the resolution of my other monitor, but that seems to be proton issue itself, otherwise no crashes or other issues on Tumbleweed KDE with 570 open driver.

Has anyone been able to get HDR working on overwatch? I am running it with the launch options ENABLE_HDR_WSI=1 PROTON_ENABLE_WAYLAND=1 PROTON_ENABLE_HDR=1 gamemoderun %command% and proton-ge-10-3 on hyprland with the hdr vulkan layer installed. This setup works flawlessly for path of exile 2, but for overwatch 2 after I enable HDR ingame and restart, the game begins crashing on launch every time until I remove PROTON_ENABLE_HDR from the launch options. I see these relevent looking lines in my journal when the crash happens:

Jun 08 17:18:57 tile steam[2979]: [HDR Layer] Created HDR surface
Jun 08 17:18:57 tile steam[2979]: [HDR Layer] Enabling format: 64 colorspace: 1000104008
Jun 08 17:18:57 tile steam[2979]: [HDR Layer] Enabling format: 58 colorspace: 1000104008
Jun 08 17:18:57 tile steam[2979]: [HDR Layer] Enabling format: 97 colorspace: 1000104002
Jun 08 17:18:57 tile steam[2979]: [HDR Layer] Enabling format: 97 colorspace: 1000104005
Jun 08 17:18:57 tile steam[2979]: [HDR Layer] Enabling format: 64 colorspace: 1000104008
Jun 08 17:18:57 tile steam[2979]: [HDR Layer] Enabling format: 58 colorspace: 1000104008
Jun 08 17:18:57 tile steam[2979]: [HDR Layer] Enabling format: 97 colorspace: 1000104002
Jun 08 17:18:57 tile steam[2979]: [HDR Layer] Enabling format: 97 colorspace: 1000104005
Jun 08 17:18:57 tile steam[2979]: [HDR Layer] Enabling format: 64 colorspace: 1000104008
Jun 08 17:18:57 tile steam[2979]: [HDR Layer] Enabling format: 58 colorspace: 1000104008
Jun 08 17:18:57 tile steam[2979]: [HDR Layer] Enabling format: 97 colorspace: 1000104002
Jun 08 17:18:57 tile steam[2979]: [HDR Layer] Enabling format: 97 colorspace: 1000104005
Jun 08 17:18:57 tile steam[2979]: [HDR Layer] Enabling format: 64 colorspace: 1000104008
Jun 08 17:18:57 tile steam[2979]: [HDR Layer] Enabling format: 58 colorspace: 1000104008
Jun 08 17:18:57 tile steam[2979]: [HDR Layer] Enabling format: 97 colorspace: 1000104002
Jun 08 17:18:57 tile steam[2979]: [HDR Layer] Enabling format: 97 colorspace: 1000104005
Jun 08 17:18:58 tile steam[2979]: [HDR Layer] Enabling format: 64 colorspace: 1000104008
Jun 08 17:18:58 tile steam[2979]: [HDR Layer] Enabling format: 58 colorspace: 1000104008
Jun 08 17:18:58 tile steam[2979]: [HDR Layer] Enabling format: 97 colorspace: 1000104002
Jun 08 17:18:58 tile steam[2979]: [HDR Layer] Enabling format: 97 colorspace: 1000104005
Jun 08 17:18:58 tile steam[2979]: [HDR Layer] Enabling format: 64 colorspace: 1000104008
Jun 08 17:18:58 tile steam[2979]: [HDR Layer] Enabling format: 58 colorspace: 1000104008
Jun 08 17:18:58 tile steam[2979]: [HDR Layer] Enabling format: 97 colorspace: 1000104002
Jun 08 17:18:58 tile steam[2979]: [HDR Layer] Enabling format: 97 colorspace: 1000104005
Jun 08 17:18:58 tile steam[2979]: [HDR Layer] Creating swapchain for id: 38 - format: VK_FORMAT_R16G16B16A16_SFLOAT - colorspace: VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT
Jun 08 17:18:58 tile uwsm_hyprland[2370]: error in client communication (pid 27377)
Jun 08 17:18:58 tile steam[2979]: [destroyed object]: error 5: Invalid luminances
Jun 08 17:18:58 tile steam[2979]: 06/08 17:18:58 minidumps folder is set to /tmp/dumps

Heres what those log lines look like with the working poe2 for comparison:

Jun 08 17:19:18 tile steam[2979]: [HDR Layer] Created HDR surface
Jun 08 17:19:18 tile steam[2979]: [HDR Layer] Enabling format: 64 colorspace: 1000104008
Jun 08 17:19:18 tile steam[2979]: [HDR Layer] Enabling format: 58 colorspace: 1000104008
Jun 08 17:19:18 tile steam[2979]: [HDR Layer] Enabling format: 97 colorspace: 1000104002
Jun 08 17:19:18 tile steam[2979]: [HDR Layer] Enabling format: 97 colorspace: 1000104005
Jun 08 17:19:18 tile steam[2979]: [HDR Layer] Enabling format: 64 colorspace: 1000104008
Jun 08 17:19:18 tile steam[2979]: [HDR Layer] Enabling format: 58 colorspace: 1000104008
Jun 08 17:19:18 tile steam[2979]: [HDR Layer] Enabling format: 97 colorspace: 1000104002
Jun 08 17:19:18 tile steam[2979]: [HDR Layer] Enabling format: 97 colorspace: 1000104005
Jun 08 17:19:18 tile steam[2979]: [HDR Layer] Creating swapchain for id: 35 - format: VK_FORMAT_A2B10G10R10_UNORM_PACK32 - colorspace: VK_COLOR_SPACE_HDR10_ST2084_EXT

[edit]
links to relevant conversations in other repos:
https://github.com/hyprwm/Hyprland/issues/9064#issuecomment-2953655029
https://github.com/Zamundaaa/VK_hdr_layer/issues/13

@ibrokemypie you can remove ENABLE_HDR_WSI, it was deprecated in GE-10-2: "Removes setting ENABLE_HDR_WSI -- this option is only specific for the vk_hdr_layer (https://github.com/Zamundaaa/VK_hdr_layer) hack, which is -not- needed as of mesa 25.1 and can cause washed out colors. If you previously used this, it's advised to remove it, and update mesa to 25.1 if you want HDR."

@ibrokemypie you can remove ENABLE_HDR_WSI, it was deprecated in GE-10-2: "Removes setting ENABLE_HDR_WSI -- this option is only specific for the vk_hdr_layer (https://github.com/Zamundaaa/VK_hdr_layer) hack, which is -not- needed as of mesa 25.1 and can cause washed out colors. If you previously used this, it's advised to remove it, and update mesa to 25.1 if you want HDR."

I am on nvidia hardware unfortunately, so not using mesa the vk layer is still required.

I've noticed some performance degradation on OW2 on Linux within the last few months. Performance seems to have taken a hit overall from a few months ago, most notably in the form of micro stutters (post shader compile, so not that) every so often. Game is still playable (~200 FPS) but FPS fluctuations are very noticeable. It also seems that RAM usage has increased dramatically. A few months ago, RAM usage was always <10 GB but now grows to upwards of 25 GB. This is not a major issue because I have 32 GB, however the timing of this may be related to the performance issues I've also been noticing. It also seems that the shader compilation process takes longer than it used to (based on high CPU usage and bad performance for first couple of mins after launching the game), though its hard to remember exactly.

A friend of mine with a similar setup has been experiencing the same, and I've seen a similar sentiment on ProtonDB. I've tried going back several Proton versions (normal and GE), older kernel versions, as well as deleting the proton pfx several times. Nothing seems to fix this, even trying proton wayland and ntsync on latest GE. I suspect it may not be a direct issue with Proton, maybe something else in the graphics stack, or perhaps they changed something with the game? Can anyone else confirm the same symptoms?

(Arch, Hyprland, 5800X3D, 7900XT, several versions of kernel up to 6.15.7, several versions of proton up to GE 10-10)

@lsr1006 I confirm that I'm seeing the same behavior lately. I've distro-hopped (from Manjaro to EndeavourOS) and I 'm seeing similar behavior.

I've tried enabling lots of different things, and none of them solved the issue: zen-kernel, gamescope, proton-ge-10-10, proton experimental, proton 10, directx12, directx11, radv, amdvlk.

I have a 7900XT AMD GPU so my FPS is between 180-240, but some very noticeable spikes happen sometimes.

Something I noticed is that now my GPU is not at 100%, it fluctuates at 70%:

I'm on KDE.

This game now has huge frametime issues. However framerate is good.
Steam shader pre-cashe is on but does not help, locking frametare to 141 (144hz screen) does improve a little.

Ryzen 5800x
32GB ram
Radeon 9070
Bazzite distro

steam-2357570.log

The game seems to be running fine on my end. I have a RX 9060 XT and 5700X3D
I tested with DX11 with low preset and high preset, and DX12 with high preset. 2 games each, fullscreen, vsync off, framerate cap set to 600 FPS, plasma wayland, proton 10, linux 6.15.9. I'd like to know more about the setups of those affected and if it takes a long time for the issue to manifest, it'd be good to clarify that.

It's also worth noting that at least the DX11 renderer has a lot of shaders to compile, so if you jump right into a match right after starting a game I'll likely still be compiling shaders, you can verify this adding this to the launch parameters DXVK_HUD=compiler, this will display text in the bottom left corner when shaders are being compiled, so you can tell when it's fine to join a game.

A update on my end. Tested yesterday with proton experimental bleeding edge and there are still issues with micro-stutter when framerate is unlocked. Capping fps to 140 and most of the stutter is gone, in this case it only happens in very intense scenarios.
And further testing today with proton experimental-BE (and with proton 10.0-2) but with DXVK_HUD=compiler flag set, I can see that it is compiling shaders every now and then but the stutter is constant from the beginning (no fps cap, 600) and lasting several rounds of gameplay.

Settings are set to high presset, DXVK, fullscreen, vsync off.
Bazzite kernel 6.15.9-106
Plasma, wayland
Mesa 25.1.3

If other info/logs are needed let med know.

@motpol gave it a go with bleeding edge, mesa 25.1.7, no fps cap, no vsync, highest settings, plasma wayland and played for a bit over an hour and had no issues. I let the initial shaders compile at the start (from time to time you could see the game compiling more through the hud, though I couldn't "feel" them). Ram usage grew around 1.5GB comparing startup of the game against when I closed it, so it doesn't look like this would be an issue.

While I had it enabled, have you tried disabling the steam overlay and seeing if that changes anything? Do you have background recording enabling?

Mangohud can be configured to show things like gpu clock speed, usage and power, does that show anything unusual? Like lower clock speed than expected, for example.

@simifor and others, Quick update - played a few games today with DXVK complier hud enabled, and will provide some more detail.

Initial shader compile took about 1-2 mins. After this, FPS is near 170-200 during low action moments but dips well below 140 during chaotic team-fights. The frame pacing feels horrible even when FPS is high. Almost to the point that I was noticing an impact on latency and my ability to aim. There are also random frame drops that happen during game-play. I did notice intermittent shader compilation happening during game-play, but the performance is already so mediocre that I can't really pinpoint the timing of that with the frame drops exactly. System RAM used goes from ~5GB (idle on desktop with steam/discord running) to ~20GB after launching the game and finishing compiling initial shaders.

Honestly this game feels worse and worse every time I play. Again just for context, a year ago I could constantly exceed 250+ FPS with no dips and there was no issues with frame time or frame pacing. No other games I play seems to be affected. Issue presents immediately and does not seem to improve after playing for long sessions. Frame time graph looks fairly normal after the shader compile, but it still feels terrible to play. You may be able to tell that its wavering a bit even in screenshot 2 and 3.

During shader compile within 1 min of launching the game (sitting still in practice range):

After shader compile finishes (sitting still in practice range):

Sitting still in spawn (real match) after playing for about 30 mins:

Again, running the following: Arch, Hyprland, 5800X3D CPU, 7900XT GPU

System (issue present on many versions of all below):

• Kernel: linux-cachyos 6.16.0-5 (tried vanilla arch and other alternate kernels too)
• Steam client version: 1751405894
• Mesa 25.1.7-arch1.1
• Hyprland 0.50.1 (Wayland)

* = things I might try to enable/disable if I have more time to test this
*** = things I've already tried changing with no improvement

Game Settings:

• Borderless windowed ***, DX11
• Mostly ultra settings, some reduced
• 100% render scale, no dynamic render scale, no FSR
• No VSYNC, frame cap 600 (in game settings) ***
• Reduced buffering on ***, high precision mouse input on ***

Other info:

• Proton GE 10-10 *** (NTSYNC enabled ***, xwayland mode ***)
• Steam game recording off
• Steam overlay on ***
• Mangohud on *
• No gamescope
• No other launch commands

Another update: I just downloaded the game on the battle.net launcher using Heroic, and the issue does not present at all on the same version of Proton (and adjusting to the same graphics settings):

Notice the much lower ram usage. No issues with frame time or pacing whatsoever. I'll have to play a few real games to make sure, but I think its safe to say there's some issue with the steam client that is conflicting with this game.

Can others who have experienced the issue confirm the same? @motpol @edisongustavo

EDIT: It is worth noting this is the flatpak version of Heroic launcher, so some dependency versions may be different. I'll try to confirm this as well.

@lsr1006 tried borderless but no change on my end. It's true that flatpak would use its own set of drivers, but I've had no issues with the same one as yours (though we are on different generations of cards so it's not impossible there's an isue affecting only one of them). Also, at least for reporting issues here you should stick to first party proton releases, GE has its own issue tracker., and extra patches like wayland or ntsync could interfere.

I'd also try on a different desktop environment to get it out of the list of potential culprits.

@simifor
I cant really comment much on these stats since I have only had this GPU and bazzite for a month or so. That being said all these numbers seems normal, FPS might be a litle low for this setup and title (200-350 range), can dip to under 144 fps. RAM usage of the game is arround 8GB in middle of a round is alright. I should add that my CPU is probably holding back my GPU, aka bottleneck. But not sure if that matters in this title? GPU usage is around 99%, CPU usage 30-40% indicates no bottleneck.
Also adding in that my Linux Mint setup (same spec different drives) acts the same.

Steam overlay was enabled but turning it off makes no difference. Steam recordings was set to manuall and I am not recording and is now off.
Shader-cash size for OW ~30GB, this is a lot! But pretty sure OW always has had a great amount. Also before testing on 13.08.25 steam shader downloaded ~10GB of shaders, dont know why it doesnt download it all in one go, just an observation.

@lsr1006
Bottles seems to have the same issue, only testing in testrange for about 10 min. GE-Proton-10-11
Heroic (GE-Proton-10-10) is acting the same for me, still too much stutter from my experience, playtime ~20 min testrange and real match. Been playing this game on Linux since 2019 or so, and the amount of stutter in all of these clients is abnormal and unplayable.
Steam beta test act the same, but with a higher FPS than GE-proton.
Your symptoms seems the same as I have, except for the high ram usage.

Steam Version: 1751405894
Steam Version: 1754956157 (Beta)

Heroic, shader compiling:

Heroic done compiling:

STeam beta Proton experimental bleeding edge, done compiling:

Playing yesterday for several hours with proton bleding edge (experimental-bleeding-edge-10.0-233402-20250822-p9d5559-w339e5c-d448fd8-v334e77) on linux mint and its running great with no frame-cap, high fps and no stutter or framepace issues! :)

Going back to normal experimental today and its running great too, might be a rare micro-stutter now and then. But its also running with about 100 fps more (400-470 vs 500-570fps) compared with bledig edge today in practice range only for about 5-10 min each.

Edit: proton version number

That could still be texture re caching. 10min of only seeing your own animations is nothing.

What i found over my last few big 7h+ sessions is that Overwatch 2 LOOOOOVES running on pure Wayland and NTSYNC instead of XWayland and fsync.

NTSYNC

https://www.reddit.com/r/linux_gaming/comments/1lxnz0g/lets_get_that_ntsync_stuff_enabled_small_guide/

TLDR : sudo modprobe ntsync on a 6.1x kernel

Native Wayland in Proton

• Latest GE-Proton required
• Add PROTON_ENABLE_WAYLAND=1 to command line in steam
• Add WAYLANDDRV_PRIMARY_MONITOR="DP-1"' to command line in steam if your game launches on the wrong monitor. Display info can be found with wayland-info

Overwatch absolutely loves to be run in native wayland. Its a night and day difference gameplay feeling wise.

I'm on uptodate Tumbleweed KDE with 580 closed drivers.

@motpol I don't know if I'm misunderstanding, but you're saying there's a 100 fps gap between experimental and bleeding edge? I'm getting the same performance for both at low and high preset on plasma wayland

@simifor Yes thats correct, normal experimental had the highest fps. But do take note that this test was short and in practice range only. This was mostly just to verify if the extreme stutter was gone on both versions, in practice range, same settings and setup. I have still not tested on a bleeding edge distro, just Mint with Cinnamon, Mesa 25.1.7 and kernel 6.14.

@TerohsLab That sounds promising. I will take a look at it when I have time, thanks.

Update:
My issue with stuttering in the past weeks/month must have been a shader-cache thing, as my bleeding-edge distro still has the issue.

Just sharing a wine bug thats tracking saving highlights in mp4 format https://bugs.winehq.org/show_bug.cgi?id=56137

The NTSYNC fix did help A LOT for some days (from https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-3218326999), but nowadays the game is literally unplayable. For some reason I also lost the DX12 option, which I can't for the life of me add back.

@edisongustavo the game is working as usual on my end. I think that the performance and lack of dx12 being presented as an option are likely related, so I'd expect some sort of issue related to your gpu.
Add this to the game's launch parameter PROTON_LOG=1 %command%, run the game with proton experimental and close it after reaching the main menu, then bring the resulting steam-2357570.log that will appear in your home folder. Also bring your dmesg log that will appear in the same place by running the following in your terminal sudo dmesg > dmesg.log

Season 20 update is now crashing, appears to happen when opening the in game chat

System Information

• GPU: AMD Radeon RX 6600
• Video driver version: Mesa 25.3.1
• Kernel version: Linux 6.17.8-saygo-xanmod1
  • (I compiled with -o2, for my cpu, and removed modules from xanmod. should have no effect on this)
• Link to full system information report as Gist: https://gist.github.com/saygo-png/9027f06f8c795aca2e3fee640701828c
• Proton version: GE-Proton10-25, Proton hotfix and experimental

I confirm:

• [ ] that I haven't found an existing compatibility report for this game.
  • I did, hence why im posting under this
• [x] that I have checked whether there are updates for my system available.

Symptoms

Game crash since the start of season 20 (Which started just a couple of hours ago)

Reproduction

First way

1. Open the in-game chatbox
2. Close it (via escape or enter)
3. Crash occurs

Second way

1. Open the battlepass screen from the main menu
2. Navigate to the end of it (tiers with titles)
3. Click on one of the titles
4. Crash occurs

Third way

1. Click Play from the main menu
2. Click Missions
3. Click the center, large screen. You can also press the back button.
4. Crash occurs

There are also numerous other ways, often involving text.
For example searching for custom games, importing custom game codes.

The attached log is from crashing the second way.

steam-2357570.log

Some other reports of this:
https://us.forums.blizzard.com/en/overwatch/t/your-best-customer-linux-now-crashing-s20/992569
https://us.forums.blizzard.com/en/overwatch/t/proton-support-is-broken-game-crashes-on-esc-chats-etc/992546

https://steamcommunity.com/app/2357570/discussions/0/689743495770993552/
https://steamcommunity.com/app/2357570/discussions/0/689743495770990860/

@saygo-png
I have made a post on the forum, Perhaps its game related not OS related?
[Your best customer] Linux now crashing, S20

It crashes on Windows too, looks like Season 20 update related, not Linux specific.

@FringeNet Could you link to this issue/my post on https://us.forums.blizzard.com/en/overwatch/t/proton-support-is-broken-game-crashes-on-esc-chats-etc/992546? I can't log in the battlenet forums due to a 500 internal error when attempting to....

I believe they don't allow external links in the forum, hinted by the fact that ctrl + v simply doesn't work

Judging by the memory access violations in the crash logs, I reckon there's some anti cheat tomfoolery going on

From @saygo-png's log:

30875.367:012c:0130:warn:seh:dispatch_exception backtrace: --- Exception 0xc0000005.
30875.367:012c:0130:trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) flags=0 addr=0000000141B69BB0

From my log:

293959.389:0134:0138:warn:seh:dispatch_exception backtrace: --- Exception 0xc0000005.
293959.389:0134:0138:trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) flags=0 addr=0000000141B69BB0

This happens at the exact moment of crash, no matter the way you reproduce it.

Can confirm it happens specifically when opening the chat and pressing enter when the chat is open, tested on Proton 10 and Proton Experimental.

Log:

steam-2357570.log

Edit: and yup, clicking prestige tiers in the battle pass does the same crash.

The issue with the game crashing should be resolved now - Blizzard has released a fix

Confirming new build id 21121308 pushed 12/10/2025 at 3:40 via Steam fixes the "crash on ESC" issue.

Hi just adding my experience here. Game doesn't crash for me but its audio is glitchy in comp games and also the characters don't render until too late in the game. This seems to be on proton 10-10GE Bazzite OS. Ryzen 5900X and Nvidia 3090. I do have the Nvidia base but I had patched it in and was using the AMD base previously. I have the Plasma desktop.

@yugonline tried the game on proton experimental and it's working normally here. A couple of questions:

• Are you using the dx11 renderer?
• Have you noticed if the audio issues disappear or lessen after the graphical issues disappear?
  This games can take up to several minutes to compile shaders (gpu vendor and cpu power are factors), I think dx12 should be working better in this regard for this title. It's normal to see missing things (like characters in your case) when shaders haven't been fully compiled. Compiling shaders also spikes your cpu usage and may result in audio popping when it otherwise wouldn't.

Same issues again as with the Season 20 update on new build 21229842?

Same issues again as with the Season 20 update on new build

Played a couple of games yesterday and had no crashes. Also failed to trigger it with battlepass titles screens and in-game Esc menu and text chat. So the answer is "no". At least for me the latest release is free of this bug.

The game is behaving normally on my end. Checked with proton experimental, a rdna4 card, mesa 25.3.2, and both dx11 and dx12 renderers. Several matches, battlepass screen, etc.

Same issues again as with the Season 20 update on new build 21229842?

Following up on my comment, my actual issue was (the same as the one with the Season 20 update, that I had little micro-stutters every 2-3 seconds which basically made the game unplayable. Anyone having the same issues: I'm always playing on boarderless window, so I tried switching to fullscreen and then back, which weirdly seems to have fixed the issue for me?
Still weird though that this started happening only with the recent updates, before I could play a year without any issues.

@71387
This sounds like shader-cache are loading. Overwatch has alot of shaders, and with new updates it might bring in more shaders (as they are adding new content). In addition to that there are other factors that triggers compiling of shaders, such as changing GPU or GPU drivers. Regardless of why shaders are compiling the symptoms tend to be micro-stutters and lower performance while compiling, and this might take a few minutes or maybe up to an hour depending on your hardware and amount of shaders.

@71387 This sounds like shader-cache are loading. Overwatch has alot of shaders, and with new updates it might bring in more shaders (as they are adding new content). In addition to that there are other factors that triggers compiling of shaders, such as changing GPU or GPU drivers. Regardless of why shaders are compiling the symptoms tend to be micro-stutters and lower performance while compiling, and this might take a few minutes or maybe up to an hour depending on your hardware and amount of shaders.

I always pre-compile shaders and have a UI ingame that shows as soon as shaders are re-compiled. I've had the experience of compiling shaders while running the game in the past and it was a bit different than this issue. Thanks for the comment, though I don't really wanna spam this general thread with my specific problem anymore.

Symptoms

Game fluctuates ping between matches wildly (40-120ms for me), occasionally spikes in matches. 10-20% packet loss for the last two or three patches (I haven't kept track). I do not experience this issue on Windows, I have tested it between different distros, different kernels, different Proton versions. Other people are reporting this issue as well, for example https://us.forums.blizzard.com/en/overwatch/t/consistent-10–20-packet-loss-since-new-season-on-linux/998697/8

Also seeing this. Uncertain if it's a linux or proton specific thing (some forum posts indicate that it's also happening on windows boxes).

More symptoms: An older win10 machine on the same network playing in the same group and game as me will have 45ms latency to ord1, while my NixOS box has 200ms latency.

I once got it to go from 200ms to 45ms in practice range by restarting resolvconf before restarting the session, but it was not a repeatable fix.

I also find that the latency doesn't drop below some "specific" point once the match is established, ex: if I start at 200ms, I won't go below 200ms that entire match. If I start at 80ms, 120ms, or 150ms, same thing.

I've checked and seen that I regularly have 10-15% packet loss in one direction, but that's present regardless of if I have the same latency as the windows machine on the same network or not.
edit: still saw 200ms latency with 0 packet in/out loss

Adding to this that it doesnt just happen on ORD1 other servers are also impacted e.g here AMS1 from my findings (see ctrl + shift + n) in game

Also seeing similar effects in AMS1. Ping fluctuates between 20-40ms to 120ms with no in-between. Was much more common in the previous patch than it is now. I'd say it happens once in every 10 games, vs. once in every 3 previously.

I've also noticed it disappearing between games, without restarting or making any changes to the network stack.

I've been having similar issue, primarily with ams1 server since I'm in EU, so I did some testing with Custom Games (since they allow to choose on which server the game should be hosted), and I've noticed a pattern: the issue seems to be limited to games that are hosted on, or proxied through, servers owned by Blizzard.

From my limited testing, when the Custom Game is hosted on one of the following servers:

• NETHERLANDS (ams1)
• SOUTH KOREA (icn1)
• USA SOUTH-WEST (las1)
• USA CENTRAL (ord1)
• AUSTRALIA 3 (syd2)

...all the data is going through Blizzard's servers in Netherlands (since I'm in EU), and usually either the LOSS OUT percentage is between 10-20%, or the latency is high or unstable (at least on ams1 server, hard to tell with others because of long distance).

With all other available options:

• BRAZIL 2 (gbr1)
• FINLAND 2 (gen1)
• SAUDI ARABIA (gmec2)
• SINGAPORE (gsg1)
• JAPAN 2 (gtk1)
• TAIWAN (tpe1)

...I end up connecting to servers owned by Google located in the respective countries, and these Custom Games seem to be issue free (gen1 server for sure is).

For anyone who would also like to test this, since the IP address of the server in no longer being shown in the Network Graph and Blizzard has started rotating IP addresses from time to time, I've used iftop to find the IP addresses the game connects to (just look for an address to which ~50kb of data is constantly being sent to and received from, assuming you're hosting a Custom Game with no other players in the lobby) and then used IP lookup to find to whom the IP address belongs to.

Now, my networking skills aren't exactly my strongest suit, and I can't currently perform the same test on Windows, but I'm not sure how this could be caused just because the game is running on Linux/Proton?

Additionally, after a big patch comes out in around 20 hours, there's a high chance servers might be struggling, so I would delay any testing for a day or 2 after it's out. Hell, if we're lucky, maybe the issue will be fixed by then?

Also, for future reference, I would advise against using Practice Range for testing this - Overwatch for the longest time has been having an issue where, if you load Practice Range right after booting up the game, it will put you on a random server on the other side of the world (Practice Range also runs at a lower tick rate, but I don't think this should matter in this case).

For me the issue has been very intermitent, my ping on Windows 11 goes from 38 to 44 ms, on linux I get about 10ms more at the lowest

The main issue tho, is that I have to restart the game multiple times before I can get my usual 50ms ping, otherwise I am stuck with 120ms to 170ms

On steam using Proton, I restart the game and go in practice range, check the server and ping, if its not ord1, close and reopen practice range, if it is ord1 and my ping is over 100ms, I restart the game, 120, restart, 100, 140, 50.. its completely random, sometimes I'll open the game and it will be 50ms from the start, which leaves me with leaving the game open for hours even if I don't play so I don't have to restart 10 times to get 50ms again when I want to play again, as it will keep the low ping until I restart

Launching it through Battle.net with Umu and Proton has me wait 2 min for the launcher to open and launch the game, relaunching only the game without relaunching the whole Proton environment will always give me the same ping, which leads me to believe it is Proton/Wine having issues here.

The ~10-25% seems to be irrelevant, yes you sometimes get warning icons, but I can still have 50ms with 25% packet out loss

I've never had these issues on Windows 11 on the same computer

Confirming this issue. 10-27% LOSS OUT (never LOSS IN) on Pop!_OS 22.04, kernel 6.17.9, Intel I226-V NIC (igc driver), AMD GPU. Tested on both Proton Experimental and GE.

Same thing is happening to me. ~35% LOSS OUT on ord1 and las1. gsg1 is fine, apparently. Running Arch, have tried Proton 8, 9, and Experimental with the same issues. Started happening about a week ago.

You can access this graph by hitting CTRL + SHIFT + N btw.

Regression: DX11 (DXVK) mid-match crashes since February 10th update

System Information:
GPU: RTX 4070 Super
Driver: 580.126.09 (NVIDIA)
Kernel: 6.18.8-1-default (openSUSE Tumbleweed)
Proton: GE-Proton 10-30 (also tested Experimental and 9-25)

Description: Since the "Stadium" update, the game is consistently hitting a Signal 11 (SEGV) mid-match when using the DX11 (DXVK) renderer.

DX11 (DXVK): Crashes ~2-5 minutes into active 5v5 gameplay.

DX12 (VKD3D): Stable and does not crash, but exhibits much higher GPU usage and poorer frame pacing compared to DX11.

Log Evidence: The crash is a silent exit that occurs immediately after an unhandled Reflex marker. My logs consistently show:

warn: Reflex: Unknown marker 7
info: nvapi64:<-NvAPI_GPU_GetLogicalGpuInfo: OK
trace: loaddll:free_modref Unloaded module L"...Overwatch\ErrorReporting\x64\dbghelp.dll"

The unloading of dbghelp.dll (the crash reporter) immediately after the "Unknown marker 7" warning suggests a hard crash at the NVAPI translation level before the engine can generate a report.

Note: This is occurring during active gameplay, not just when pressing ESC or using Chat (though those also trigger crashes). PROTON_NO_NTSYNC=1 and PROTON_NO_FSYNC=1 do not resolve the issue.

steam-2357570.log

ok I got it to run for longer this time but it still crashes in the end. Journalctl shows just a few entries that are relevant. Don't know why it shows game recording when I have it off in settings for both the game and steam. The only other entry that I see that might be related is at 6:02:36 that I will put as well. Otherwise I don't see anything in journalctl other than removing game process every time it crashes. Actual crash is at 6:07:05.

Feb 11 06:02:36 pdesksuse kwin_wayland[3044]: 0x501: GL_INVALID_VALUE error generated. Size and/or offset out of range.
Feb 11 06:07:05 pdesksuse steam[134184]: Game Recording - game stopped [gameid=2357570]
Feb 11 06:07:05 pdesksuse steam[134184]: Removing process 136619 for gameID 2357570
Feb 11 06:07:05 pdesksuse steam[134184]: Removing process 136617 for gameID 2357570
Feb 11 06:07:05 pdesksuse steam[134184]: Removing process 136615 for gameID 2357570

Then this happened when I was swapping off vkd3d to dxvk as I was quitting the game before that. Seems to happen consistently when swapping from vkd3d to dxvk actually.
Feb 11 05:51:55 pdesksuse systemd-coredump[136586]: Process 135261 (Overwatch.exe) of user 1000 dumped core.
Feb 11 05:51:55 pdesksuse systemd[1962]: Started Launch DrKonqi for a systemd-coredump crash (PID 136587/UID 0).
Feb 11 05:51:55 pdesksuse drkonqi-coredump-launcher[136602]: Unable to find file for pid 135261 expected at "kcrash-metadata/wine64-preloader.8da03f92abf44c339f8631a1cec2b830.135261.ini"

One more log in ~/.steam/steam/steamapps/compatdata/2357570/pfx/drive_c/users/steamuser/Documents/Overwatch/Logs/Overwatch.log
last 3 lines in zulu time correspond to 6:01 to 6:03 PST just before the crash and mention voice chat. I have voice chat off in the game as well but made no difference apparently.. Also I know I have easyeffects on, but I tried without it and same difference, same crash. Not even sure if this is relevant.
Again, I don't see any crash messages, the game just quits unexpectedly.

Overwatch.log

Edit: all that and I upgraded kernel and no more crashes. On 6.18.9-1 now.

Edit2: I take it back, next day its crashing randomly again. Same messages. No real clues. Just game recording stopped and then removing game process in journalctl. I don't get it.

Edit3: Ok someone on reddit linked me this thread with a comment from doitsujin with a dxvk option that has done wonders. No more crashes and much lower ram usage. I wasn't paying attention to ram or vram before and I still havent actually checked vram but i have checked ram and its at least 6 gb lower with this option and like I said, no more crashes. So something to do with vram or ram seems likely. dxvk.trackPipelineLifetime = True
https://github.com/doitsujin/dxvk/issues/3813

https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-3884108956

Is there a chance you can share the journalctl when the crash happens? This looks like it could be a driver level crash not seen by Wine/the game.

For anyone still having the networking issue with ord1, especially with dropped packets, there is quick fix on the support thread
changing the default TTL to Windows' default seems to fix the issue

sysctl -w net.ipv4.ip_default_ttl=128

Replying to https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-3884108956

Interestingly, since that date I'm having crashes "device not found" (refeering to the GPU), GPU freezes, or full system stall.

Game launches in poor performance, inconsistent 15-40fps, and eventually crashes during matches, training or even lobby. CPU hard pin to 100% and graphics are not even using 50% capacity. My system is an old 3770K with GTX 960 2Gb, but 2 days ago the game run at 60fps SOLID (fps cap/v-sync), no stuttering, no frame drop, nothing. I'm using nvidia 580.126.09 open drivers in CachyOS with proton cachyos 10.0-20260207 native, but it happens in any other single version of proton. Tried most default in-game video settings (like disabling reflex, v-sync, etc). Game still crashes. Other games like CS works FINE and don't experience any similar simpthom.

So based in your comment I'm assuming this has something to do between proton and latest OW update.

EDIT: I can drop debug data if it helps, just tell me what you guys need.

In known issues listing it is stated that lag issue was fixed:

Don't have it anymore on my side.

As far as the network instability issue I'm not really noticing a difference when compared to other seasons, but I don't play this game often. How do you change the server location? I haven't found the option.

I was originally getting good FPS and minimal lag on DX12 but then players were invisible and stopped loading. over 2x VRAM used than DX11, but no crashing.

DX11, however, still has a lot of random crashing but uses much less VRAM and also has minimal lag.

@StupidRepo well, memory usage does increase over time until seemingly settling down, comparing dx11 and dx12 with the same settings, after a bit over an hour of quick match and then comparing values in practice range. I saw dx11 using 2.5GB of VRAM and 3.2GB of RAM, while dx12 was using 2.5/5.4GB though I had been checking at other points and it seemed to be stable at around 5 point something gigabyte of memory and didn't look like it was going to grow indefinitely. This with rdan4, linux 6.18.0 and mesa git as of a few days ago.

While it's never going to be a perfect oranges-to-oranges comparison as the map and hero selection might have an effect in what's stored in memory, it does seem like dx12 uses a bit more memory. If you were close to your memory limit with dx11, it's possible you're running out with dx12 eventually.

Overwatch dx11/dxvk has severe memory leaks

Overwatch dx12/vkd3d (with VKD3D_FEATURE_LEVEL) fix the memory leak but lower framerates and mess with heros' shaders

DXVK_CONFIG="dxvk.trackPipelineLifetime = True" fixes the memory leak on dx11 without having the problematic framerates and messing with heros' shaders like the default dx12 version does

I've found using DX12 results in much higher framerates, and if you use Wayland then it prevents some weird crashing bug. Only issue is that the models take a long time to load in but once they're loaded then you're basically good to go.

@StupidRepo it's the opposite way around for me, can you please output your steam system information?

Shader compilation speed seems to have improved in the new Overwatch patch. Before, with an empty shader cache, it took almost 3 hours to stop stuttering on my i3-6100 with the CPU at 100%. Now, with an empty shader cache, in less than half an hour it’s already playable and stable. Try the new patch as well.

https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-4387886032

Try setup a dxvk.conf with dxvk.trackPipelineLifetime=True, generally this goes next to the executable.

Normally you only need to use this for 32-bit games but this could help in cases where Overwatch's 110K individual shaders for some reason take too much RAM with your GPU+Driver combination.

On my PC, the game normally used 8GB+ of RAM but with that option set to true, it only uses up to 5.
Quick heads-up as well that this can also reduce performance in some cases.

[#7033 (comment)](https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-4387886032)

Try setup a dxvk.conf with dxvk.trackPipelineLifetime=True, generally this goes next to the executable.

Normally you only need to use this for 32-bit games but this could help in cases where Overwatch's 110K individual shaders for some reason take too much RAM with your GPU+Driver combination.

On my PC, the game normally used 8GB+ of RAM but with that option set to true, it only uses up to 5. Quick heads-up as well that this can also reduce performance in some cases.

It did successfully reduce RAM usage, but as you said it also unfortunately reduced performance to an unusable state.

https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-4063362431 from @Malix-Labs :

Overwatch dx11/dxvk has severe memory leaks

Overwatch dx12/vkd3d (with VKD3D_FEATURE_LEVEL) fix the memory leak but lower framerates and mess with heros' shaders

DXVK_CONFIG="dxvk.trackPipelineLifetime = True" fixes the memory leak on dx11 without having the problematic framerates and messing with heros' shaders like the default dx12 version does

Did something change since then?

My config when I wrote this message was this one : https://www.protondb.com/app/2357570#29CoOpk6VK

Custom Proton: proton-cachyos-slr-x86_64_v3
Distro: NixOS 25.11 (Xantusia)
Kernel: 6.19.6-cachyos-lto
RAM: 14 GB
GPU Driver: 4.6 Mesa 25.2.6
GPU: AMD Radeon (radeonsi, renoir, ACO, DRM 3.64, 6.19.6-cachyos-lto)
CPU: AMD Ryzen 7 5800H with Radeon Graphics

On the testing branch of Bazzite I'm seeing the game no longer launch. Bnet will launch but clicking play closes Bnet and nothing else happens. Rebasing back to stable fixes issues.

These are the logs from Lutris: https://gist.github.com/gitty323/349450aee8a9fcdf7706c6eda9e6b48a

I'm not sure where in the toolkit the issue is to be able to report to the right people and don't see anything specific in the logs that points an issue out.

On the testing branch of Bazzite I'm seeing the game no longer launch. Bnet will launch but clicking play closes Bnet and nothing else happens. Rebasing back to stable fixes issues.

These are the logs from Lutris: https://gist.github.com/gitty323/349450aee8a9fcdf7706c6eda9e6b48a

I'm not sure where in the toolkit the issue is to be able to report to the right people and don't see anything specific in the logs that points an issue out.

Isn't proton specifically for Steam ? Why use Battle.net when the game is available on Steam with no launcher

Replying to https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-4526718139

Proton is made by Valve but Steam is not required - many ppl use other launchers such as Heroic or Lutris with Proton. There are privacy concerns w the Steam version of OW as it requires you linking your Bnet and Steam accounts and then anyone else that uses Steam can view your Steam profile from in game. I also like to reduce my reliance on monopolistic workflows so making my game launch independent of Steam is important to me.

Following this guide, I was able to generate a fresh working prefix for Battle.net through Steam and then I copied that prefix into my desired location and now launching through Heroic works fine. My old prefix was generated in Lutris with one of their scripts so maybe it is related to that configuration. I have been unsuccessfully (due to this bug) trying to ditch Lutris for a while now so I'm happy to have figured out how to get it working through Heroic finally, even if it requires a bit of jank to get setup.

Following this guide, I was able to generate a fresh working prefix for Battle.net through Steam and then I copied that prefix into my desired location and now launching through Heroic works fine. My old prefix was generated in Lutris with one of their scripts so maybe it is related to that configuration. I have been unsuccessfully (due to this bug) trying to ditch Lutris for a while now so I'm happy to have figured out how to get it working through Heroic finally, even if it requires a bit of jank to get setup.

Your setup is unsupported, this github bug tracker is only for games on Steam.

Compatibility Report

• Name of the game with compatibility issues: Overwatch
• Steam AppID of the game: 2357570

System Information

• GPU: RTX 4060
• Video driver version: nvidia 595.71.05
• Kernel version: 6.17.0-35-generic
• Link to full system information report as Gist: Gist Link
• Steam Runtime Diagnostics: Gist Link
• Proton version: 1780064122 experimental-11.0-20260529

I confirm:

• [X] that I haven't found an existing compatibility report for this game.
• [X] that I have checked whether there are updates for my system available.

Proton_LOG=1 running 'experimental-11.0': steam-2357570_Bad.log
Proton_LOG=1 running '11.0 beta': steam-2357570_Good.log

Symptoms

When the game is started while already configured to use full-screen mode, the game doesn't recognize keyboard inputs- a keyboard press gets ignored by the game (alt-tabbing works).
Even 'esc' doesn't do anything, mouse works fine.
Also, when started as full-screen, but then changed to windowed it just fills the extra space and coesn't fix the issue:

If I start the game with the setting set to windowed/borderless, it works fine and changing to full-screen doesn't break it.
This is on the Proton 'experimental' version, when going back to '11.0 beta' the issue is resolved (both logs are above).
Another Steam game running the 'experimental' works fine.
Tried both DX11&DX12.

Reproduction

Set the game to run with full-screen & proton 'experimental-11.0', enter the main menu or load into a game and try using the keyboard.
For example, on the main menu pressing 'esc' will not open the game "Menu".

https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-4630648607

What distro and window manager? This seems like Window Manager issues to me as I don't have this issue with that version of Proton. (Xfce + Picom)

Also looking at your Proton log you apparently have a 4060.

[#7033 (comment)](https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-4630648607)

What distro and window manager? This seems like Window Manager issues to me as I don't have this issue with that version of Proton. (Xfce + Picom)

Also looking at your Proton log you apparently have a 4060.

Thanks you're correct its actually 4060, typo (fixed).
Im running Linux Mint 22.3 with Cinnamon/Muffin.

[#7033 (comment)](https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-4630648607)

What distro and window manager? This seems like Window Manager issues to me as I don't have this issue with that version of Proton. (Xfce + Picom)
Also looking at your Proton log you apparently have a 4060.

Thanks you're correct its actually 4060, typo (fixed). Im running Linux Mint 22.3 with Cinnamon/Muffin.

Willing to bet Muffin's doing something funky; see if a Window Manager like Openbox works. Not sure if Cinnamon supports swapping the Window Manager like MATE does but if it does test it that way.

Replying to https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-4631704131

Seems like you're correct, I installed Xfce+xfwm4 on the same system (Mint 22.3) - and now it works fine.
Not sure who to blame, Proton or Cinnamon.

https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-4632330846

While a Proton 11 change introduced the regression, it's likely Muffin to blame. May be worth filing a bug for Muffin about it.

If I remember to do so I'll try doing that tomorrow.

https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-4987080073

Have you tried stock Proton 11?
Also try deleting your prefix's compatdata and starting the game again; I had to do that after a Proton 11 update did something similar. (I had 5 FPS even in the menus)

(I'd recommend deleting compatdata when switching from Proton GE and back anyway as I've had some weird issues in the past with mixing GE and stock Proton versions with prefixes previously generated from one or the other)

For future reference, Proton Hotfix is generally for critical game compat issues. (example: THE FINALS failing to start got fixed quite a few times via this Proton version before one of the standard branches picked up the relevant fix)
It's much better to use regular Proton or Proton Experimental as-is.

Long time Linux player here, adding my data since I hit the same thing as the Feb season thread plus a placement problem.

For 2-3 years now, on different PCs and fresh installs (currently Fedora, GE-Proton but also tested on Arch, void), matchmaking keeps putting me on far away servers. I'm in Quebec. Most often AMS1, and GMEC2 (Dammam, Saudi Arabia), which I confirmed with a packet capture in game: around 1270 packets in 10s to a Google Cloud IP in Dammam.

Practice range also put me on GEN1 (Finland) at 135ms the other day. Restarting the game sometimes lands me a normal server.

What it's not: not my account (same account on Windows, same machine and network, always fine). Not my IP (same behavior through a Montreal VPN exit). Not the launcher (happens on Steam and Battle.net). Not DNS, not NIC offloads, not the driver.

I also checked the QoS/DSCP angle since Wine stubs qWAVE. The game never calls qwave or sets IP_TOS at all (WINEDEBUG=+qwave,+winsock), and a capture shows all outbound game traffic at tos 0x0. So marking is not the difference, on any OS.

My guess: whatever latency and loss numbers the client produces under Wine are wrong, and both the matchmaker and the practice instance picker trust them. I also get the 10-20% loss out from the other thread. Happy to run more tests if useful.

Replying to https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-4987080073

I am also having this issue on Cachy-proton. tried playing with __GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1 and it is still recompiling shaders every session.

https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-5076087581

I find this happens to me too and it's caused by the entire Overwatch client stalling during shader prewarm, which ends up skewing latency measurements. That said, I usually end up queuing into the correct server once prewarm is done and i actually queue for a game. (It's also significantly more reliable after the NVIDIA driver cache is hot)

https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-5126412017

You'll want to place that environment variable into /etc/environment or somewhere similar so it applies session wide if not system wide, also this is for NVIDIA GPUs only. (I forget what the AMD equivalent is)

Also once again try resetting prefix, making a note of the in-game graphics settings first so you can restore them afterward.

https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-5126412017

You didn't specify your hardware nor how you're running the game but in case you are on Nvidia and running Overwatch on DX12 as a non-Steam game (via Battle.net client) like I am, you should try defining a fixed location for the shader cache. I was having a similar issue which started about a month or two ago, the shader cache would not persist between runs.

At first I tried increasing the cache size by adding __GL_SHADER_DISK_CACHE_SIZE=10000000000 (a common suggestion nowadays, I think it's default on CachyOS) in file $HOME/.config/environment.d/nvidia-shader-cache-size.conf which raises the max size before cleanup to 10GB but the cache would still not persist across runs. So I also added __GL_SHADER_DISK_CACHE_PATH=$HOME/.cache/Battle.net %command% as a Steam launch option and that made the cache persist (create the directory first).

Also, if you set the cache to 10GB you can remove __GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1. It's been a week since my cache was invalidated by an update and right now it's at 1.7GB, well below 10GB but more than the default which is supposedly 1GB.

I still have occasional issues with disappearing models in the post-match overview and hero customization menus, but at least in game the character models are visible without having to wait for the cache to rebuild every run, which takes forever because Overwatch has an absurd amount of shaders. After you update drivers you'll need to rebuild the cache still, but you can speed up the process with this custom game preset: 929PJ. It will cycle through all maps and heroes until you leave the lobby.

[#7033 (comment)](https://github.com/ValveSoftware/Proton/issues/7033#issuecomment-5126412017)

Running OW on DX11 starts to process the shaders at the main menu, but the game is far more unstable now in DX11. So long as the game does not crash, the shaders take 15-20minutes to finish.

On DX12 the game has a more stable framerate, takes long to process the shaders and only processes them while in a match(not in the main menu). Anytime someone is on a new hero/skin it has to recompute the shader for that hero and they continue to appear invisible while in game.

The workshop mode 929PJ helps while playing on DX11 but the increased time to process the shaders in DX12 is causing the gamemode to lock up my game when it tries to change map. But I still have to do this everytime I launch the game. It seems the shader cache is being cleaned up even after increasing the shader cache size in my .conf file via __GL_SHADER_DISK_CACHE_SIZE=24000000000.

I isolated one cause of Overwatch 2's DX12 shaders recompiling across launches on a hybrid Ryzen iGPU + NVIDIA system. This is distinct from NVIDIA's cache-size limit and from first-ever shader compilation.

Environment: CachyOS, kernel 7.1.6, Ryzen 7 9800X3D (enabled iGPU), RTX 5090, NVIDIA 610.57.04, proton-cachyos-slr 11.0-20260703, VKD3D-Proton 3.1.0 build 565d695093224e3. Renderer is DX12, SM 6.7, HDR, native Wine-Wayland. Cache is in Steam's AppID path through PROTON_LOCAL_SHADER_CACHE=1.

Reproduction:

1. Start with a valid NVIDIA base cache plus a valid .cache.write generated by Overwatch.
2. Launch Overwatch with normal asynchronous VKD3D cache setup and VKD3D_DEBUG=info VKD3D_CONFIG=pipeline_library_log.
3. Overwatch creates and rapidly destroys an RTX D3D12 probe, then creates a Ryzen iGPU device, then creates the final RTX render device.

Relevant log sequence:

# preliminary RTX device
Merging disk caches.
Device teardown request received, stopping parse early.

# next device; immediately preceded by "Loaded amdxc64.dll successfully"
Write cache is invalid (hr #887e0001), nuking it.

# final RTX device
No write cache exists. No need to merge any disk caches.
D3D12 PSO count: 322017

0x887E0001 is D3D12_ERROR_ADAPTER_NOT_FOUND, so this is specifically the iGPU rejecting a cache created on the NVIDIA adapter. The first RTX teardown takes VKD3D's cancellation path, which intentionally preserves .write. The adapter-mismatch path instead reaches the common out label, which unconditionally deletes .write. All devices collide because an explicit cache directory is split by executable name only, not adapter identity.

Controlled red/green result using the same saved fixture:

• Async: the 10,555,680-byte pending write archive is deleted; the 79,185,072-byte / 322,017-PSO base remains unchanged.
• VKD3D_CONFIG=shader_cache_sync: the first RTX probe merges 42,631 new entries before teardown; the base becomes exactly 89,740,704 bytes / 364,648 PSOs. The iGPU then has no .write to delete, and the final RTX loads all 364,648 PSOs.
• Two earlier controls also merged exactly 33,856 and 138,096 pending entries. After the latter, the same D0231 six-hero set improved from up to ~65 s cold to ~5 s after a full process restart.

Current workaround:

VKD3D_CONFIG=shader_cache_sync PROTON_LOCAL_SHADER_CACHE=1 %command%

The smallest upstream correction appears to be preserving .write when validation returns D3D12_ERROR_ADAPTER_NOT_FOUND, while continuing to discard it for a genuine driver-version mismatch/corruption. A more structural alternative is adapter-scoped internal cache naming. Current code references: mismatch branch, cancellation-preserve branch, unconditional delete, and per-executable naming.

I can provide the full startup logs and cache count/hash receipts. I have not yet reproduced this exact trace on Valve's stock Proton build; the runtime tested is the current CachyOS build named above, and the cited control flow is from its exact upstream VKD3D commit.

I can provide the full startup logs and cache count/hash receipts.

Please do.