[winewayland.drv] "GameThread timed out waiting for RenderThread" (crash/freeze) in Sway

[GrabbenD]

This issue isn't specific to wine-tkg

My upstream bug report #56172 has been stale for weeks and I was hoping there's someone experienced here who can give advice on how to resolve this issue :)

Problem

• Setup: I've only been able to reproduce this issue using Wayland driver (_wayland_driver="true") with Sway 1.9.
• When: changing to a different Sway Workspace, the game process continues to run for exactly 120 seconds before freezing.
• Where: Any game like Detroit Become Human, High On Life or Cyberpunk 2077 (via Bottles).
• Clarification: audio is still played when the workspace is unfocused. However, I believe Sway doesn't render applications in unfocused workspaces (because when I return it skips a few frames to "catch up").
• Distro: Arch Linux

Stacktrace

Detroit Become Human:

LowLevelFatalError [File:Unknown] [Line: 1209] GameThread timed out waiting for RenderThread after 120.00 secs

Question

Can I somehow disable the 120 seconds timeout / is there's any proper method to resolve this issue?

[Tk-Glitch]

That log output doesn't seem to come from wine and it seems to be the game timing out, which would point to Sway handling of the window being the issue here. I assume it works fine with xwayland/winex11.drv ?

[GrabbenD]

@Tk-Glitch

Yes that's correct, I can't reproduce this with XWayland driver in WINE.

---

My apologies for the confusion, the stacktrace is different or non existent depending on which game is tested (as you guessed). The one posted above was for Detroit Become A Human.

With Cyberpunk 2077 this dialog is displayed after leaving the game in a unfocused Sway Workspace for exactly 120 seconds:

Terminal:

wine: Unhandled exception 0x80000003 in thread 794 at address 000000014000634B (thread 0794), starting debugger...

Dialog:

The program REDEngineErrorReporter.exe has encountered a serious problem and needs to close. We are sorry for the inconvenience.

More details button

It's not possible to copy the content unfortunately:

[Arastais]

Do you happen to be using an NVIDIA graphics card with the proprietary driver? This issue may not be specific to sway.

I'm not on sway (I'm on wayland GNOME), but had this issue on the native wayland driver (but not on the x11 driver) with a couple of games when I was on an NVIDIA GPU. It went away when I switched to an AMD GPU.

For me, games on the native wayland driver would basically semi-regularly but randomly freeze until I inputted something on the window (e.g. I clicked inside the game window or pressed a key). If it didn't input anything and just let it stay frozen, the game would time out after two minutes as you describe. I'd be as if the game would randomly unfocus (and thus stop rendering), even though I was playing it and wasn't alt-tabbed or anything.

Although, every now and then if I was "unlucky" it would hard freeze and no inputs would unfreeze the game - I'd have to kill the process through command line or something.

[GrabbenD]

Do you happen to be using an NVIDIA graphics card

I'm using 7900 XT and I've also been able to reproduce this with 6800 XT

@Tk-Glitch which would point to Sway handling of the window being the issue here
@Arastais I'm not on sway (I'm on wayland GNOME)

There's some Reddit posts claiming to have the same issue with KDE too

Although I know that Sway doesn't render anything inside Workplaces which are unfocused. If you play a Youtube video in one workplace and switch to another, when you come back it will show you the last rendered frame before rendering a new one

[v1993]

To repeat what I've commented on upstream bug: XWayland works this around by rendering frames once in a while even when rendering callback is not being invoked by Wayland compositor, exactly to prevent this kind of issues arising in X applications (which includes Wine under XWayland). Since Windows apps evidently also rely on rendering continuing to run at all times, Wine could fix this in its Wayland driver by also rendering frames once in a while (e.g. once per second) when app is invisible.