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: ValveSoftware/dxvk@40b5275

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.