Proton 5.13-2 tries to use mesa/ANV before nVidia (Optimus laptops)

[austinried]

Can't seem to get any games to run with the latest Proton 5.13-2, but the 5.0-10 version seems to work. I also am having trouble finding any specific error that's being thrown, they all just seem to throw up either a full white window or transparent window and then crash with a force quit/wait dialog shortly after.

Games tried: Sekiro, Risk of Rain 2, Gloomhaven. Sekiro loads an all white window, Risk of Rain 2 and Gloomhaven load up transparent windows, although Gloomhaven does change the cursor to their custom one oddly.

Any help is much appreciated.

steam-632360.log
steam-780290.log
steam-814380.log

Computer Information:
Manufacturer: Unknown
Model: Unknown
Form Factor: Laptop
No Touch Input Detected

Processor Information:
CPU Vendor: GenuineIntel
CPU Brand: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
CPU Family: 0x6
CPU Model: 0x9e
CPU Stepping: 0xa
CPU Type: 0x0
Speed: 4100 Mhz
12 logical processors
6 physical processors
HyperThreading: Supported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Unsupported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
AVX2: Unsupported
AVX512F: Unsupported
AVX512PF: Unsupported
AVX512ER: Unsupported
AVX512CD: Unsupported
AVX512VNNI: Unsupported
SHA: Unsupported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported

Operating System Version:
Ubuntu 20.04.1 LTS (64 bit)
Kernel Name: Linux
Kernel Version: 5.4.0-56-generic
X Server Vendor: The X.Org Foundation
X Server Release: 12008000
X Window Manager: GNOME Shell
Steam Runtime Version: steam-runtime_0.20201005.0

Video Card:
Driver: NVIDIA Corporation GeForce RTX 2080 with Max-Q Design/PCIe/SSE2
Driver Version: 4.6.0 NVIDIA 455.38
OpenGL Version: 4.6
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 143 Hz
VendorID: 0x10de
DeviceID: 0x1e90
Revision Not Detected
Number of Monitors: 1
Number of Logical Video Cards: 2
Primary Display Resolution: 1920 x 1080
Desktop Resolution: 1920 x 1080
Primary Display Size: 13.54" x 7.64" (15.51" diag)
34.4cm x 19.4cm (39.4cm diag)
Primary Bus: PCI Express 16x
Primary VRAM: 8192 MB
Supported MSAA Modes: 2x 4x 8x 16x

Sound card:
Audio device: Realtek ALC298

Memory:
RAM: 15910 Mb

VR Hardware:
VR Headset: None detected

Miscellaneous:
UI Language: English
LANG: en_US.UTF-8
Total Hard Disk Space Available: 273437 Mb
Largest Free Hard Disk Block: 202662 Mb

[kisak-valve]

Hello @austinried, let's treat this as a Pressure Vessel issue with Steam Linux Runtime - Soldier until there's a stronger indication that the issue is elsewhere.

Starting with Proton 5.13, Proton is run on top of the Steam Linux Runtime - Soldier container environment and that's setup by Pressure Vessel.

What I suspect is happening here is that the games are using the first Vulkan driver the Vulkan loader gives them and they end up getting handed the Intel driver first in the container environment, before the nVidia Vulkan driver. You should be able to test this hypothesis by temporarily disabling mesa/anv with something like sudo mv /usr/share/vulkan/icd.d/intel_icd.x86_64.json /usr/share/vulkan/icd.d/intel_icd.x86_64.json.disabled and/or sudo mv /usr/share/vulkan/icd.d/intel_icd.i686.json /usr/share/vulkan/icd.d/intel_icd.i686.json.disabled. That would leave the nVidia driver as the only working option for the game to pick up.

If that helps, it confirms that there's an issue with using mesa/anv when the system is configured to exclusively use nVidia's driver.

[austinried]

Yep that looks like the issue, after renaming both of those files all three games start up and run fine.

[austinried]

Couple updates on this problem:

• The issue persists with Proton 5.13-3
• The issue also occurs when I am in NVIDIA On-Demand mode instead of performance mode

I switched to on-demand mode today because of another issue where I wasn't getting 144hz display and instead getting 60hz, and that apparently fixes it, but noticed that even if I had launched steam using the dedicated graphics option, Hades was still getting very low framerates. Only renaming the intel driver files actually forces it to run on the nvidia hardware. Other games noted above still crash as well unless the intel files are renamed.

[smcv]

Please could you show us a log of what pressure-vessel is thinking, and exactly what happens? You can do this without involving Proton (which should make things a bit simpler) like this:

cd /path/to/SteamLinuxRuntime_soldier
PRESSURE_VESSEL_VERBOSE=1 ./run -- steam-runtime-system-info --verbose 2>&1 | tee container.log

and then send container.log as a gist. You can edit/censor the log if there's anything in it that you consider private, as long as it's obvious where it has been edited, for instance replacing your username with REDACTED.

The SteamLinuxRuntime_soldier directory will be in one of your Steam libraries. The most likely place is ~/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier if you haven't reconfigured the installation path.

Also please show us the full system information (Help -> System Information in Steam), after waiting for the diagnostic tools to finish thinking about what drivers you have. Again, you can edit/censor it if you need to, and please send it as a gist.

[austinried]

Just to clarify @smcv does it matter if I gather these logs with the mesa/anv driver files disabled, and also would you like me to be in performance mode or on demand mode?

[kisak-valve]

We definitely would want the same environment as when you see the issue. Please re-enable mesa/ANV when testing. I'm not sure it matters between the two modes, since you saw an issue with both, just make it clear which you used.

[austinried]

Alright here you go, these were taken in performance mode with mesa/anv enabled:

Steam System Information: https://gist.github.com/austinried/dffd510b8e6d266bd840f4c606235f59
conatiner.log: https://gist.github.com/austinried/20b52de9208d0e2999546504a1a7d754

[smcv]

Steam System Information: https://gist.github.com/austinried/dffd510b8e6d266bd840f4c606235f59

This says an i386 vulkaninfo on the host is also trying to use Intel:

  "architectures" : {
    "i386-linux-gnu" : {
        "x11/vulkan" : {
...
          "renderer" : "Intel(R) UHD Graphics 630 (CFL GT2)",
          "version" : "1.2.131 (device 8086:3e9b) (driver 20.0.8)",

but an x86_64 vulkaninfo on the host gets NVIDIA, which I assume is what you wanted to happen:

    "x86_64-linux-gnu" : {
...
      "graphics-details" : {
        "x11/vulkan" : {
...
          "renderer" : "GeForce RTX 2080 with Max-Q Design",
          "version" : "1.2.142 (device 10de:1e90) (driver 455.152.0)"

I think this means that if you ran 32-bit Vulkan or DXVK games without using the container (e.g. Proton 5.0) they would use Intel, but if you ran 64-bit Vulkan or DXVK games without using the container, they would use NVIDIA. Does that match your experience?

OpenGL seems to be using the NVIDIA driver in both cases.

[kisak-valve]

The user @nuno1212s saw the same behavior with an AMD + nVidia setup at ValveSoftware/Proton#3521 (comment).

[FeralBytes]

I would just like to note the fix above enabled Proton 5.13.3 to work on my NVIDIA Optimus Laptop while playing Ark Survival Evolved.

[MEJacoby529]

I would just like to note the fix above enabled Proton 5.13.3 to work on my NVIDIA Optimus Laptop while playing Ark Survival Evolved.

Same for me, with Borderlands 3!

[smcv]

the fix above

Removing the .json files for the Intel driver is a workaround, rather than being a fix.

There was a bug in how the container set up Vulkan layers, which accidentally disabled the Mesa device selection layer (and possibly some NVIDIA layers, depending on precisely how they work). That bug might have been part of the root cause for selecting the wrong graphics card. The fix for that missed the boat for the current beta, but should be in the next beta.

Multi-GPU device selection in Vulkan is fairly complicated, so it's entirely possible that there is more than one root cause that triggers the same symptoms.

[DonKatsu]

I've got a dedicated AMD GPU and Intel iGPU, but I have this problem now after doing a fresh install of Fedora 34 KDE.
I had Mesa 20.3.5 before, and 21.0.3 now. I'm still using x11.

On Fedora 33 KDE, all versions of Proton always used my R9 280 without any configuration needed.
After the fresh install of 34, Proton 5.13-6 and 6.3-2 use my Intel iGPU instead. 5.0-10 and below use the AMD GPU as expected.
Renaming the intel_icd.*.json files or using DRI_PRIME=1 both work in making my AMD GPU get picked instead.
I have applied the boot flag for amdgpu.si support, of course. Native Linux games use the AMD GPU without tweaks applied.
My system information.

[luca-s]

Just an update since I participated on this issue for some time. I have recently started using Steam again and the issue is solved, the games run fine. Is the new proton or the new runtime? I don't know but it works. Thanks!

[Guite]

Confirmed: reverted the workaround (renamed intel_icd files) and things still seem to work like a charm.

[smcv]

@austinried Are you still having this issue?

If other people are still having this issue, it is probably best if each issue reporter other than @austinried opens a separate issue with full information about their system (see https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information), what works, what doesn't work, and whether there was a recent change that triggered the problem.

[smcv]

Is the new proton or the new runtime? I don't know but it works.

Changes that make this work, or that make it stop working, could be in any of:

• a Proton component (DXVK is probably the most important one)
• the pressure-vessel container runtime launcher (the pressure-vessel row in SteamLinuxRuntime_soldier/VERSIONS.txt)
• the container runtime itself (the soldier row in SteamLinuxRuntime_soldier/VERSIONS.txt)
• your operating system's graphics drivers (major components: glvnd, libvulkan, Mesa, NVIDIA driver, libdrm, kernel)
• your operating system configuration

which is why we ask for so much information. This is not a simple topic!

[austinried]

@smcv I've recently updated my OS to Ubuntu 21.04, and switching RoR2 and Sekrio to the latest Proton version (6.3-5) it looks like the problem is resolved for me now (after I reverted the "fix" of disabling those intel driver files). I'm running in on-demand mode and it appears I don't even have to launch Steam with dedicated graphics, the games are picking up and using Nvidia graphics either way.

[kisak-valve]

Closing as resolved.

If anyone is seeing a similar issue, please open a new issue report with all the information requested at https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information.

[CanYooSeeM3]

Still an issue as of now. Will test the methods mentioned above.

Just tested moving the intel files. No affect, still don't run.

I'm currently using Debian on my laptop, using the method of using the Nvidia GPU as the Primary GPU due to being the only working method for me in having the HDMI work.

[meatsink]

This issue still happens with Yakuza Kiwami. Another workaround I found is setting DXVK_FILTER_DEVICE_NAME="NVIDIA" %command%. It matches on substrings, so you don't have to enter the full GPU name as long as it matches with a device in vulkaninfo.
https://github.com/doitsujin/dxvk#device-filter
edit: seems like someone already mentioned this but it's hidden
#312 (comment)

[Woazboat]

This issue still happens with Yakuza Kiwami. Another workaround I found is setting DXVK_FILTER_DEVICE_NAME="NVIDIA" %command%.

Same for Borderlands 3 on my laptop. Adding the device filter worked for me.

[smcv]

I'll repeat this for the people commenting on this closed issue:

If anyone is seeing a similar issue, please open a new issue report with all the information requested at https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information.

As I said before, multi-GPU device selection in Vulkan is complicated, and there is probably more than one root cause that triggers the same symptoms. We want to make this work better, but we cannot do anything with "the issue still happens": to be able to improve anything, we need enough information to be able to see why the issue still happens. The most important thing is to collect one complete set of information and logs without using any special workarounds, in the situation that should work but doesn't.

If you have a workaround, it's also helpful to collect a second set of information and logs with the workaround in place, so that we can compare (but please make it as obvious as possible which set is which).