GoldSRC not drawing a window on Linux, possibly AMD GPU related

[immerohnegott]

SysInfo: steam_sysinfo.txt

(Arch Linux, AMD R7 4750U with Vega graphics, Mesa 21)

This affects me with both Half-Life and CS1.6 - probably all GoldSRC games. The issue does not appear to be system wide, as other OpenGL Steam games run without issue on the affected machine.

In trying to help another user with this issue, I discovered it was reproducible (at least with our small sample size of two). To wit, launching Counter-Strike 1.6 or Half-Life in Steam using a Linux machine AMD graphics (caveat Mesa version?) results in an hl_linux process being spawned, but no window is ever drawn. The spawned process(es) don't appear to be doing much of anything as CPU time lives in the <1% range.

The behavior is similar to https://github.com/ValveSoftware/halflife/issues/2100, but disabling GLSL shader cache via unsetting MESA_GLSL_CACHE_DIR does not resolve. Running in CLI gives no useful output that I can see (just normal gameoverlayrenderer ELFCLASS warnings):

Starting app 10
>>> Adding process 93509 for game ID 10
GameAction [AppID 10, ActionID 23] : LaunchApp changed task to WaitingGameWindow with ""
ERROR: ld.so: object '<redacted>/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
GameAction [AppID 10, ActionID 23] : LaunchApp changed task to Completed with ""
>>> Adding process 93511 for game ID 10
pid 93513 != 93511, skipping destruction (fork without exec?)
ERROR: ld.so: object '<redacted>/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '<redacted>.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
>>> Adding process 93514 for game ID 10
>>> Adding process 93517 for game ID 10
<nothing until I force stop the process>
Game removed: AppID 10 "", ProcID 93509 
Uploaded AppInterfaceStats to Steam
Exiting app 10
No cached sticky mapping in ActivateActionSet.

I cannot reproduce this on either of my systems running Linux with Nvidia GPUs, one on Arch, one on Ubuntu 20.04

It could be related to something in the Steam Runtime / how Steam itself is launching the binary - I was able to at least get the game to launch manually by copying the LD_LIBRARY_PATH out of the process' environment while running then manually executing it from CLI with an LD_LIBRARY_PATH=<copied paths> ./hl_linux -steam -game cstrike. This gave a locale warning (likely due to a bunch of other ENV being gone, it couldn't find the en_US.UTF-8 locale), but the game loaded and ran. As yet, I've been unable to find anything injected by the Steam Runtime that will cause it to fail when run manually.

I hacked an strace call into the hl.sh script to try and glean more information, I can provide that output as well if needed. It seems to hang on a futex call after loading the first set of libraries, though my strace-fu is weak. FWIW, the other user I was trying to help was running Ubuntu 20.04, also with an AMD Ryzen APU. The AMD link may be a Red Herring, but I can run it with no issues with Nvidia on two Linux machines.

[scurrvy2020]

I have this issue with my AMD machine and mesa-get. No issues running it with Intel gpu.

[chinese-soup]

Hello. My friend had the same issue a few weeks ago on Arch Linux, RX 5600 GPU. Upgrading mesa, reinstalling steam, removing Half-Life, reinstalling Half-Life, validating Half-Life, etc. - none of that worked, the process just hung just like you describe it.

However: We eventually got it to reappear again, we have tried two things and we don't know which one helped (probably the latter though)

1. First, the environment variable SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS=0 we've found in this thread https://github.com/ValveSoftware/halflife/issues/1695#issuecomment-223762011

2. Second, running Steam / just the hl_linux (or hl.sh) in Xephyr: https://wiki.archlinux.org/title/Xephyr When he ran Steam (or HL1 itself and Steam on :0 Xorg don't remember) in Xephyr the game magically appeared inside the Xephyr screen window in the default 640x480 fullscreen (the game was freshly reinstalled). When he quit HL1 & Steam & Xephyr and started Steam again on his main :0 desktop, the game then worked on :0 as well and works till this day (We've solved it by this on 22nd of May 2021).

This should still obviously be tracked down and fixed (probably some Mesa issue I guess?), but try giving Xephyr and the SDL env variable (even though it was probably the Xephyr run that fixed it) this if this fixes it for you as well.

I have yet to reproduce this on my Arch Linux + RX570 machine myself so I can't provide any more details on the hangs etc., sorry.

EDIT: I see your issue probably isn't the same one as my friend had, since we've tried to copy the environment and run everything from console etc. and the window still didn't want to spawn, like it did for you.

[immerohnegott]

@chinese-soup I see your edit, but I can at least try and replicate the behavior on my laptop after work today.

[chinese-soup]

Just posting to say I've had the same problem as my friend, and again, I've solved it with one-time Steam start in Xephyr and the game has been running fine on :0 for several days.

[Noiseko]

This is still affecting me on and off, I don't know how it sometime fixes itself or why it dies. Also arch also amdgpu 5700xt

[niobium93]

Same problem here. Disabling shader pre-caching completely in the Steam setting resolves this for me, but obviously isn't ideal.

[niobium93]

Figured out how do fix it without disabling shader pre-caching for everything. Paste this into your launch options:

env -u MESA_DISK_CACHE_SINGLE_FILE -u MESA_GLSL_CACHE_DIR %command%

Both of those environment variables need to be unset. Either one of them still breaks the game.

[namtsui]

amdgpu 6800 xt slackware linux 5.15.11 mesa 21.2.6

I experienced the same with counter-strike 1.6 not launching. The hint provided by @niobium93 with unsetting environment variables resolves this issue. Thanks.

[6yntar05]

ArchLinux Vega 7 Linux 5.16.1-zen Mesa 21.3.4 Same