Trying to use iGPU instead of dGPU to run games with Proton doesn't work.

[segvee]

Hi,

I have a laptop with a dedicated video card but for older games or games that don't require that much power I'd like to use the integrated video card instead of the dedicated one.

The processor is a i7-11800H which has a , glxinfo reports Mesa Intel(R) UHD Graphics (TGL GT1). The mesa version is 4.6 (Compatibility Profile) Mesa 21.2.1 - kisak-mesa PPA.

Now whenever I try to run a game with the dedicated video card I just set

__NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=nvidia %command%

in the launch options for that game and it works fine. In some native Linux games like X4 you can chose the video card from the options menu and for most other native Linux games I just don't set launch options at all and it works fine using the integrated video card.

Unfortunately that does not seem to work with Proton games, e.g. with Noita. I started the game with just PROTON_LOG=1 %command% and tried the following versions of Proton: Experimental, 6.3-5 and 5.13-6. These are also attached here, in that order. steam-881100_proton_experimental.log steam-881100_proton_6.3-5.log steam-881100_proton_5.13-6.log

[kisak-valve]

Hello @segvee, I expect that this is a known (Intel -> nVidia) video driver compatibility issue when the system is configured to run the X session on the nVidia GPU and mesa/ANV can not render to that due to a lack of dri3 support in nVidia's driver (Called nVidia Performance Mode by some configuration tools). I don't think this is a Proton-specific issue, so I've transferred this issue to the steam-runtime issue tracker.

In case I'm wrong, please give https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information a read and share the requested information.

[smcv]

Unfortunately that does not seem to work with Proton games

Please define "doesn't work"? There are two major ways it might "not work" - the game might use the dGPU even though you wanted the iGPU, or the game might not run at all. From your logs it looks as though it's not running at all (crashing on startup).

Steam tries to select the dGPU, and DXVK in Proton also tries to select a dGPU even if an iGPU is the default (to avoid issues where the iGPU either is too slow to be usable, or doesn't support Vulkan at all), so trying to force games onto the iGPU is definitely a "swimming upstream" situation.

[segvee]

Hello @segvee, I expect that this is a known (Intel -> nVidia) video driver compatibility issue when the system is configured to run the X session on the nVidia GPU and mesa/ANV can not render to that due to a lack of dri3 support in nVidia's driver(Called nVidia Performance Mode by some configuration tools). I don't think this is a Proton-specific issue, so I've transferred this issue to the steam-runtime issue tracker.

In case I'm wrong, please give https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information a read and share the requested information.

Hey, I just tested Noita with the other Proton versions. Whereas with the one mentioned in my original post it didn't start I tried 5.0-10, 4.11-13, 4.2-9 and 3.16-9 and they seem to work - by that I mean that the game starts, I haven't tested it further. With 3.7-8 the game starts (i.e. a window pops up whereas with experimental, 6.3-5 and 5.13-6 it didn't do that at all) but then the window closes.

Furthermore I am running the X server on the integrated video card i.e. I am using NVidia's on-demand mode. Is this still possibly a Steam runtime issue and should I follow the instructions you provided? I will gladly do that if that is the case though I am afraid I won't be able to do that until monday.

Unfortunately that does not seem to work with Proton games

Please define "doesn't work"? There are two major ways it might "not work" - the game might use the dGPU even though you wanted the iGPU, or the game might not run at all. From your logs it looks as though it's not running at all (crashing on startup).

Steam tries to select the dGPU, and DXVK in Proton also tries to select a dGPU even if an iGPU is the default (to avoid issues where the iGPU either is too slow to be usable, or doesn't support Vulkan at all), so trying to force games onto the iGPU is definitely a "swimming upstream" situation.

Sorry, by doesn't work I mean the game doesn't start in the sense that the main window doesn't even appear. As mentioned above, though, it works with other versions of Proton. I don't think it tries to run on the dGPU. I switched back to Proton Experimental and was monitoring nvidia-smi and Noita didn't appear as a process while it was starting. So I think it tries to use the iGPU and the game does not run at all.

I didn't know that Steam tries to select the dGPU. I thought it uses the integrated video card by default and you have to specifically use __NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=nvidia %command% in order to run something on the dGPU.

For future reference: if a game uses the dGPU even though I didn't use the command above is there a way to force the usage of the iGPU? Maybe this could come in handy sometime.

[kisak-valve]

Proton started using the Steam Linux Runtime - Soldier container environment with Proton 5.13. Since Proton 5.0 and earlier behaves better for you, that makes it more likely that there's an issue with the container environment. There's no particular hurry to gather the extended diagnostic information, we just won't make much progress in the mean time.

[smcv]

I didn't know that Steam tries to select the dGPU

It has PrefersNonDefaultGPU=true and X-KDE-RunOnDiscreteGpu=true in the .desktop file. Whether that does anything or not depends on your desktop environment and its version number, and on how you run Steam.

if a game uses the dGPU even though I didn't use the command above is there a way to force the usage of the iGPU?

For native Linux games, this might work:

__NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=non_NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=mesa %command%

(Or it might be better with __NV_PRIME_RENDER_OFFLOAD=0, I'm not sure.)

However, DXVK second-guesses the rest of the driver stack and tries to select a dGPU anyway: https://github.com/ValveSoftware/dxvk/commit/40b52758e3240700b061dd9650986a1312c9099f

so that might not work.

Setting DXVK_FILTER_DEVICE_NAME (see https://github.com/ValveSoftware/dxvk/) might also help to force DXVK to do what you want.

[Leopard1907]

Replying to https://github.com/ValveSoftware/steam-runtime/issues/449#issuecomment-902745772

Prime Render Offload var needs to be enabled to use __VK_LAYER_NV_optimus=non_NVIDIA_only

So what you have specified above with

__NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=non_NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=mesa %command%

does work for both native and Proton games, DXVK-vkd3d doesn't try to use dgpu still when combo above is used.

[segvee]

Hey, I managed to gather the needed information. Hopefully this will be helpful!

slr-app881100-t20210821T200107.log steam-881100.log system_information.txt VERSIONS.txt

[edit] Another thing that I have noticed, which I thought was because I am using Ubuntu 21.04 instead of Debian at the moment, is that when I started a game the whole desktop would freeze. I could still move the mouse but the clock in KDE would stop and I could not interact with anything. That is true for every game I tried to start using Proton. But now that I've switched to Proton 5.0 for Noita that issue does not appear anymore. It only appears when I use versions of Proton using the Steam Linux Runtime - Soldier container environment, so Proton 5.10, 6.3 and experimental. When I use Proton 5.0 the game starts a lot more quickly and there are no freezes.

[smcv]

Another thing that I have noticed, which I thought was because I am using Ubuntu 21.04 instead of Debian at the moment, is that when I started a game the whole desktop would freeze. I could still move the mouse but the clock in KDE would stop and I could not interact with anything

Are you sure it's that, and not this, which would also match those symptoms?

• On startup, the game (or maybe a Proton component) allocates a fullscreen window
• The initial contents of that window are effectively a screenshot of your KDE session, including the clock stopped at its initial value
• Clicking anywhere on that window doesn't do anything because the game hasn't fully started yet
• While the game is starting up, no more frames are drawn
• When the game draws a frame for the first time, the contents of that window are replaced by whatever the game draws

You might be able to tell the difference by using Alt+Tab to switch between windows, or using a equivalent of GNOME's Overview if KDE/Plasma has one.

[smcv]

19856.410:00c8:00cc:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\winex11.drv" at 00007F1DE4E00000: builtin
19871.343:0020:0024:err:ntdll:RtlpWaitForCriticalSection section 6EDBC320 "../src-wine/dlls/user32/user_main.c: user_section" wait timed out in thread 0024, blocked by 00b8, retrying (60 sec)
MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0

19872.603:00bc:00c0:err:xrandr:xrandr14_get_adapters Failed to get adapters
19872.614:00bc:00c0:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\shcore.dll" at 00000003126F0000: builtin
19872.614:00bc:00c0:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\shlwapi.dll" at 00000002E3540000: builtin
19872.614:00bc:00c0:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\shell32.dll" at 00007F54EB540000: builtin
19872.616:0020:00b8:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
19872.616:0020:00b8:err:winediag:nodrv_CreateWindow The explorer process failed to start.
19872.616:00bc:00c0:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
19872.617:00bc:00c0:err:winediag:nodrv_CreateWindow The explorer process failed to start.
19872.617:00bc:00c0:err:ole:apartment_createwindowifneeded CreateWindow failed with error 0
19872.618:00bc:00c0:err:ole:apartment_createwindowifneeded CreateWindow failed with error 0
19872.620:00bc:00c0:err:ole:apartment_createwindowifneeded CreateWindow failed with error 0

[smcv]

From your system info, we're successfully detecting both your Intel and NVIDIA GPUs as Vulkan devices, with the Intel GPU preferred, but both working. You also have software Vulkan rendering available. This is true both inside and outside the container.

I think pressure-vessel is working correctly, but maybe you need something like

__NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=non_NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=mesa %command%

or some suitable value for DXVK_FILTER_DEVICE_NAME, to convince DXVK not to second-guess this and try to render via the NVIDIA GPU anyway.

[segvee]

Another thing that I have noticed, which I thought was because I am using Ubuntu 21.04 instead of Debian at the moment, is that when I started a game the whole desktop would freeze. I could still move the mouse but the clock in KDE would stop and I could not interact with anything

Are you sure it's that, and not this, which would also match those symptoms?

• On startup, the game (or maybe a Proton component) allocates a fullscreen window
• The initial contents of that window are effectively a screenshot of your KDE session, including the clock stopped at its initial value
• Clicking anywhere on that window doesn't do anything because the game hasn't fully started yet
• While the game is starting up, no more frames are drawn
• When the game draws a frame for the first time, the contents of that window are replaced by whatever the game draws

You might be able to tell the difference by using Alt+Tab to switch between windows, or using a equivalent of GNOME's Overview if KDE/Plasma has one.

The symptoms in my case are similar but not wholly congruent. It may be the case that a fullscreen window is allocated, however, this is what I experience: the little steam window "Preparing to launch Noita..." pops up. After a few second the screen freezes for a few seconds whereas I cannot do anything. I cannot even alt+tab. The only possible interaction is moving the mouse cursor, that's it. Then it unfreezes. Then it freezes again, for a longer period of time and then it unfreezes again after which the game starts (the main game window pops ups) or other things happen (like the Origin window launching in Far Cry 5's case).

From your system info, we're successfully detecting both your Intel and NVIDIA GPUs as Vulkan devices, with the Intel GPU preferred, but both working. You also have software Vulkan rendering available. This is true both inside and outside the container.

I think pressure-vessel is working correctly, but maybe you need something like

__NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=non_NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=mesa %command%

or some suitable value for DXVK_FILTER_DEVICE_NAME, to convince DXVK not to second-guess this and try to render via the NVIDIA GPU anyway.

I tried that command, unfortunately the same thing happened, the game doesn't start. :/

[smcv]

@kisak-valve, would you be able to point Proton/DXVK developers to this? From the system info in https://github.com/ValveSoftware/steam-runtime/issues/449#issuecomment-903152769 it looks as though basic use of Vulkan is working OK both outside and inside the container (we successfully run a simple program check-vulkan from steam-runtime-tools, which opens a non-visible X11 window and uses each GPU in turn to draw a triangle), which I think points towards this being a higher-layer problem, maybe with DXVK.

@segvee, something you could try to confirm whether Vulkan is working correctly in the container is to install a native Linux game that uses Vulkan, and configure it to use the "Steam Linux Runtime" compatibility tool. https://store.steampowered.com/app/583950/Artifact/ is an example of a free native Linux game that uses Vulkan.

If Artifact works but Proton games don't, then that points towards a problem with Proton/Wine/DXVK.

If Artifact doesn't work either, then that points towards a container (or Vulkan) problem.

[Leopard1907]

Tested on my system with Prime Render Offload and can't see a problem.

__NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=non_NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=mesa %command% works just fine on a D3D11 game and correctly runs on my igpu.

https://store.steampowered.com/app/588430/Fallout_Shelter/

Whilelisted against Proton 3.7 so i forced it to run with Proton 6.3-6.

• System info as gist:

https://gist.github.com/Leopard1907/6f6641d50118a47c95387193d42d48c5

• How i launch Steam:

__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia __VK_LAYER_NV_optimus=NVIDIA_only steam

• How i launched this specific game:

__NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=non_NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=mesa %command%

Fwiw ; game that reporter posted output from ( 881100) is Noita, which is a Windows only OpenGL game. So DXVK/Vulkan is irrelevant here.

I tested a Windows only GL game, Wolfenstein New Order with __NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=non_NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=mesa %command% and it does correctly runs on Intel igpu.

So it might be a simple copy-paste error on user side that prevents those vars to work or it might be a Intel driver issue?

@segvee Can you try with another GL game? Maybe Intel driver is just not able to run that Noita game?

Also PCGW notes that Noita is a 32 bit game so make sure you have functioning 32 bit Intel GL driver.

Not sure if there is something like glxgears-32 exist for you to test it quickly.

[smcv]

Fwiw ; game that reporter posted output from ( 881100) is Noita, which is a Windows only OpenGL game. So DXVK/Vulkan is irrelevant here.

Aha, that's a good point. If Proton implements Windows OpenGL using by Linux OpenGL, then it should be __GLX_VENDOR_LIBRARY_NAME that matters for OpenGL games.

https://store.steampowered.com/app/302380/Floating_Point/ is free, and is a nice simple example of a native Linux 32-bit OpenGL game to try. It's the one we used for a lot of the early container runtime testing, before Proton started using it.

Not sure if there is something like glxgears-32 exist for you to test it quickly.

The diagnostic tool in System Information should already be doing a quick functional check for at least GLX (look for glx/gl) - as with Vulkan, it just opens an invisible window and draws a triangle. It says 32- and 64-bit OpenGL are using Mesa 21.2.1 from the kisak-mesa PPA, and they seem to be working OK both outside and inside the container.

[segvee]

Hello there,

Replying to https://github.com/ValveSoftware/steam-runtime/issues/449#issuecomment-904537612

I ran Artifact Foundry with __NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=non_NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=mesa %command% and without and both times the game started without any problems.

---

Replying to https://github.com/ValveSoftware/steam-runtime/issues/449#issuecomment-904583652

I don't usually launch Steam with __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia __VK_LAYER_NV_optimus=NVIDIA_only steam so that is there to keep in mind.

I ran other game besides Noita but I will gladly try again.

I don't have Fallout Shelter but I do have Wolfenstein: The New Order and I tried running it without specifying anything, with __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia __VK_LAYER_NV_optimus=NVIDIA_only steam and with __NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=nvidia %command%, using Proton experimental every time.

• Without any options and forcing Intel GPU: steam said the game is starting, the little window disappeared and nothing happened anymore. Had to stop the game from the Steam window.
• Forcing NVidia: Game launched without any problems.

Here are the soldier and proton logs for running without any command, with forcing intel and with forcing nvidia (in that order): slr-app201810-t20210824T164110_nothing.log slr-app201810-t20210824T164520_intel.log slr-app201810-t20210824T164938_nvidia.log steam-201810_nothing.log steam-201810_intel.log steam-201810_nvidia.log

---

Replying to https://github.com/ValveSoftware/steam-runtime/issues/449#issuecomment-904609502

I downloaded and ran Floating Point. nvidia-smi confirmed that it ran using the Intel GPU. The game started without a problem and worked fine. I should also note that I didn't have any problems with most Linux native games so far. I'm not sure whether it uses Vulkan or OpenGL but I could run American Truck Simulator on my Intel and on the NVidia GPU without a problem, just as an example. I think Tonight We Riot is a Vulkan game with a native Linux port and I could run it without problems on the Intel GPU, too.

[Leopard1907]

@segvee Did you run Floating Point by forcing Steam Linux Runtime? I think that is the key point here to determine if this is a Pressure Vessel/runtime issue or not. Right click to game-Properties-Compatibility Tools-Steam Linux Runtime

ATS is also an OpenGL game. Forcing SLR should be needed there to also determine if issue is Pressure Vessel rooted or not.

Fallout Shelter is a free to play game and relatively small. But since it is D3D11, it is not related to your possibly (?) OGL and runtime related issue. Of cource you could try to run it with wined3d for determining if issue also exist there too.

[Leopard1907]

One more thing, can you post output of this from terminal?

inxi -SMGxx

[segvee]

@segvee Did you run Floating Point by forcing Steam Linux Runtime? I think that is the key point here to determine if this is a Pressure Vessel/runtime issue or not. Right click to game-Properties-Compatibility Tools-Steam Linux Runtime

ATS is also an OpenGL game. Forcing SLR should be needed there to also determine if issue is Pressure Vessel rooted or not.

Fallout Shelter is a free to play game and relatively small. But since it is D3D11, it is not related to your possibly (?) OGL and runtime related issue. Of cource you could try to run it wined3d for determining if issue also exist there too.

Ah I see. Sorry, I think I misunderstood.

I forced Steam Linux Runtime for Floating Point and the game started fine. nvidia-smi doesn't report any processes so I think it runs on the Intel GPU. Same thing with American Truck Simulator. I forced the Steam Linux Runtime and nvidia-smi didn't report any new process. The FPS was also very poor so it definitely ran on the Intel GPU.

How would I go about running Fallout Shelter with wined3d?

One more thing, can you post output of this from terminal?

inxi -SMGxx

The output of inxi -SMGxx is as follows:

System:    Host: myhostname Kernel: 5.11.0-31-generic x86_64 bits: 64 compiler: gcc v: 10.2.1 Console: tty 10 wm: kwin_x11 
           DM: GDM3, SDDM Distro: Ubuntu 21.04 (Hirsute Hippo) 
Machine:   Type: Laptop System: LENOVO product: 20YS0004GE v: ThinkPad T15g Gen 2i serial: serialnumber Chassis: type: 10 
           serial: serialnumber 
           Mobo: LENOVO model: 20YS0004GE v: SDK0J40697 WIN serial: serialnumber UEFI: LENOVO v: N37ET28W (1.09 ) 
           date: 06/24/2021 
Graphics:  Device-1: Intel vendor: Lenovo driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:9a60 
           Device-2: NVIDIA GA104M [GeForce RTX 3070 Mobile / Max-Q] vendor: Lenovo driver: nvidia v: 470.57.02 
           bus ID: 01:00.0 chip ID: 10de:249d 
           Device-3: Acer Integrated Camera type: USB driver: uvcvideo bus ID: 3-4:3 chip ID: 5986:212b 
           Display: server: X.Org 1.20.11 compositor: kwin_x11 driver: loaded: modesetting,nvidia unloaded: fbdev,nouveau,vesa 
           resolution: 1920x1080~60Hz s-dpi: 98 
           OpenGL: renderer: Mesa Intel UHD Graphics (TGL GT1) v: 4.6 Mesa 21.2.1 - kisak-mesa PPA direct render: Yes

[Leopard1907]

Your inxi output is ok. I asked for it to see if you are on NV only mode.

https://github.com/ValveSoftware/Proton#runtime-config-options

PROTON_USE_WINED3D=1

From your comments above it might be an Intel driver issue you experienced, rather than a runtime related one. Which in this case it might be good to report them on Mesa tracker.

[smcv]

It seems like the container runtime is working fine for native Linux games, which I think points us towards this being a Proton-specific issue?

[Leopard1907]

His Fallout Shelter with wined3d test should yield to ultimate result i think. OpenGL due to wined3d usage ( if forced like mentioned above) and Proton.

Since Intel drivers gets very little testing for games ( usually) , it is very possible driver and HW combo ( Tigerlake-i915/Iris) might have some weirdness with select games. My system has KBL so results might differ.

[kisak-valve]

Thanks for the testing so far, I think you've pondered this issue well enough to consider the runtime environment as healthy, so it's back to something for the Proton devs to ponder.

[segvee]

Your inxi output is ok. I asked for it to see if you are on NV only mode.

https://github.com/ValveSoftware/Proton#runtime-config-options

PROTON_USE_WINED3D=1

From your comments above it might be an Intel driver issue you experienced, rather than a runtime related one. Which in this case it might be good to report them on Mesa tracker.

It is strange, I installed Fallout Shelter and tried to run it. It started without problems. But it defaulted to the NVidia card. I then tried __NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=non_NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=mesa %command% and __NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=non_NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=mesa PROTON_USE_WINED3D %command% and the game worked both times, using the Intel GPU.

His Fallout Shelter with wined3d test should yield to ultimate result i think. OpenGL due to wined3d usage ( if forced like mentioned above) and Proton.

Since Intel drivers gets very little testing for games ( usually) , it is very possible driver and HW combo ( Tigerlake-i915/Iris) might have some weirdness with select games. My system has KBL so results might differ.

It's true but then again Noita works using the Intel GPU when I force Proton 5.0 or a version of Proton that doesn't use the Soldier container environment, i.e. Proton major version 5 works when not using the Soldier container environment but doesn't when using the Soldier container environment. The versions of Proton are 5.0-10 and 5.13-6. I wonder whether the breakage occurs somewhere in between or when switching to the Soldier container environment.

[Leopard1907]

Reason why Fallout Shelter ran on your dgpu without doing anything is this.

https://github.com/doitsujin/dxvk/blob/master/src/dxvk/dxvk_instance.cpp#L183

DXVK and vkd3d tries to run on dgpu by default.

Try Noita with latest Proton but with disabling runtime then.

https://github.com/flightlessmango/MangoHud/issues/369#issuecomment-709902078

Do this but with shift 2 , if it works like that ( runtime disabled) but doesn't work when runtime is enabled ( simply reverting shift 2 hack) then it is possibly a runtime issue. If it doesn't help then it might be a Proton issue.

Btw that is PROTON_USE_WINED3D=1 not plain PROTON_USE_WINED3D

[smcv]

but with disabling runtime

Note that running Proton 5.13 or later without using the container runtime is an entirely unsupported modification. You can try it as a way to compare different scenarios, but do not expect technical support if something doesn't work like that.

[segvee]

I changed

#!/usr/bin/env bash

to

#!/usr/bin/env bash
shift 2
exec "${@}"

and tried to start Noita using the default Proton version. The game did not start, so I guess we can rule out that possibility.

Anything else I should test for? Maybe try different Proton releases between 5.0 and 5.13? When did the change to the Soldier container environment occur?

[smcv]

When did the change to the Soldier container environment occur?

Proton 5.13+ (including Experimental) uses soldier. Proton 5.0 and older didn't. Unfortunately this means there is no supported way to distinguish between "regression caused by switching to the container runtime" and "regression in Proton/Wine/DXVK/etc. between 5.0 and 5.13".

However, because bypassing the container runtime had the same result as using the same Proton version in the container, that suggests that the important thing here is probably the version of Proton itself (Proton, Wine, DXVK or some other component) rather than the container runtime.

[Leopard1907]

Yes, if disabling runtime didn't help there with never Proton versions then we can rule out runtime as possible culprit. What i would do in this case is; both leaving a comment with logs in here with runtime enabled Noita issue tracker and checking ProtonDB ( not official but a good place to see how a game works for others including with their system info) to see if it works for other Intel igpu users.

Since i already looked there and saw Intel gpu users can run this game on newer Proton's as well, you reported game works on Nvidia dgpu without problems and game works on your igpu if Proton version is set to 5.0; it is either a very edge situation Proton regression or simply your igpu does something on newer Proton versions that Proton doesn't like but somehow other gpu's and vendors are ok with it.

So to sum it up:

• Report to Noita tracker with logs from both igpu can run it and igpu can't run it states ( Proton 5.0 vs newer one)

• Report the issue to Mesa tracker since it might be something that your hw/driver specifially does wrong but it worked somehow on older Proton

https://gitlab.freedesktop.org/mesa/mesa/-/issues

When reporting Note that Noita is an OpenGL game.

[Leopard1907]

One last thing to test:

• Set game to a Proton version that is known to be not working with your igpu, try this as a launch option:

MESA_LOADER_DRIVER_OVERRIDE=i965 %command%

[segvee]

One last thing to test:

• Set game to a Proton version that is known to be not working with your igpu, try this as a launch option:

MESA_LOADER_DRIVER_OVERRIDE=i965 %command%

I just tested this, no dice.

I'm not sure whether I should report that in the Noita tracker. The problem is that this happens to a lot of games using newer versions of Proton. I also tried "Wolfenstein: the new order", "My summer car", "Ostriv", "Mini motorways", "Outer wilds" and many more I had tried earlier. Actually I became suspicious about Fallout Shelter and I think I have to retract my earlier statement. Due to an oversight of mine I did not realise that it defaults to Proton version 3.7. Upon forcing the game to use Proton experimental it does not start on the Intel GPU anymore. I don't think it's these games' fault. It's either Proton or the hardware/driver, as you mentioned.

[Leopard1907]

Did you use NV prime render offload vars correctly to run it on igpu tho? It should work...

[segvee]

My launch options for Fallout Shelter look like this: PROTON_LOG=1 __NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=non_NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=mesa %command%

[arrowgent]

please note that __NV_PRIME_RENDER_OFFLOAD=1 & __NV_PRIME_RENDER_OFFLOAD_PROVIDER=NVIDIA-0 are only now supported by xserver-xorg 1.21 & Nvidia v435x/440.x

check your version with: apt list xserver-xorg-core

these upstream improvements have been waiting in limbo for nearly 2 years since the original nvidia driver releases it is not recommended to use those two unless you have the latest xserver-xorg do some benchmark testing between the two options and you might (should) see up to 90% performance decrease

https://www.phoronix.com/scan.php?page=news_item&px=GLXVND-Offload-Improve-1.21 https://www.phoronix.com/scan.php?page=news_item&px=X.Org-Server-21.1-Coming

https://download.nvidia.com/XFree86/Linux-x86_64/435.17/README/primerenderoffload.html https://download.nvidia.com/XFree86/Linux-x86_64/440.64/README/primerenderoffload.html

other resource you can use and reference for Mesa https://mesamatrix.net/

personally i use nvidia-prime to "select" nvidia. https://packages.ubuntu.com/search?keywords=nvidia-prime

afaik the older methods "primerun" & "bumblebee" or whatever they were called have been deprecated and abandoned, favoring nvidia-prime

alternatives you can test these supported enviornment variables:

export __GLX_VENDOR_LIBRARY_NAME=nvidia
export __VK_LAYER_NV_optimus=NVIDIA_only

also note proton 4.11 & 5.0 have different DXVK requirements:

DXVK Version 1.5.2 https://github.com/doitsujin/dxvk/releases/tag/v1.5.2

@doitsujin doitsujin released this on Jan 24, 2020

Compatibility
Vulkan 1.1 is now required, which means that very old drivers will no longer be able to run DXVK:

note this was released in proton 5.0 https://github.com/ValveSoftware/Proton/releases/tag/proton-5.0-1 Update DXVK to v1.5.4.

last to allow using vulkan 1.0 was proton 4.11 https://github.com/ValveSoftware/Proton/releases/tag/proton-4.11-12 Update DXVK to v1.5.1.

[kisak-valve]

Hello @arrowgent, your claim that the unreleased xorg-server 1.21 is required for nVidia's prime render offload is not true, the patches were backported to the 1.20.6 release years ago.

[segvee]

Sooo... since Debian testing now supports my wifi card I was able to go back home again and install Debian (<3). My current version of mesa is OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.3.5. So far I have tried Noita and I was successfully able to launch and run it on the iGPU. It seems this issue doesn't exist on Debian testing. It doesn't seem like anyone else had this issue so I might as well close it.

[E-daw]

I'm having an issue with this currently. Trying to run the windows version of civilization 5 on my iGPU and it just defaults to Nvidia. No launch arguments seem to change the outcome of which GPU is selected

currently on manjaro using the hybrid intel-nvidia driver

[segvee]

I'm having an issue with this currently. Trying to run the windows version of civilization 5 on my iGPU and it just defaults to Nvidia. No launch arguments seem to change the outcome of which GPU is selected

currently on manjaro using the hybrid intel-nvidia driver

Hey, just to be clear: using

__NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=non_NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=mesa %command%

is not working?

[E-daw]

I'm having an issue with this currently. Trying to run the windows version of civilization 5 on my iGPU and it just defaults to Nvidia. No launch arguments seem to change the outcome of which GPU is selected currently on manjaro using the hybrid intel-nvidia driver

Hey, just to be clear: using

__NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=non_NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=mesa %command%

is not working?

No it's not working.

Edit: I tried uninstalling the nvidia drivers, and after rebooting my system and relaunching the game, it wouldn't even run, it would crash half way through launching. Vulkaninfo showed an error when trying to get an output stating something about no gpus detected at all.

I reinstalled intel-vulkan and the mesa layers with it as well and the game would then run and launch on the integrated graphics. However since reinstalling the nvidia hybrid drivers and using the above arguments, it still decides to force the Nvidia GPU for some reason.

[segvee]

I'm having an issue with this currently. Trying to run the windows version of civilization 5 on my iGPU and it just defaults to Nvidia. No launch arguments seem to change the outcome of which GPU is selected currently on manjaro using the hybrid intel-nvidia driver

Hey, just to be clear: using

__NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=non_NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=mesa %command%

is not working?

No it's not working.

Edit: I tried uninstalling the nvidia drivers, and after rebooting my system and relaunching the game, it wouldn't even run, it would crash half way through launching. Vulkaninfo showed an error when trying to get an output stating something about no gpus detected at all.

I reinstalled intel-vulkan and the mesa layers with it as well and the game would then run and launch on the integrated graphics. However since reinstalling the nvidia hybrid drivers and using the above arguments, it still decides to force the Nvidia GPU for some reason.

Hybrid drivers? How do you install your drivers? I am using Debian and I just install nvidia-driver through apt. Is it possible that your BIOS is set so only the NVidia GPU is used? In KDE and Gnome you can check that in the About section in the Settings or somewhere like that.

[E-daw]

Hybrid drivers are packaged with Manjaro, It includes nvidia-prime, intel i915 mesa, and the nvidia drivers. By default the intel graphics on my machine are selected. For some reason any games ran through proton just select the dGPU instead of the iGPU by default and there seems to be no way to override it. Nothing in BIOS should be effecting this issue, and no setting like that exists for me. I'm on a Razer Blade Stealth 13 inch.

Edit: Currently the only way I'm able to reliably run Proton games with the integrated graphics is by using Optimus Manager and switching the system to exclusively use the iGPU.

[smcv]

@E-daw: please report a separate issue with full details and logs (see https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information).

We might be able to help if given more information, but if we keep appending more comments to a previously-fixed issue, it just gets confusing (which makes it less likely that anything will be diagnosed or fixed).