Currently I don’t have any multi-GPU device so I can’t test it myself but the bug is still open New steam UI does not open if run with DRI_PRIME=1 · Issue #9383 · ValveSoftware/steam-for-linux · GitHub
Just tried it, it indeed has issues, the ui doesn’t come up but I can still launch games from tray icon which then run on the egpu. Very weird, have not found a progam that didn’t just work with DRI_PRIME
Just to clarify to people here what exactly the mux is on Framework 16. It controls which GPU the eDP connects to. You really don’t want this exposed in the BIOS because hardcoding it to dGPU means your dGPU would never go into the lowest power state. Your battery life would be abysmal.
In Windows Radeon Software will let you set up policies that when you launch certain games it would automatically toggle the mux so that your dGPU spins up and eDP is connected to the dGPU. The whole thing is seamless on Windows.
The game (of course) runs on the dGPU. You end up with “less latency” than a regular hybrid graphics setup because you don’t make the round trip from one GPU to another to render content. The idea is supposed to be that when you have a very high refresh rate display (like 165Hz) that you can take full advantage of that.
In Linux this isn’t exposed today; and it’s mostly because of complexity. The kernel driver would in theory see hotplug events on both the iGPU and dGPU, but it wouldn’t be a pretty experience. You would see flickering because you would go through two modesets.
In Linux the DRM master (the compositor) is in full control of kernel mode setting. What would really need to happen is the system has to advertise a DRM property that it supports this mux switch and then the compositor would need to orchestrate the action to ensure that you don’t go through modesets.
Then lastly you would need a way for the compositor to advertise this ability to applications and the applications would need to opt in by using some compositor specific interface.
So like I said; a lot of complexity, a lot of projects would need to develop code and an architecture to support it.
11 Likes
I use the BIOS option to toggle dGPU only mode on my Razer when I’m gaming on the device and want maximum performance without the input delays from using the iGPU as a middleman. This is doubly an issue if the iGPU and dGPU support different resolutions and refresh rates. In this scenario, a battery is not necessary.
For the sake of software simplicity, it can be beneficial to completely eliminate either the iGPU or dGPU from the system before the OS is loaded to avoid software compatibilities issues. If things work as intended, this wouldn’t be necessary, however in my experience they do not. I’ve yet to try it on the FW or with an AMD gpu.
3 Likes
Yeah if you want such an option knowing the relevant trade-offs then it’s conceptually possible for Framework to add it to BIOS. Hopefully my above description explains why it’s “not” there though.
Huh? The resolutions and refresh rates are based on what the panel supports not the GPU.
2 Likes
On my Razer laptop, the iGPU only supports 60hz refresh rates meaning that if the dGPU output is going through the iGPU it’s also capped at 60hz. A mux may help with that, but having not used a mux before I would guess that it also matters if the content is rendered in exclusive fullscreen or not (which seems to be growing less common). Hence why I prefer having an override option available as well.
I’m well aware that using only the dGPU would increase power consumption. However, this is exactly how MUX used to work before AMD SmartAccess Graphics and NVIDIA Advanced Optimus were introduced. The difference between a MUX laptop and a MUXless one meant having this option, usually in the BIOS, sometimes via software. The MUXless laptop could only offer two modes: iGPU only or hybrid mode. In contrast, the laptop with MUX allowed you to choose from three modes: iGPU only, hybrid mode, or dGPU only. So, that’s what I expected when I read that Framework 16 is going to have a MUX.
It’s nice that AMD is trying to automate the switching process, but that doesn’t mean we have to lose manual control. If you look at this list, you’ll see that a laptop with a MUX without manual toggle it is very unusual and certainly not common.
1 Like
Nothing specific for me to add at this time.
I will say this. Mario knows what they are talking about. He is an expert on these topics.
I wanted to make sure everyone here is aware that Mario is speaking from a place of deep experience. Please engage in healthy conversation if all parties can continue to keep it friendly, but I want to be crystal clear on this.
Okay, continue on folks.
10 Likes
Just to put this out there - this is correct.
8 Likes
I had no doubt that Mario was correct, well, except for this part:
I’m not an expert on how Linux handles graphics cards, but I also think that adding support for automatic MUX switching to Linux would be complicated, so probably we won’t see it anytime soon. That’s why I asked about manual MUX switching in the BIOS. In my opinion that’s the only way for Linux users to benefit from having a MUX. From my point of view, it’s a pity to have a MUX chip and all DisplayPort pins in the expansion bay and not being able to use them.
Wouldn’t connecting a monitor to the USB-C port on the dGPU also prevent the dGPU from going into the lowest power state?
1 Like
Yes. The difference is that is just while it’s plugged in. However if you have a BIOS switch it’s for the “whole boot”.
6 Likes
This whole thing kinda bums me out, I didn’t even know that Linux won’t use the mux. I was pretty stoked since this was going to be my first machine with one.
2 Likes
Framework Laptop 16 is an unusual case. Linux can utilize MUX because MUX itself is OS-independent, but it cannot utilize NVIDIA Advanced Optimus or AMD SmartAccess Graphics because they are available only for Windows. So the problem is not MUX itself but how you control the MUX.
When laptops with switchable graphics cards started appearing, having MUX was the only way to use the dGPU on Linux because MUX controls which graphics card is connected to the monitor, and MUX toggle was usually in the BIOS, making it OS-independent. In contrast, MUXless “switching” aka hybrid mode, works by the dGPU not being directly connected to the monitor but sending the resulting data to the monitor through the iGPU, which required OS-level support. So for a long time, it didn’t work properly on Linux. I had one MUXless laptop, and GPU switching on Linux worked so terribly at that time that since then, I’ve only bought iGPU-only laptops. But from what I’ve heard, it is working quite well these days.
As Mario mentioned, sending data to the monitor through the iGPU adds latency, and I think it also prevents Nvidia G-Sync and AMD FreeSync from working. So a couple years ago, Nvidia introduced NVIDIA Advanced Optimus, and AMD recently responded with SmartAccess Graphics. The idea is that instead of sending data to the monitor through the iGPU, the GPU driver itself switches the MUX. The problem is that this currently only works on Windows, and for some to me unknown reason, Framework has decided to rely solely on this solution and not offer an alternative option to control MUX in the BIOS.
So having MUX is an advantage for a Linux laptop unless it is the same case as Framework Laptop 16.
So unless I switch the mux to the dGPU in the bios, which the 16 may not have an option for, the display signal will be going through the iGPU thus defeating the point of having a mux? Which to my mind means the dGPU would still be worthwhile but the mux would be doing nothing, or am I still off?
You’re right. It’ll basically work like a MUXless laptop. So you can tell the application to use dGPU by using DRI_PRIME=1. For example, like this DRI_PRIME=1 cheese. This works for most applications although there are exceptions. For example Steam can’t be launched this way.
This is worrying because I suspect that dGPU passthrough (VFIO) is not going to work.
I don’t see why that would be the case. This is about the mux control for the eDP.
5 Likes
Luckily I never needed a gpu passthrough. Proton and Bottles have managed to run everything I’ve needed so far. I thought the gpu passthrough didn’t need the MUX but it’s mentioned in some guides. For example: [GUIDE] Optimus laptop dGPU passthrough · GitHub
I’m wondering, suppose someone creates another dGPU module based on Nvidia or Intel. How would the MUX switching be handled then? Would AMD software work with a GPU from another manufacturer?
Sorry to probably keep asking the same question as everyone else, but under Linux, will we be able to use the external Display Port USB c to drive a monitor for games? Will it have the same latency as in Windows (I’m wondering from your comment about the refresh rate and latency for dGPU vs iGPU)? I’m not familiar with what a MUX is, but the concept of the path needing to go from dGPU to the iGPU, then to the monitor makes sense that it would add latency.
Does the DRI_PRIME flag address this for specific apps (by telling the compositor to use the dGPU or something)?
Again, apologies for my ignorance. I’m just curious about being able to use that eDP for monitors and gaming in Linux.
EDIT: I’m sorry, I took ‘eDP’ to mean External Display Port (like the usb c on the back of the dGPU). Apparently this is something else altogether?