search

ValveSoftware / Proton

Compatibility tool for Steam Play based on Wine and additional components
Other
24.13k stars 1.05k forks source link

Overwatch 2 (2357570) #7033

Open EpicureanGit opened 1 year ago

EpicureanGit commented 1 year ago

Compatibility Report

System Information

I confirm:

Proton_LOG=1 https://gist.github.com/EpicureanGit/17ffca725b311bd1f78cb621c47e6efe

Symptoms

My cursor doesn't align with the interface after lowering my in-game resolution from my native 4K resolution. Under my native resolution the cursor aligns with the light gray highlighted "2560 X 1440 (60)*" resolution option. 4K Overwatch 2

After I changed my monitor resolution to "1920 x 1080 (60)" I had to move my cursor to the left and up in order to highlight the "2880 x 1620 (60)" resolution option. 1080p Overwatch 2

Reproduction

In-game go to the lower right, select Menu, go to Options, and then go to Video. Then while using fullscreen display mode lower your resolution from your native resolution and apply the new settings.

ishitatsuyuki commented 6 months ago

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

E-D-W-I-N commented 6 months ago

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?)
PickMeNow commented 6 months ago

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

polluxau commented 6 months ago

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?

PickMeNow commented 6 months ago

Replying to #7033 (comment)

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

What proton version?

Proton Experimental

SopaDeMacaco-UmaDelicia commented 6 months ago

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

PickMeNow commented 6 months ago

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 :)

Ciflire commented 5 months ago

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

agurenko commented 5 months ago

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

E-D-W-I-N commented 5 months ago

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

Ciflire commented 5 months ago

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

Jafner commented 5 months ago

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.

simifor commented 5 months ago

@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 commented 5 months ago

@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.

SopaDeMacaco-UmaDelicia commented 5 months ago

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.

TerohsLab commented 5 months ago

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.

gofman commented 5 months ago

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.

slagiewka commented 5 months ago

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

And for some reason the GPU is heavily underused.

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

Any-Fuel-5635 commented 5 months ago

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.

TerohsLab commented 5 months ago

And we are crashing again even on proton 8.

agurenko commented 5 months ago

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.

Any-Fuel-5635 commented 5 months ago

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

Jelgnum commented 5 months ago

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

polluxau commented 5 months ago

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

Jelgnum commented 5 months ago

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

simifor commented 5 months ago

@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.

Jelgnum commented 5 months ago

@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.

simifor commented 5 months ago

@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 commented 5 months ago

@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 commented 5 months ago

@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 commented 5 months ago

@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

simifor commented 5 months ago

@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.

Jelgnum commented 5 months ago

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

polluxau commented 5 months ago

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

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

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

ishitatsuyuki commented 5 months ago

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.

polluxau commented 5 months ago

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

ishitatsuyuki commented 5 months ago

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.

polluxau commented 5 months ago

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

TerohsLab commented 5 months ago

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:

AngryPlayer04 commented 4 months ago

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

polluxau commented 4 months ago

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?

Jelgnum commented 4 months ago

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

AngryPlayer04 commented 4 months ago

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

TerohsLab commented 4 months ago

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.

AngryPlayer04 commented 4 months ago

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

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

TerohsLab commented 4 months ago

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.

Nanotwerp commented 4 months ago

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.

Nanotwerp commented 4 months ago

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

simifor commented 4 months ago

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.

TerohsLab commented 4 months ago

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.