Proton: libGL error: MESA-LOADER: failed to open radeonsi with Proton 5.13-1

[AwesamLinux]

System Information

• GPU: RX 5700
• GPU Driver: Mesa 20.3.0-devel
• Kernel version: 5.8.16-050816-lowlatency
• Distro version: Mint 20 (64 bit) (Cinnamon)
• Proton version: 5.13-1

Symptoms

Most games I have tested are no longer launching with Proton 5.13-1, these are games that I tried and still works for me with Proton 5.0-9.

_I think I have the same/related issue as #4278 and #4269, however those report says can't run anything but that is not the case for me, therefore I'm posting this a separate issue just in case._

I included a bunch of logs trying to launch games with Proton 5.13-1. All these games do still work for me with Proton 5.0-9 but don't launch with 5.13-1 (nothing happens). I also included some logs of games that did launch for me with 5.13-1 for comparison.

FAILED TO LAUNCH:
steam-1349960 The Ghost Train - FAIL
steam-501300 What Remains of Edith Finch - FAIL
steam-1057750 The Suicide of Rachel Foster - FAIL
steam-343710 Kholat - FAIL
steam-1122720 Sayonara Wild Hearts - FAIL
steam-752590 A Plague Tale: Innocence - FAIL
steam-826940 Maid of Sker - FAIL

SUCCESSFULLY LAUNCHED:
steam-368430 Through the Woods - SUCCESS
steam-217920 Alien Rage - SUCCESS
steam-321270 UNLOVED - SUCCESS

What I have tried:

• Verifying Proton files through steam
• Deleting the Proton folders manually, and verifying/letting Steam downloading them again.

Logs:
Logs of launching all these games with Proton 5.13-1

logs.zip
system_info.txt

Edit: System information after waiting for runtime info to be filled in:
system_info.txt

Update:
I tried now also launching a few games with the Proton 5.13 debug branch:
logs_debug.zip

I have also tried verifying the "Steam Linux Runtime - Soldier" files, it is curiously for me listed as a game not a tool (that does not seem right?)

[jaubin]

On NVIDIA blob 450.66 :

A Plague Tale : Innocence - OK

I could not try the other games.

[guglovich]

SUCCESSFULLY LAUNCHED:
Witcher 3, Bayonetta, Borderlands GOTY Enhanced, Endless space, S.T.A.L.K.E.R.: Shadow of Chernobyl, The Walking Dead

FAILED TO LAUNCH:
Remember Me (Also doesn't work with 5.0.9)
Other game - Lineage 2

[aeikum]

Looks like all of your failing logs contain this:

libGL error: MESA-LOADER: failed to open radeonsi (search paths /overrides/lib/x86_64-linux-gnu/dri:/overrides/lib/i386-linux-gnu/dri)
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open radeonsi (search paths /overrides/lib/x86_64-linux-gnu/dri:/overrides/lib/i386-linux-gnu/dri)
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open swrast (search paths /overrides/lib/x86_64-linux-gnu/dri:/overrides/lib/i386-linux-gnu/dri)
libGL error: failed to load driver: swrast
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  152 (GLX)
  Minor opcode of failed request:  6 (X_GLXIsDirect)
  Serial number of failed request:  281
  Current serial number in output stream:  280

So something is going wrong loading your GL driver from within the runtime container.

[TTimo]

@AwesamLinux please include a complete 'System Information' report - e.g. please wait for the runtime information tool section to fill in.

[AwesamLinux]

@TTimo here is the full system info:
system_info.txt

[TTimo]

On your machine, 64 bit GL drivers are not working in either the scout or soldier runtime containers (32 bit seems fine though, and LD_* runtime is generally fine also).

The steam installation is distro altered - I would recommend using official Valve packages instead (http://repo.steampowered.com/steam/), although that's not likely related to the driver problem.

[kisak-valve]

undefined symbol: drmGetDevices2 and undefined symbol: amdgpu_cs_query_reset_state2 looks interesting from the system information. Somehow the driver is picking up a variant of libdrm that's too old for that build of mesa.

[smcv]

overrides/lib/x86_64-linux-gnu/libdrm.so.2 -> /run/host/opt/amdgpu/lib/x86_64-linux-gnu/libdrm.so.2.4.0
overrides/lib/i386-linux-gnu/libdrm.so.2 -> /run/host/usr/lib/i386-linux-gnu/libdrm.so.2.4.0

pressure-vessel doesn't currently support graphics drivers or their dependencies installed outside /usr. I expect this will be the problem for @AwesamLinux.

Is this something you are deliberately still using, or something that is left over from an old installation? I notice libGLX_mesa.so.0 is still in /usr.

We cannot know whether other users who have commented have the same issue, a related issue, or something completely unrelated.

64 bit GL drivers are not working in either the scout or soldier runtime containers (32 bit seems fine though)

That'd be because the ones in /opt are 64-bit-only, so they can only break 64-bit. For 32-bit, the drivers in /usr seem to be fine.

overrides/lib/x86_64-linux-gnu/libOpenCL.so.1 -> /run/host/opt/amdgpu-pro/lib/x86_64-linux-gnu/libOpenCL.so.1

I didn't know amdgpu-pro was even still a thing.

[smcv]

Somehow the driver is picking up a variant of libdrm that's too old for that build of mesa

I think what's happening here is:

• on the host system, when we ask the OS "if I told you to load libdrm.so.2, where would you get it from?", the answer is the copy in /opt, probably because /opt/amdgpu/lib is in LD_LIBRARY_PATH or /etc/ld.so.conf or similar
• we set up the symlinks in /overrides
• there is no /run/host/opt because pressure-vessel assumes graphics drivers always come from /usr or /lib*, so the symlink in the directory in the LD_LIBRARY_PATH ends up as a broken link
• when the dynamic linker inside the container looks for libdrm.so.2, it tries the broken link, rejects it, and moves on to the next version, which is the one supplied by the container runtime (it came from Debian 10), and is too old for your graphics driver in /usr

[AwesamLinux]

@smcv I just add a PPA with recent Mesa drivers and let it install them wherever it does by default. I tried purging ppa:ernstp/mesaaco and tried it now with ppa:kisak/kisak-mesa instead, but made no difference.

However I have manually installed OpenCL from the amd-gpu-pro drivers in headless mode, so maybe that causes issues somehow (most using professional software like Blender do that, because the OpenCL provided with Mesa does not support everything).

[AwesamLinux]

Proton 5.13-1 is working for me now, thanks for the support and ideas :tada:

I uninstalled the AMD-GPU-PRO OpenCL driver that I had previously installed in headless mode. After uninstalling it and rebooting games are launching fine now with Proton 5.13-1.

So I guess the OpenCL driver somehow interferes with Proton 5.13-1 :man_shrugging:!?. I guess this could perhaps cause issues to some other AMD users too, as I think it is fairly common to install just install the AMD GPU PRO OpenCL driver for some professional apps.

Just for reference including a log, and system info of my now working setup:
steam-826940.log.zip
system_info.txt

[kisak-valve]

Let's keep this issue open for a while, at least for visibility, as it's not uncommon for users to tinker with amdgpu-pro.

[smcv]

So I guess the OpenCL driver somehow interferes with Proton 5.13-1

I think the conditions for getting this issue are:

• installs its own version of libraries that your graphics driver directly or indirectly depends on (in your case libdrm.so.2)
• puts them in the global search path that your OS uses to find libraries (I don't know exactly what the amdgpu-pro driver does, but presumably it either edits /etc/ld.so.conf or drops a file into /etc/ld.so.conf.d)
• puts them in locations that are not /usr or /lib* (in your case in /opt)

That will confuse the container runtime system that we use to give Proton 5.13 its required runtime environment (it's called pressure-vessel and is in the SteamLinuxRuntime_soldier/pressure-vessel/bin/ directory), because at the moment it assumes all libraries came from /usr or /lib*.

Installing a version of libdrm.so.2 in /opt that is outside the OS's dependency management system and putting it on the global search path is always going to be a potentially problematic thing to do, because if happens to be older than the one your OS installs in /usr, it will break dependencies in your OS.

Packages from PPAs behave more like replacements for part of the OS - there's still a risk of breaking things, but their structure tends to be a drop-in replacement rather than overlaying extra stuff over the top, and upgrading to a newer base OS will often be able to replace the PPA packages cleanly with the versions from the new base OS.

[Lepidos]

Yes I have this issue. And using amdgpu-pro... :-(
Need a step by step guide to solve this on debian.

I tried this
LD_LIBRARY_PATH=/opt/amdgpu/lib/i386-linux-gnu:$LD_LIBRARY_PATH steam but no go

[coolacid]

I'm also affected by using amdgpu-pro. Here's some notes, amdgpu-pro does the following on install:

1. Places it's dri libs in /opt/amdgpu/lib/*/dri
2. Adds 20-amdgpu.conf into /etc/ld.so.conf.d which adds above directories to the ldcache.
3. Moves the /usr/lib//dri/_dri.so files to *dri.so~
4. Adds a symlink from the original file names to the /opt/amdgpu/lib//dri/ file

Terrible work around, Delete the symlinks and ~ files from the /usr/lib dirs, and copy the files from /opt/amdgpu/lib, move the ld.so.conf file out, and run ldconfig command to rebuild the cache.

Alas, I still have problems running Among Us, but I think I'm past this problem, and gives you all some data points.