Has anyone tried an AMD eGPU on Linux and what was your experience with it? I was also looking into enclosures to see a portable gaming solution.
1 Like
AMD has better driver support on Linux than Nvidia, if you buy one of the tested enclosures confirmed to work I can’t see why you would have an issue
1 Like
I don’t have a Framework laptop yet, but I do have an AMD eGPU setup on Linux.
I’m currently running EndeavourOS on Gnome 40 Wayland, and everything seems to run perfectly (Better than previous on KDE X11 at least).
Linux kernel 5.14 brought hot-unplugging of the GPU and there was already support for hot-plugging so I can run this setup perfectly fine even as a portable setup. I’m also using gnome-egpu to handle any switching
Now I haven’t tried this setup yet using the eGPU as the primary display. Currently I’m letting the iGPU on my T480 stay as the primary GPU since I’m only using the internal display. Using PRIME, I can selectively launch which games or programs I want to use the eGPU.
I have a sneaking suspicion that if I were to use the eGPU as the primary display, hotplugging would break the display manager. Though I haven’t tried to confirm this.
As far as gaming goes, I’ve only tried Genshin Impact so far since this is just a temporary setup till my Framework laptop arrives. However, Genshin Impact still runs decently. I can definitely tell that the game isn’t running as efficiently as Windows as I’m getting more frame drops. This could totally be due to the gimped Thunderbolt 3 implementation of the T480 (only 2 PCIe lanes).
Once I get my Framework laptop, I can provide more conclusive information.
2 Likes
Awesome, thanks for the reply! Just curious, how did you get Genshin Impact working on Linux?
1 Like
Some hacky workaround someone created online. Tricks the anti-cheat basically. The creator wants to keep the project hidden from the word of mouth so that the devs don’t pick up on it. However, it isn’t too hard to find the repository on Google.
1 Like
I’m in the current batch to be shipped this month and intend to use Linux with eGPU. I’ll post my experience using an RX 5500XT as that’s what I’ve got on hand atm.
However I haven’t had any eGPU issues with other laptops running 11th Gen Intel.
3 Likes
Some updates on my end.
AMD eGPU support on the Framework seems a bit iffy. I currently have a problem where the laptop won’t post with the eGPU connected.
Meanwhile on the Linux side… AMD eGPUs definitely work more seemlessly on Wayland than xOrg, though I was able to get both to work for the most part.
Wayland first. Recognizing the eGPU itself was plug-and-play on EndeavourOS (Gnome40, Linux 5.14). Though it defaulted to all displays being enabled. On my main setup I have two displays connected to the eGPU and the laptop display itself. On Windows this works pretty seemlessly. On Linux, however, if I don’t disable either the laptop screen or both of the displays on the eGPU, the whole desktop gets laggy. Afterwords, I tried install gnome-egpu to see if that would change anything, but it didn’t.
Meanwhile, on xOrg. A rough experience to say the least. When the setup works, it works great. Once again, I had similar problems when I had all displays enabled. This time, however, occasionally an external display would stop working randomly. To remedy this, I had to install egpu-switcher. Doing so allowed me to manually select which gpu I would prefer to use as my primary display. Internal Display → iGPU. External Display → eGPU. Unfortunately, this does remove any sort of hotplug support or easy switching between the two (restart required).
Speaking of hotplug support. It sometimes works on Wayland and only works on xOrg when only using the internal display with iGPU primary.
1 Like
That’s disappointing to say the least, ideally that’s the setup I would run with
I’ve had reasonably decent results with my AMD eGPU, except random unexplainable freezing running things over Proton (or even Minecraft). But it’s been more or less plug and play with an X11 Ubuntu 20.04 LTS setup.
I tried to get the 7900 xtx working on AMD without much luck. The trick of simply creating a udev rule like with an nvidia GPU didn’t work. I don’t know if it was a conflict with internal dedicated GPU, but yeah it didn’t work.
I successfully managed to use an AMD RX 580 with the Framework 13 i7-1280P using an EXP GDC TH3P4G3 (buy link on egpu.io).
I’m running Pop!_OS 22.04 LTS under Wayland.
In my case, I had to force Wayland to use the eGPU as primary using all-ways-gpu otherwise apps would still start on Intel graphics. Since my setup has 2 monitors (1440p 165 Hz and 1080p 60 Hz) and the dock is meant to be fixed at the desk, I didn’t mind making this switch.
It also seems that for my dock/GPU combo I had to force the GPU to use PCIe 3.0 speeds instead of PCIe 1.1 Don’t ask me why that’s happening, I have no idea. I used the guide from all-ways-gpu here.
Only problem I stumbled upon is that the laptop doesn’t want to go to sleep with the dock connected (even without a GPU inserted in the dock). Made a post about it here.
EDIT: I managed to fix the sleep problem.
2 Likes
Nice to hear the th3p4g3 works with amd and Framework.
I recently bought it with a amd 6600 to use with linuxmint and the Framework 13 1340p.
Somehow i can only use it at pcie 1.1 speeds (2,5gt) instead of the 8gt with tb4 and pcie3x4.
Couldnt manage to fix this Problem yet. I even installed Pop_Os like @TermoZour . Maybe he can help
Did try the above link with the modprobe file but still:
3:04.0 PCI bridge: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge DD 2018] (rev 06)
The speeds advertised by tools like lspci and shown in the kernel logs are wrong at best and confusing at worst.
There is a fix in the GPU driver in kernel 6.8 that helps the performance (but not the reporting to those tools and logs). Please see the commit message for more details.
Is there something similar for nvme? Pretty sure that has a similar problem with usb4 enclosures.
The problem in the GPU driver is that it was artificially limiting the GPU performance based on evaluation of each link speed in the topology.
The idea was don’t use higher performance than the slowest link. This generally works for desktops but when you have virtual links that dynamically change speeds like USB4 but the register values are fixed it’s wrong.
I am not aware of any other drivers doing this but you can check if the nvme stack does this too.
I am pretty sure something is, since with the same enclosure I get 3.8GB/s read on windows and only about 2.8GB/s on linux (and 2.0 a few kernel versions ago). Also there are some lines in dmesg about bandwidth being limited.
The dmesg line should be a red herring.
Can you raise a bug on the kernel bugzilla for the nvme issue? I think it will need nvme, PCI and USB4 CM maintainer comments for where in the stack they think the issue really is.
Not entirely sure how to do that, miay look into it later.
I posted the full dmesg here: AMD Framework and NVMe SSD Enclosure Compatibility Investigation - #38 by Adrian_Joachim
There is also the weird bit about one speciffic ssd (970 evo) not hotplugging only on linux but I am pretty sure those are separate issues.
You can file both of them here:
https://bugzilla.kernel.org/
I think you can mark them against NVME initially, but they might need to loop in people from PCI and USB4 after initial triage from the NVME guys.
2 Likes
Turns out I just tested wrong, apparently dd isn’t enough to saturate the ssd. I used kdiskmark which kooks like a pretty good analog to crystaldiskmark and that one does full bandwidth on linux. False alarm.
1 Like