New steam UI does not open if run with DRI_PRIME=1

[koresh-krasa]

Your system information

• Steam client version (build number or date): 1682634349
• Distribution (e.g. Ubuntu): Fedora Silverblue 38
• Opted into Steam client beta?: [Yes/No] Yes
• Have you checked for system updates?: [Yes/No] Yes

Please describe your issue in as much detail as possible:

Similar symptoms as https://github.com/ValveSoftware/steam-for-linux/issues/9381 Login prompt displayed correctly but than main window tries to appear but crashes and goes into loop. This issue is happening if DRI_PRIME is set to non 0 (e.g. DRI_PRIME=1, DRI_PRIME=pci-0000_03_00_0) DRI_PRIME=0 works fine.

In journalctl I was able to find some error logs related to steamwebhelper crash. steam_journalctl.txt

Optput from DRI_PRIME=1 com.valvesoftware.Steam steam_output.txt

Steam client is flatpak

System information: https://gist.github.com/koresh-krasa/b9a7a4c486ff061b9823aea6ce44f65b

DRI_PRIME=1 was working before this update

Steps for reproducing this issue:

1. Open steam with DRI_PRIME set as non 0 / from Gnome application menu
2. Login splash window works as expected
3. Main window is not appearing Screencast from 2023-04-28 11-23-06.webm

[michaelneverwins]

I was initially unable to launch Steam from the menu after upgrading to Linux Mint 21.2 (from 21.1), and the workaround suggested by @kisak-valve (changing PrefersNonDefaultGPU=true to PrefersNonDefaultGPU=false in the desktop entry) fixed it for me.

But in my case, games then launched from Steam seem to run perfectly well without adding DRI_PRIME=1 %command% to the launch options as suggested above. It occurs to me that, despite having a system with both integrated and discrete graphics, I've never had to use DRI_PRIME=1 for anything (even outside of Steam) in several years of using Linux, and maybe this is why:

michael:~$ glxinfo -B | grep Device
    Device: AMD Radeon HD 7900 Series (tahiti, LLVM 15.0.7, DRM 3.42, 5.15.0-76-generic) (0x679a)
michael:~$ export DRI_PRIME=1
michael:~$ glxinfo -B | grep Device
    Device: Mesa Intel(R) HD Graphics 4600 (HSW GT2) (0x412)
michael:~$ 

My discrete GPU appears to be the default, although I didn't make it that way on purpose. Is that not a valid configuration? The use of PrefersNonDefaultGPU=true in Steam's desktop entry would suggest as much, given the implication that the "non-default GPU" is necessarily the right one for gaming. By the way, if I do run games with DRI_PRIME=1, some of them — particularly native Steam games which use OpenGL and, outside of Steam, native GZDoom in OpenGL mode — run poorly and are clearly using my integrated graphics, whereas otherwise they run well and use my discrete graphics. Some other games — such as Windows games under DXVK via Proton via Steam (launched with PrefersNonDefaultGPU=false) as well as native GZDoom in Vulkan mode — appear to use my discrete GPU regardless of whether I set DRI_PRIME=1. So there's some inconsistency here, but OpenGL at least seems to handle DRI_PRIME=1 simply by selecting my (apparently non-default) integrated graphics chip.

Did setting PrefersNonDefaultGPU=false in Steam's desktop entry fix it for me because my discrete GPU is the default? (Was Steam just failing to start because it was trying to use integrated graphics?) It seems like it must be a coincidence, because the PrefersNonDefaultGPU=false workaround appears to have helped a lot of people and yet everything I've been reading has given me the impression that discrete graphics being the default is very unusual. But I figured I should bring it up.

[romeroFan6268]

I was initially unable to launch Steam from the menu after upgrading to Linux Mint 21.2 (from 21.1), and the workaround suggested by @kisak-valve (changing PrefersNonDefaultGPU=true to PrefersNonDefaultGPU=false in the desktop entry) fixed it for me.

Could you please tell me where the Steam desktop file is located? Or is it perhaps a command I need to run in the terminal? I'm still learning how to use Linux (I quit Windows over a year ago, since I was fed up with their constant spying).

[michaelneverwins]

Could you please tell me where the Steam desktop file is located?

I think it should be at /usr/share/applications/steam.desktop. That would be owned by root, so you would need to open the file with administrator privileges in order to change it directly. If you don't want to do that, you can also make a copy of the file at ~/.local/share/applications/steam.desktop and then change PrefersNonDefaultGPU=true to PrefersNonDefaultGPU=false in that copy. Desktop entries in ~/.local/share/applications/ typically act as overrides to the ones in /usr/share/applications/, at least in Cinnamon (Linux Mint's desktop environment).

To copy and modify it from the command line:

cp /usr/share/applications/steam.desktop ~/.local/share/applications/steam.desktop
sed s/PrefersNonDefaultGPU=true/PrefersNonDefaultGPU=false/ -i ~/.local/share/applications/steam.desktop

Edit: Just to clarify, the desktop entries in /usr/share/applications/ and/or ~/.local/share/applications/ define items in the application menu. If you have an actual desktop shortcut to Steam, the file defining that shortcut would probably be ~/Desktop/steam.desktop.

[returnofblank]

I was initially unable to launch Steam from the menu after upgrading to Linux Mint 21.2 (from 21.1), and the workaround suggested by @kisak-valve (changing PrefersNonDefaultGPU=true to PrefersNonDefaultGPU=false in the desktop entry) fixed it for me.

Could you please tell me where the Steam desktop file is located? Or is it perhaps a command I need to run in the terminal? I'm still learning how to use Linux (I quit Windows over a year ago, since I was fed up with their constant spying).

/usr/share/applications, there you will find the .desktop file. Make sure to log out and log back in after making changes, so the launcher refreshes.

[romeroFan6268]

Yup, it worked! Thanks, guys... :+1:

[chinoto]

@michaelneverwins DRI_PRIME is usually meant for laptops where the iGPU is going directly to the display and renderings from the dGPU have to pass through the iGPU to reach the display. I'm guessing that DRI_PRIME blindly offloads to the non-display GPU, regardless of which way the power difference goes.

As for why OpenGL and Vulkan** games behave differently, I believe that is because Vulkan games can choose which GPU to render on, whereas OpenGL games are stuck with whatever the graphics stack chose to use, which can be influenced by DRI_PRIME and MESA_LOADER_DRIVER_OVERRIDE***.

integrated/dedicated Proton uses Vulkan via DXVK for DirectX games I attempted to use this to play with Zink, but it wasn't included in my distribution's Mesa package at the time (apparently it is now!). I just tried running steam with it, but it failed. Might be useful for specific OpenGL games though.

[romeroFan6268]

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/9383#issuecomment-1647196453

Well, that's one problem solved. Both the panel icon and the "Start Menu" icon for Steam work. However, there is one more issue. It appears certain games are having problems loading. One such example is the hit zombie game "Dying Light." Is the DRI_PRIME the culprit? Again, sometimes it take a while for "Dying Light" to load, sometimes the game doesn't start. When it does, I can play, but when I try to quit the game, the computer freezes. I am then forced to shut the power off on my PC. Also, to point out, "Dying Light" has Vulcan shaders to load when it starts, so I'm very certain it is a Vulcan game. Should I set the DRI_PRIME line for the .desktop Steam file to 0, or what should I do? Any help would be appreciated. Thanks... :)

[michaelneverwins]

Thanks for the information, @chinoto. I am indeed not using a laptop, and both of my monitors are plugged directly into my GPU, one via HDMI and the other via DVI just because that's what I have. (Wondering if it would make a difference, I tried plugging them into the motherboard's HDMI and DVI ports while the PC was off and then booting it up, but then my desktop wouldn't display at all and I had to switch to a TTY with Ctrl+Alt+F1 to see anything.)

As of now, I'm not sure whether having my discrete GPU as the default is a blessing or a curse. On one hand, I've never had to worry about adding DRI_PRIME=1. On the other hand, as I've now discovered, I have to worry about software incorrectly assuming my default graphics are bad, e.g. desktop entries with PrefersNonDefaultGPU=true launching programs with integrated graphics. Steam not launching with PrefersNonDefaultGPU=true may have other causes, but Super Tux Kart's desktop entry also has PrefersNonDefaultGPU=true which causes it to use my integrated graphics and run poorly. I've also noticed that right-clicking items in Linux Mint 21.2's application menu shows a "Run with dedicated GPU" option which, sure enough, actually results in OpenGL software using my integrated graphics instead. At best, this option is badly named. It's going to bug me even if I don't look at it. But I'll stop ranting now.

[romeroFan6268]

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/9383#issuecomment-1647261937

You're not the only one, michaelneverwins. We all want Steam running spotless on Linux. Especially other distros that are not Ubuntu. I've tried Ubuntu in the past and I just could not get pass the desktop. Didn't like it. So, I instead turned to Linux Mint. Plus, LM has better privacy settings than Ubuntu. Hopefully, some new update will come along and fix all this... :)

So, has anyone got some of their games to work (the ones that worked before the torturous Steam update)? Some of mine work, but not all of them (and yes, I have the Proton Experimental enabled). Also, Dying Light (which has a native Linux version) still has issues running. Can't even quit the game without it crashing... :(

[chinoto]

From what I'm reading, it seems PrefersNonDefaultGPU is [not simply/more than] a proxy for DRI_PRIME=1 because there are several other variables that manipulate how GPU selection is handled and are specific to OpenGL or Vulkan, but the exact handling depends on your Desktop Environment or whatever opened the .desktop file.

I believe (Edit: I was wrong) DRI_PRIME is specific to OpenGL and should have no effect on DirectX games running through DXVK, which Proton/"Steam Play" (a modified version of Wine) uses.

Hopefully this either clears things up or just makes it more obvious how complicated this all is...

https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#:~:text=PrefersNonDefaultGPU

PrefersNonDefaultGPU: If true, the application prefers to be run on a more powerful discrete GPU if available, which we describe as “a GPU other than the default one” in this spec to avoid the need to define what a discrete GPU is and in which cases it might be considered more powerful than the default GPU. This key is only a hint and support might not be present depending on the implementation.

https://github.com/flathub/com.valvesoftware.Steam/issues/559#issuecomment-815900530

DRI_PRIME=1 selects the first non-default GPU, whatever that is. If your default is a fast AMD/NVIDIA discrete GPU, and you also have a slow AMD/Intel integrated GPU, then DRI_PRIME=1 will do the exact opposite of what you want.

https://gitlab.xfce.org/xfce/garcon/-/issues/21

On systems with NVidia discrete GPUs, render offload is controlled with three different environment vars as documented here. It's probably a good idea to just set all of them when the discrete GPU is requested

[DianaNites]

DRI_PRIME "applies to OpenGL and Vulkan" and is commonly needed to run Windows games through Proton on the dGPU. Some games offer GPU selection on their own or otherwise use the more powerful one, though.

[michaelneverwins]

Thanks again @chinoto and @DianaNites. I'm just commenting again to clear up a couple of things.

Earlier I wrote that I tried plugging my monitors into the motherboard instead of the GPU and had no graphics at all: https://github.com/ValveSoftware/steam-for-linux/issues/9383#issuecomment-1647261937

This was because I had to change "Initial Display Output" from "PCIe 1 Slot" to "IGFX" in my BIOS settings. I did that and then rebooted with my monitors plugged into my motherboard, and now Linux Mint is indeed treating my integrated graphics as the default (which is apparently typical).

michael:~$ glxinfo -B | grep Device
    Device: Mesa Intel(R) HD Graphics 4600 (HSW GT2) (0x412)
michael:~$ export DRI_PRIME=1
michael:~$ glxinfo -B | grep Device
    Device: AMD Radeon HD 7900 Series (tahiti, LLVM 15.0.7, DRM 3.42, 5.15.0-76-generic) (0x679a)
michael:~$ 

Note that this is the opposite of the glxinfo output I got when my monitors were plugged into the GPU: https://github.com/ValveSoftware/steam-for-linux/issues/9383#issuecomment-1647187561

So the reason for my dedicated graphics being the default (thus causing DRI_PRIME=1 to do the opposite of what was expected in some cases) was indeed the fact that my monitors were plugged into the GPU directly (or, on second thought, the fact that the GPU was the initial display output in the BIOS settings).

The more relevant bit of information is that, with Linux Mint now treating my integrated graphics as the default, Steam still fails to open a window when launched from a shortcut with PrefersNonDefaultGPU=true, which confirms that this bug has nothing to do with my integrated graphics having previously been the non-default. (Sorry for this whole tangential discussion.) Additionally, modifying the shortcut to use PrefersNonDefaultGPU=false still fixes Steam. The difference is that now I actually do need to add DRI_PRIME=1 %command% to the launch options of some games in order to get them to run well, whereas previously I did not because Steam as launched with PrefersNonDefaultGPU=false was already running games using my discrete GPU.

[chinoto]

@michaelneverwins You should try running a benchmark to see what the overhead (latency and processing) would be of your more powerful/dedicated GPU directly connected to the monitor compared to the integrated being connected to the monitor and offloading to the more powerful GPU. If the overhead isn't a concern, then the power savings when you're not doing anything graphically demanding could be appealing.

[michaelneverwins]

Thanks, @chinoto. I don't know of a good way to measure power consumption right now, but that's worth checking out. I did look at the temperature readings from my dedicated GPU while I was set up to use integrated graphics by default, and it didn't seem significantly cooler so it may not have been going to its lowest-power state when idle, but I guess temperature shouldn't correlate strongly to power consumption anyway if the fans are doing their job.

For now, though, I've gone with the simplest solution: just disabling my CPU's integrated graphics via the BIOS settings (and also, of course, setting "Initial Display Output" back to my PCIe slot, and moving the monitor cables back to the GPU ports accordingly). This may not be the most energy-efficient way to go, but it isn't any worse than my original dedicated-GPU-by-default configuration in which the integrated graphics were enabled but basically never used. With only one available graphics device, Steam launches successfully from the default menu shortcut. (Meanwhile I don't have to worry about adding DRI_PRIME=1, nor do I have to worry about PrefersNonDefaultGPU=true doing the wrong thing, since it won't do anything now.)

[richeersssss]

will this bug fix?still has the same issus on ubuntu 22.04 with amd 5800h with radeon rx6600m

[redve-dev]

My problem is, every game crashes when I have to open steam overlay in game (or I get an achievement, or whatever). The workaround that works now is to add "DRI_PRIME=1 %command%" in launch options in game that breaks as someone has mentioned above.

I use arch linux with bspwm

[TimTheOverlord]

TLDR: If you have an AMD GPU and are using the pro drivers, remove them and reinstall the AMD drivers using the --usecase=graphics option.

Alright, for anyone with an AMD GPU, if you have the AMD PRO drivers installed, simply don't. With some recent update, Valve killed the -vgui workaround I reported earlier, which prompted me to think about fixing it again. I dug into the logs to see why Steam was crashing, specifically at ~/.local/shareSteam/logs/cef_log.txt and noticed several entries of this:

EGL Driver message (Error) eglGetMscRateANGLE: glXGetMscRateOML failed

Googling that led me here which mentioned the infinitely opening windows of Chrome (very similar in my situation with Steam's windows opening and closing over and over again). Basically, I think that AMD does something funky with it's professional drivers and Steam, being engineered for the average Linux build, is probably expecting the open source AMD drivers to be installed. I specifically fixed it by completely purging the AMD drivers and then reinstalling them, this time with the --usecase=graphics option (steps to update here). I don't know how applicable this is to other people, but this finally got it working for me.

My system is running Ubuntu 20.04 on an AMD Ryzen 5 3600 with and old Vega 56. I installed the pro drivers initially with the intent of doing some deep learning in Pytorch. I had issues setting that up, and once Steam was updated to the new UI it broke. I hadn't tested many other applications, but I also noticed KiCAD was having graphics troubles too. The lesson learned here is don't stray too far from the beaten path when it comes to Linux, unless you're an Arch user... ;)

[sleeyax]

This issue has bugged me for months now. Although the suggested 'solution' to remove DRI_PRIME=1 from the environment variables works, it makes the steam client incredibly slow and laggy (because it's using the integrated graphics card now). Has anyone figured out how to force the steam client to use the dedicated GPU anyways?

[chinoto]

@sleeyax You might be able to improve Steam's performance while not using DRI_PRIME by disabling "GPU accelerated rendering in web views" and other hardware acceleration, but this assumes the iGPU is so bad that the CPU becomes a better choice.

I tried running Steam with Zink (Vulkan-based translation layer for OpenGL), but the main window repeatedly attempts to open, then closes/crashes, which could easily be the fault of either Zink or Steam given how immature Zink is and how flaky Steam can be. The overhead isn't too high, so if it works on your setup, it could be good enough.

I ran Xonotic's the-big-keybench in timedemo mode with 1080p ultra settings and got these results direct and via Zink:

10510 frames 46.2483050 seconds 227.2515719 fps, one-second fps min/avg/max: 152 232 304 (336 seconds) # ./xonotic-linux64-sdl
10510 frames 54.8067248 seconds 191.7647886 fps, one-second fps min/avg/max: 146 195 257 (336 seconds) # env MESA_LOADER_DRIVER_OVERRIDE=zink ./xonotic-linux64-sdl

[VirtualLusamine]

Hey none of the thing here helped me. When i open with DRI_PRIME=1 steam, it just constantly crashes for me and doesnt let me play tf2 alone. The only reason i want this is because it makes steam launch every game with the correct GPU always which is ultimately what i want, i dont understand why it doesnt use the correct gpu in the first place but whatever. If i try DRI_PRIME=1 on tf2 launch options is also irelevant as it launches with the integrated gpu regardles. the only way is with steam.

[ryanpetris]

I was able to workaround this problem by running steam with the -cef-disable-gpu parameter. DRI_PRIME=1 steam -cef-disable-gpu works, along with switcherooctl launch -g 1 steam -cef-disable-gpu. Also, launching steam from the normal .desktop file works as well when adding this parameter to the Exec= line.

Edit:

System information: Arch with with kernel 6.5.5-arch1-1; primary GPU is an Intel integrated GPU on a 1360p processor. Secondary GPU is an AMD Radeon RX 6800 in an eGPU enclosure.

P.S. This fix does not work with the steam-native command, which crashes even when running on the integrated gpu.

[normanre]

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/9383#issuecomment-1741845619

it also works in my case but it seems like the dedicated gpu is not used then

[ryanpetris]

Replying to #9383 (comment)

it also works in my case but it seems like the dedicated gpu is not used then

In my case, the dedicated GPU was still used if launched via the normal .desktop launcher (where PrefersNonDefaultGPU is true) or when explicitly enabling it via other methods like DRI_PRIME or switcherooctl.

If you just run steam -cef-disable-gpu without anything else from the command line, unless you have DRI_PRIME set in your environment variables then it is going to use your integrated or otherwise "default" GPU.

[normanre]

Replying to #9383 (comment)

it also works in my case but it seems like the dedicated gpu is not used then

In my case, the dedicated GPU was still used if launched via the normal .desktop launcher (where PrefersNonDefaultGPU is true) or when explicitly enabling it via other methods like DRI_PRIME or switcherooctl.

If you just run steam -cef-disable-gpu without anything else from the command line, unless you have DRI_PRIME set in your environment variables then it is going to use your integrated or otherwise "default" GPU.

DRI_PRIME=1 steam -cef-disable-gpu is the command i used. Maybe my method of finding out if the dedicated GPU is used is flawed.

[Bloodhewk]

I had this issue got it to open using the settings trick that someone said. if you download a game it will also download (steam Linux runtime 3.0 sniper) then it will work normally

[lesar]

Your system information

Steam client version (build number or date): steam-1.0.0.78-1.fc38.src.rpm
Distribution (e.g. Ubuntu): fedora 38
Opted into Steam client beta?: No
Have you checked for system updates?: Yes
Steam Logs: [generate by running this command in a terminal tar -zcvf ~/Desktop/steam-logs.tar.gz ~/.steam/steam/logs]
CPU: AMD Ryzen 9 7900X3D (24) @ 5.660GHz
GPU: AMD ATI Radeon RX 7900 XT/7900 XTX (discrete)
GPU: AMD ATI 19:00.0 Raphael (integrated not connected by cable to monitor)

Please describe your issue in as much detail as possible:

I have installed from fedora repo not Flatpak Steps for reproducing this issue:

try to start csgo2 give this error:

ERROR: ld.so: object '/home/leonardo/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/leonardo/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/home/leonardo/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/leonardo/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/leonardo/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
....  
GLib-GObject-CRITICAL **: 11:34:58.231: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Inconsistency detected by ld.so: dl-close.c: 200: _dl_close_worker: Assertion `(*lp)->l_idx >= 0 && (*lp)->l_idx < nloaded' failed!

Valve csgo windows show on left screen and close to be then show on right screen and close and so repeat showing to the left and then to the right and so on until I stop the csgo2 app.

bets regards
Leonardo

[kisak-valve]

Hello @lesar, you're looking for https://github.com/ValveSoftware/csgo-osx-linux/issues/3268 instead of this issue report.

[lesar]

Hello @lesar, you're looking for ValveSoftware/csgo-osx-linux#3268 instead of this issue report.

Thanks you very match: work!
(I haven't see the post)

[karesosis]

Re-reading this issue report, it should be noted that the common case where DRI_PRIME gets set is from the desktop environment seeing PrefersNonDefaultGPU=true in Steam's desktop shortcut. As a workaround, this can be set to false or removed to avoid this issue.

well i applied this by changing lines to comments.after reboot (as recommended), prime-run steam still gives the same result as in my case #10208.

#PrefersNonDefaultGPU=true
#X-KDE-RunOnDiscreteGpu=true

[chinoto]

@karesosis prime-run is just a more direct way of getting a program to run on a non-default/discrete GPU, whereas those keys in the desktop entry file are ways of indicating to the desktop environment that the program should be launched with prime-run, env DRI_PRIME=1, or some other way of running the program on a different GPU. Until this issue is fixed, you'll just have to run Steam on the default GPU and add prime-run %command% to the launch options of each game that runs via OpenGL. Vulkan (native or translated with dxvk/vkd3d) games should automatically pick the more performant GPU or allow you to choose if native.

[superm1]

I can reproduce this issue with a laptop with two AMD GPUs (Phoenix and 7700S) and launching Steam like this:

DRI_PRIME=1 flatpak run com.valvesoftware.Steam

I haven't seen it mentioned here so I thought I should add that when the issue happens there is a segfault followed by a GPU reset.

[ 1086.416442] Composite Threa[26976]: segfault at 0 ip 0000000000000000 sp 00007f11d9993c38 error 14 in steamwebhelper[400000+10000] likely on CPU 4 (core 2, socket 0)
[ 1086.416457] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[ 1094.281717] Composite Threa[28145]: segfault at 0 ip 0000000000000000 sp 00007fe1471b0c38 error 14 in steamwebhelper[400000+10000] likely on CPU 15 (core 7, socket 0)
[ 1094.281734] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[ 1103.053918] [drm] PCIE GART of 512M enabled (table at 0x00000081FEB00000).
[ 1103.053956] [drm] PSP is resuming...
[ 1103.110556] [drm] reserve 0x1300000 from 0x81fc000000 for PSP TMR

The kernel version is 6.6.6-200.fc39.x86_64, and this is Silverblue, so the flatpak is really the only way to run Steam.

The workaround mentioned above does work for me.

DRI_PRIME=1 flatpak run com.valvesoftware.Steam -cef-disable-gpu

[garrett]

@superm1: I'm also on Silverblue and use Steam from Flathub and have 2 GPUs (one integrated with my CPU and a discrete one.)

While we're waiting for a proper fix, you can set that environment in the Flatseal app. Or you can run a 1-line command to adjust it for you (which does the same thing):

flatpak override --user --env=DRI_PRIME=1 com.valvesoftware.Steam

(Use either 1 or 0, depending on which works for you. This will override it just for your user account; if you are on a multi-user system and want to fix it for everyone on the system, then you'd need to drop the --user and prefix the command with sudo).

In my case, I need to tell it DRI_PRIME=0 (not 1), else it takes a while longer to start (as it looks like it loop crashes a few times until it eventually figures it out after a minute or two).

Here's what it looks like for me in Flatseal (you have to click the + icon first, then enter the variable):

I find that if I set the variable correctly (I tried both 0 and 1; for me it's 0), I don't need to specify -cef-disable-gpu or disable GPU acceleration in Steam's settings (under "Interface").

[Thesola10]

@garrett that's not really a solution, you're essentially telling Steam to run on your iGPU, meaning games won't launch on your dGPU by default, which is unacceptable for many games...

[chinoto]

@Thesola10 A solution would be Valve fixing the underlying issue, but until then we have to settle for these workarounds.

Vulkan (and D3D via translation) games should automatically pick the more performant GPU, so the only games that should be an issue are those that use OpenGL, in which case you simply set env DRI_PRIME=1 %command% or prime-run %command% as the game's launch command depending on your setup.

This has worked just fine for me, though it would be nice to not need it at all.

[garrett]

@Thesola10: I never said it was a solution. It's a workaround you can do meanwhile.

I literally said this near the top to explain that:

While we're waiting for a proper fix, you can

[romeroFan6268]

Well, I see that Linux Mint 21.3 "Virginia" is finally out. However, I am very hesitant to upgrade. I had to struggle quite a bit to get Steam running back to normal on Linux Mint 21.2 "Victoria." Has the new Linux Mint version (21.3 "Virginia") solved theses issues, or does it cause further problems? Just wanted to ask and voice my concern is all...

[chinoto]

@romeroFan6268 This issue is distro (version) agnostic, as far as I can tell.

[romeroFan6268]

@romeroFan6268 This issue is distro (version) agnostic, as far as I can tell.

Yeah, I know. I noticed that this problem started happening with Linux Mint 21.2 "Victoria." All the previous versions ran fine. I was just hoping to know if the new Linux Mint distro (21.3 "Virginia") had the same issue, if it fixed it, or made it worse. I do hope Valve fixes these issues, or that the Linux developers can. I was able to get Steam to run on Linux Mint 21.2 "Victoria" by changing these two lines in the settings to "false," so it'd read:

PrefersNonDefaultGPU=false X-KDE-RunOnDiscreteGpu=false

That did the trick for me. I hope this helps... :)

[chinoto]

I'm betting that the desktop environments in previous versions of Linux Mint hadn't yet implemented the GPU hinting functionality, so Steam's issue with non-default GPUs wasn't being triggered.

[romeroFan6268]

I'm betting that the desktop environments in previous versions of Linux Mint hadn't yet implemented the GPU hinting functionality, so Steam's issue with non-default GPUs wasn't being triggered.

I see. Yeah, that sounds like the problem I was having. Changing those two lines in Steam's settings did the trick for me. I heard others weren't so lucky. I do hope that the Steam developers fix this issue soon... :)

[ninjadev64]

Myself and one other are also experiencing this issue. Setting Exec=/usr/games/steam %U -cef-disable-gpu (leaving all other settings the same) resolved it.

@kisak-valve I think this issue should be prioritised higher as many Linux users not as capable with Google-fu may not be able to find this thread.

[Rua]

I had this issue fixed by setting PrefersNonDefaultGPU=false, but I guess something else updated the file, which broke Steam for me again. At least I'm savvy enough to find this thread, but I agree that most people are not going to be able to fix it on their own.

[romeroFan6268]

I had this issue fixed by setting PrefersNonDefaultGPU=false, but I guess something else updated the file, which broke Steam for me again. At least I'm savvy enough to find this thread, but I agree that most people are not going to be able to fix it on their own.

Just out of curiosity, which Linux distro are you using? Linux Mint Cinnamon 21.3 "Virginia," Ubuntu, or something else? Just wanna make sure which Linux distros are affected by this change is all... :)

Also, for me, I changed the two lines in Steam setup, so it read as followed:

PrefersNonDefaultGPU=false X-KDE-RunOnDiscreteGpu=false

I know you changed the first line to this, but maybe changing the second line as well may help... :)

[Rua]

Just out of curiosity, which Linux distro are you using?

Linux Mint 21.3. But the problem didn't reappear when I upgraded from 21.2, it reappeared more recently.

I know you changed the first line to this, but maybe changing the second line as well may help... :)

Changing only the first line was enough to get it working again for me.

[romeroFan6268]

Just out of curiosity, which Linux distro are you using?

Linux Mint 21.3. But the problem didn't reappear when I upgraded from 21.2, it reappeared more recently.

I know you changed the first line to this, but maybe changing the second line as well may help... :)

Changing only the first line was enough to get it working again for me.

Oh, so you were able to get it working again by changing that line again?

[perroboc]

this happened to me, after restarting. Steam would show a balck window and close it, repeatedly, not being able to show my library. Launching from console worked OK.

What worked for me is that I noticed that my iGPU (the one that comes with the CPU) was suddenly enabled after a restart. Disabling it, as it was at the moment of installation of Steam, fixed everything.

[cemkavuklu]

After @perroboc 's comment, I checked the BIOS and my iGPU was enabled as well (Ryzen 9 7950X3D). Just disable the stupid thing, and you are good to go without any modifications.

[OboTheHobo]

Lot of comments here so apologies if this has been said before, but I found a fix. If you can find a way to launch steam that works (for me launching it from console with the steam command works) and turn off Enable GPU accelerated rendering in web views in the interface setting it will work again if launched with DRI_PRIME=1 or, for me, from the application launcher in KDE.

[romeroFan6268]

Well, it appears that changing the two lines in the Steam setup to:

PrefersNonDefaultGPU=false X-KDE-RunOnDiscreteGpu=false

Well, now it works only once and then quits for good. Steam will not open. I have no idea why. Perhaps it's the new update for Linux Mint, Steam, or both. I have no idea...

In short, the Panel Icon for Steam will not work right.

Also, the start menu application shortcut for Steam does not work either...

Thankfully, I can still get it to work by typing in "Steam" in the terminal, clicking the Steam desktop icon, or by right-clicking the Steam icon on the Panel and selecting "Settings." It will not open any other way (at least none that I know about).

Ay-ya-ya-ya-yai. Such a rigmarole trying to get Steam to work on Linux Mint, you know? Uffda... :(

It seems over time, Steam wants us to use their program less and less. I don't know why. A lot of us don't wanna switch to Ubuntu to run Steam. Plus, from what I've heard, some people are even having problems on there as well...

Even "Minigalaxy" (which is basically the Linux version for GOG Galaxy) does not have any issues opening up...

[Metalfyre]

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/9383#issuecomment-1860142748

This seems to be a solution for me, as for now. But sometimes the issue comes back and the client remains invisible. So I hope this is more of a permanent solution. At least until it is properly fixed

Unfortunenately the problem came back.