Proton
Proton copied to clipboard
ValveSoftware
Guild Wars 2 (1284210)
Compatibility Report
- Name of the game with compatibility issues: Guild Wars 2
- Steam AppID of the game: 1284210
System Information
I've been able to reproduce the problem on two separate systems:
- GPU: RTX 3090
- Driver/LLVM version: Nvidia 525.60.11
- Kernel version: 5.19.0
- Link to full system information report as Gist:
- Proton version: Proton Experimental
- Steam Deck running both the Client- and System-Beta
- Proton version: Proton Experimental
I confirm:
- [ ] that I haven't found an existing compatibility report for this game.
- There is an existing compatibility report, but it's closed
- [x] that I have checked whether there are updates for my system available.
Proton Log with the issue: steam-1284210.log Proton Log from a few days ago, when the game was working fine: steam-1284210.log
Symptoms
The game doesn't launch anymore. It's shown as running in Steam, but the launcher never appears. This issue has only appeared in the bleeding edge-branch a few days ago, but is now also occuring in the regular Proton Experimental-branch.
The line 00c0:00c4:err:sync:RtlLeaveCriticalSection section 00007FF941E4CA60 is not acquired is repeating in the logs, so I guess that has something to do with it.
Reproduction
- Launch the game
- Nothing happens
I can confirm, the game appears as running on steam but the launcher never appears. It was introduced in a recent update of proton experimental. The problem does not occur in proton 7.0-6 nor in proton hotfix
Here is the system info
I confirm, but it should by fixed on https://github.com/ValveSoftware/wine/releases/tag/experimental-wine-7.0-20230220b please try with this version
Can confirm, the launcher starts again with the latest Proton experimental (which is presumably the version linked above).
There are two other bugs with GW2, which were originally filed against upstream wine before GW2 was on Steam, but deserve a mention here since they also show up on Proton:
- Can't swap weapons with the default controls on a German keyboard (https://bugs.winehq.org/show_bug.cgi?id=52174)
- Mouse cursor turns invisible on the launcher window until it moves over an interactable element (https://bugs.winehq.org/show_bug.cgi?id=40300)
Can confirm that the game runs again with the current bleeding edge version. Thanks! :)
- Can't swap weapons with the default controls on a German keyboard (https://bugs.winehq.org/show_bug.cgi?id=52174)
I've come across this issue a few times, but I'm not sure if Proton can fix it. It exists because the ^-key is handled as a dead key in your keyboard layout. You can work around this issue by choosing German (no dead keys) as a keyboard layout in your system settings.
GW2 works just fine with dead keys on Windows, so I don't immediately see why Proton would be unable to fix it. Switching to German (no dead keys) is an interesting workaround I wasn't aware of, but unfortunately it breaks, you know... typing. Gonna stick to my current workaround of binding weapon swap to Q instead.
for me GW2 launcher gets stuck at "Initializing..." -phase, with both version of proton (7.0-6 and experimental-bleeding)
here is the log steam-1284210.log
my system spec:
.;ldkO0000Okdl;.
.;d00xl:^''''''^:ok00d;. OS: openSUSE MicroOS
.d00l' 'o00d. Kernel: x86_64 Linux 6.1.12-1-default
.d0K^' Okxoc;:,. ^O0d. Uptime: 3h 21m
.OVVAK0kOKKKKKKKKKKOxo:, lKO. Packages: Unknown
,0VVAKKKKKKKKKKKKK0P^,,,^dx: ;00, Shell: bash 5.2.15
.OVVAKKKKKKKKKKKKKk'.oOPPb.'0k. cKO. Resolution: 3072x1728
:KVAKKKKKKKKKKKKKK: kKx..dd lKd 'OK: DE: KDE 5.103.0 / Plasma 5.27.0
lKlKKKKKKKKKOx0KKKd ^0KKKO' kKKc lKl WM: KWin_wayland
lKlKKKKKKKKKK;.;oOKx,..^..;kKKK0. lKl GTK Theme: Breeze [GTK2], [GTK3]
:KAlKKKKKKKKK0o;...^cdxxOK0O/^^' .0K: Icon Theme: Papirus-Dark
kKAVKKKKKKKKKKKK0x;,,......,;od lKP Disk: 16T / 21T (75%)
'0KAVKKKKKKKKKKKKKKKKKK00KKOo^ c00' CPU: AMD Ryzen 7 5700G with Radeon Graphics @ 16x 4.3GHz
'kKAVOxddxkOO00000Okxoc;'' .dKV' GPU: NVIDIA GeForce RTX 3060 Ti
l0Ko. .c00l' RAM: 5594MiB / 15779MiB
'l0Kk:. .;xK0l'
'lkK0xc;:,,,,:;odO0kl'
'^:ldxkkkkxdl:^'
- Can't swap weapons with the default controls on a German keyboard (https://bugs.winehq.org/show_bug.cgi?id=52174)
This also happens with an ANSI keyboard on Portuguese (english int layout) locale, my workaround is to switch to english.
I have the issue that every time I launch the game, I get the Processing Vulkan shaders window:
It happens literally after every start of the game, and lasts for around a min. I know that that window should pop up after gpu driver update, but it keeps appearing every single time even when I haven't updated my drivers.
I use Proton Experimental Bleeding Edge, Mesa-git
./o. smokus@smokus-linux
./sssso- -------------------
`:osssssss+- OS: EndeavourOS x86_64
`:+sssssssssso/. Host: MS-7C91 (2.0)
`-/ossssssssssssso/. Kernel: 6.3.0-rc3-273-tkg-cfs
`-/+sssssssssssssssso+:` Uptime: 12 hours, 20 mins
`-:/+sssssssssssssssssso+/. Packages: 1516 (pacman)
`.://osssssssssssssssssssso++- Shell: zsh 5.9
.://+ssssssssssssssssssssssso++: Display 1: 1920x1080 @ 144Hz
.:///ossssssssssssssssssssssssso++: Display 2: 2560x1440 @ 170Hz
`:////ssssssssssssssssssssssssssso+++. DE: KDE Plasma 5.27.3
`-////+ssssssssssssssssssssssssssso++++- WM: KWin (Wayland)
`..-+oosssssssssssssssssssssssso+++++/` WM Theme: Breeze
./++++++++++++++++++++++++++++++/:. Theme: Breeze (Dark) [QT], Breeze [GTK3/4]
`:::::::::::::::::::::::::------`` Icons: breeze-dark [QT], breeze-dark [GTK2/3/4]
Font: Cantarell (11pt) [QT], Cantarell (11pt) [GTK2/3/4]
Cursor: Bibata-Modern-Ice (24px)
Terminal: konsole 22.12.3
Terminal Font: MesloLGS NF (12pt)
CPU: AMD Ryzen 9 5900X (24) @ 4.950195 GHz
GPU: AMD Radeon RX 6800 XT
Memory: 7.50 GiB / 31.19 GiB (24%)
Disk (/): 916 GiB / 1 TiB (67%)
Disk (/mnt/ExternalHDD): 1 TiB / 4 TiB (30%) [Removable]
Locale: en_US.UTF-8
Edit: Nevermind, game bug that happens when shadow quality is set to ultra.
Got some misrendering in one specific location. It's a dark room with a light in the middle. Supposed to look like this:
For me the lighted area is very blocky instead of being a nice circle:
Location: Super Adventure Box: World 2 Zone 1: Hidden Room 7 (Associate of Secrets, World 2: Does the log have other secrets?). Using Proton Experimental (non-BE) with Mesa 23.0.1 on an AMD R9 390. DX9 renderer: broken with dxvk; broken with wined3d DX11 renderer: broken with dxvk; game crashes on start with wined3d
My attempts to create an apitrace haven't been fruitful since it's impossible to get there with 6fps. Maybe someone with more powerful hardware has better luck. Can anybody try to reproduce on Windows to rule out a game bug? A textual guide on how to get there: https://wiki.guildwars2.com/wiki/Rapids#Checkpoint_7_to_Checkpoint_8 Video guide on how to get there: https://youtu.be/UWyjrPp3KN8?t=610
Unfortunately Super Adventure Box is a seasonal festival and will only be available until April 18 this year (10 days from now).
Hello @LingMan, you might have better luck getting a renderdoc capture instead of an apitrace and file a bug report with mesa for the video driver devs to ponder.
Thanks for the pointer, @kisak-valve. Had a nice testing session with @Blisto91. Turns out to be a game bug that happens when shadows are set to ultra. Same behaviour on Windows.
Replying to https://github.com/ValveSoftware/Proton/issues/6547#issuecomment-1439552278
okay I found the solution for my MicroOS issue or more exact SELinux issue
apparently I need to run this command: sudo setsebool selinuxuser_execmod 1 to get the game run and other (mmo) games that had the same issue
more about it here: https://en.opensuse.org/Portal:MicroOS/Desktop#Steam_Proton,_Bottles,_WINE,_Lutris,_Android_Studio_emulator_not_working_from_flatpaks
There is this odd issue were the game client seems to stop downloading randomly
@SViN24 I've seen that only once and it was shortly after a patch release (just like it is right now), so that's probably a server issue on Anets end.
So I think i have come across another small compatibility issue but only on the steam deck . Sometimes an input will get stock and keep repeating over and over again blocking any other aside from movement from taking palace. For example sometimes it will be one of the skills for example 1 you will see the skill flashing like if you where tapping on the key but not actually being executed in the game. Only way I have found to get back to normal is to return to the chart selection screen and goo back in. I'm running it on proton 8.1 on the steam deck. I have yet to try experimental.
Sorry if this not the best place to report this issue.
Should Guild Wars 2 be processing vulkan shaders every time it loads? Or is this the processing shaders bug? (On proton 8.02)
This game's launcher always acted up on Steam Deck, but I feel like it has gotten worse over the last few months:
System Information
- Steam Deck running both the Client- and System-Beta
- Proton version: Proton Experimental - bleeding edge
Symptoms
Displaying the launcher, which isn't very demanding, causes massive stuttering, especially when it's idle (not downloading patches). The stutter is system-wide, it's almost impossible to open up the Steam menu or even just move the cursor. After the game client has been launched, the stutter is gone. The issue seems to only exist in gaming mode, so it might be an issue related to gamescope?
I've created a proton log in which I've only started the launcher without launching the game itself: steam-1284210.log.
Reproduction
- Launch the game on Steam Deck in Gaming Mode
- (optional) Wait for updates to finish; the problem becomes far worse once the launcher is idle
- Take a look at your FPS graph, as it rather shows seconds per frame instead of frames per second
I'm unable to login to the launcher on the Steam Deck, as it loses fps and then freezes up and requires a hard reset. steam-1284210.log
The launcher runs perfectly fine on my desktop (archlinux, swaywm) in and out of gamescope. No issues. Only getting the problem on the Steam Deck.
The issue happens in both Stable and Beta channels, in Preview I can login and get past the launcher, but the fps is ~10fps. I'm unable to use the Preview channel as it likes locks my GPU frequency to 200MHz and a max of 1040MHz (doesn't scale how it should).
Steam Deck Information
- System Update Channel: Beta
- OS Version: 3.4.11
- OS Build: 20231005.1
- Proton Experimental
UPDATE: Steam Deck just got an update, it no longer needs a hard reset but the fps is basically 0 and very very unresponsive (May as well hard set instead of waiting for it to load, its that slow). This effects the entire system unless the launcher is closed. If I enabled the box for auto-play in the launcher it launches the game. The game seems to run fine but the memory clocks like to stay at 200MHz and a max of 1040MHz now.
If it fails to -autologin I'm unable to press "Login".
Steam Deck Information
- System Update Channel: Beta
- OS Version: 3.5.5
- OS Build: 20231116.2
- Proton Experimental
1. Launcher takes 1m20s to show up with Proton 8
This is regressed between Proton 7 and Proton 8. On Proton 7 it takes ~20s for the launcher to appear and be interactable. On Proton 8 this takes 1m20s on my system. I noticed when Proton 8 came out originally but pinned Guild Wars 2 to Proton 7 and forgot about it. Confirmed still present on the current Proton Experimental. Vanilla Wine 8.21 (with or without dxvk) does NOT have this problem.
Similar to other reports above there's system-wide stuttering while waiting for the launcher to appear. Although that briefly happens with Proton 7 and vanilla Wine as well, just not as long.
2. Can't set personal marker on the mini map
Alt + Left clicking on the mini map should place a personal waypoint () on the map. Instead nothing happens. Tested with Proton 7 and with Proton 8 Experimental. The marker does appear correctly with vanilla Wine 8.21.
Edit 2024-02-07: Turns out the marker appears just fine in a KDE session, but doesn't work in my standard Cinnamon session.
System Information: https://gist.github.com/LingMan/45ed43ceee831550c604dfb583219c75 Steam Runtime Diagnostics: https://gist.github.com/LingMan/af1852e3d7d66ef56e9f2207dcff0ada
Hello @LingMan, please add PROTON_LOG=1 %command% to the game's launch options, reproduce the regression, and attach the generated $HOME/steam-$APPID.log to this issue report as a file. (Proton logs compress well if needed.) Also, please copy your system information from Steam (Steam -> Help -> System Information) and the contents of Steam Runtime Diagnostics from Steam (Steam -> Help -> Steam Runtime Diagnostics) and put them in a gist, then include a link to the gist in this issue report.
@kisak-valve Right, sorry for not including that in the first place. I've edited my earlier post to include all of that info.
@LingMan I'm getting the same launch time on Proton 7.0 and Proton 8.0 -- I'm assuming you are timing the time from clicking Play on Steam to the launcher appearing and the "Play" button being usable and purple? I let the game finish downloading completely before testing the launch times as I'm assuming you have the game fully downloaded?
Could you please get a log from the Proton 7.0 launch for us to compare to the 8.0 log?
@alasky17 Thank you for looking into it! Yes, I'm timing from clicking the Play button in Steam to the launcher being fully loaded. The Play button in the launcher being purple is a good enough approximation for "fully loaded" as I've ignored any attempts that would process Vulkan shaders or download an update.
There are really only two phases that take a long time.
- There's no window at all for the first 50-60s with Proton 8. This phase takes ~20s on Proton 7.
- Then there's a short phase where the laucher checks for updates to itself. There's a relatively empty launcher window with only the text "Downloading 0%" or something to that effect. That only lasts maybe 1-2s on both Proton 7 and 8.
- Then the launcher shows an empty window with the text "Initializing...". This takes about ~20s on Proton 8 but only 2-3s on Proton 7.
@LingMan Thanks for the quick response! As a heads up, it may be a bit before we get a chance to look at this 😅
That's fine, pinning to Proton 7 has been a good enough workaround for the better part of the last year (😅) and continues be one for now. And with the holidays coming up: Merry Wintersday! :christmas_tree:
I was going to test GW2 again, with gamescope being updated to 3.13.19-1 for this bug, but when I went to go launch GW2 with gamescope the launcher loads but then hangs indefinitely on "initialising..." with btop showing this:
- PROTON_LOG=1: steam-9602761796817518592.log
- Launch Options: PROTON_LOG=1 gamescope -w 3840 -h 1800 -W 3840 -H 1800 -f -- %command%
I have tried with different proton compatibility and its the same result all round when launching with gamescope.
- GE-Proton8-25: Hangs indefinitely on "initialising..."
- Proton Experimental: Hangs indefinitely on "initialising..."
- Proton 8.0-4: Hangs indefinitely on "initialising..."
- Proton 7.0-6: Hangs indefinitely on "initialising..."
The game launches fine without using gamescope and other games launch fine using gamescope.
I'm not sure when this started as I haven't played GW2 in a while.
System Information
- OS: Arch Linux
- WM: sway version 1.8.1
- GPU: AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 18.0.0, DRM 3.54, 6.6.7-arch1-1)
- GPU Driver: 4.6 Mesa 24.0.0-devel (git-30faa7a483)
- Gamescope Version: 3.13.19-1
EDIT: I've tried running Gw2-64.exe inside a gaming bottle in bottles using wine-ge-proton8-25, "Gamescope" enabled with the same resolution settings and fullscreen, but I get the same result.
EDIT-2: This also happens on the Steam Deck. Making GW2 unplayable unless you "Switch to Desktop" and launch without gamescope.
Gamescope is now working with GW2 on both my desktop and Steam Deck.
Used GE-Proton8-25 and Proton Experimental.
Desktop System Information
- OS: Arch Linux
- Kernel: 6.6.8-arch1-1
- WM: sway version 1.8.1
- GPU: AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 18.0.0, DRM 3.54, 6.6.8-arch1-1)
- GPU Driver: 4.6 Mesa 24.0.0-devel (git-551924aa87)
- Gamescope Version: 3.13.19-1
Steam Deck System Information
- OS Version: 3.5.11
- OS Build: 20231213.2
- Kernel Version: 6.1.52-valve10-1-neptune-61
- GPU: AMD AMD Custom GPU 0405 (vangogh, LLVM 15.0.7, DRM 3.54, 6.1.52-valve10-1-neptune-61)
- GPU Driver: 4.6 Mesa 23.1.3 (git-3138303bd3)
Never mind just ran into the same problem again, seems like it happens infrequently.
Has the 6.6 kernel changed how memory and vram is handled? I'm having a strange issue with swap for the past few weeks. With the holidays and infrequently gaming during them, I'm not exactly sure when it started happening.
System Information
- GPU: Nvidia 1050ti
- Video driver version: nvidia 545.29.02
- Kernel version: 6.6.8
- Link to full system information report as: https://gist.github.com/garpu/0a645535faffac75612c2270bb050ace
- Proton version: 8.0-4
If I play for a long time (about an hour or so), I noticed when I load a different area or exit, my swap usage will go up, while I'll still have 6-7GB of system RAM available. Eventually if I don't clear the swap and restart the game, it will slow things down and keep eating swap. (I don't think I've noticed it beyond 1GB swap.)
I've noticed this with other games using dxvk (Fallout New Vegas), but to a lesser extent. I can play Vampire survivors while watching youtube videos and no problems.
I started a discussion over on LQN with the slackware forum, in case it was a regression there: https://www.linuxquestions.org/questions/slackware-14/maybe-issue-with-swap-and-the-6-6-kernel-4175732315/ (It has more details about memory useage and an nvidia-smi dump while it was happening.)
OK...little more testing. I don't see it on anything other than dxvk games through proton. (I can watch youtube videos and play Vampire Survivors at the same time.) I tried the beta steam client, and it still happens. I've also tried Proton-GE. I've upgraded my kernel to 6.6.9. I don't know if this is specifically a Guild Wars 2 issue, though. Should I report it on the steam for linux github, instead? I noticed today that my swap went up when loading a new area, and I still had roughly 2GB of VRAM left and 6-7 system RAM. Any ideas what I should try next? (I even cleaned the dust out of my computer, in case that were impeding performance.)
ETA: adjusting vm_swappiness seems to have fixed the issue for now. I'm still unclear as to what changed to produce this.