eGPU not working properly. Probably issue with BIOS

Framework Laptop 16 Linux
1

Which Linux distro are you using?

Arch Linux

Which release version?
(if rolling release without a release version, skip this question)

2026.02.01

(If rolling release, last date updated?)

2026-02-13

Which kernel are you using?

6.18.7-arch1-1

Which BIOS version are you using?

4.03

Which Framework Laptop 16 model are you using? (AMD Ryzen™ 7040 Series)

AMD Ryzen 9 7940HS
AMD RX7700s

Hi there!

I got an eGPU (Razer Core X V2 w/ RX9070 XT) a few days ago and haven’t gotten it working properly so far. I use a 4k Monitor and wanted to be able to play games a little more performant, than I can with the RX7700s. Also I needed more VRAM for video editing.

In Games like RDR2 and Cyberpunk 2077 and even CS2 I barely hit 20 FPS with the eGPU whereas with the RX7700s I get more than 30 FPS in those games. In CS2 with my realistic settings (medium Graphics + 1080p) I get 120FPS+.

I’m well aware of the USB 4 bottleneck, but I have to assume that there is something else wrong here. The performance is just way too bad to simply blame it on USB4.

I did some debugging and found out that the Laptop 16 seeming doesn’t support resizable BAR:

sudo dmesg | grep -i bar

[  184.767945] amdgpu 0000:0a:00.0: amdgpu: Fetched VBIOS from ROM BAR
[  184.782277] amdgpu 0000:0a:00.0: BAR 2 [mem 0x7410000000-0x74101fffff 64bit pref]: releasing
[  184.782280] amdgpu 0000:0a:00.0: BAR 0 [mem 0x7400000000-0x740fffffff 64bit pref]: releasing
[  184.782345] amdgpu 0000:0a:00.0: BAR 0 [mem size 0x400000000 64bit pref]: can't assign; no space
[  184.782347] amdgpu 0000:0a:00.0: BAR 0 [mem size 0x400000000 64bit pref]: failed to assign
[  184.782348] amdgpu 0000:0a:00.0: BAR 2 [mem size 0x00200000 64bit pref]: can't assign; no space
[  184.782349] amdgpu 0000:0a:00.0: BAR 2 [mem size 0x00200000 64bit pref]: failed to assign
[  184.782351] amdgpu 0000:0a:00.0: BAR 0 [mem size 0x400000000 64bit pref]: can't assign; no space
[  184.782352] amdgpu 0000:0a:00.0: BAR 0 [mem size 0x400000000 64bit pref]: failed to assign
[  184.782354] amdgpu 0000:0a:00.0: BAR 2 [mem size 0x00200000 64bit pref]: can't assign; no space
[  184.782355] amdgpu 0000:0a:00.0: BAR 2 [mem size 0x00200000 64bit pref]: failed to assign
[  184.782439] amdgpu 0000:0a:00.0: amdgpu: Not enough PCI address space for a large BAR.
[  184.782441] amdgpu 0000:0a:00.0: BAR 0 [mem 0x7400000000-0x740fffffff 64bit pref]: assigned
[  184.782455] amdgpu 0000:0a:00.0: BAR 2 [mem 0x7410000000-0x74101fffff 64bit pref]: assigned
[  184.782488] [drm] Detected VRAM RAM=16304M, BAR=256M

And furthermore, I think it doesn’t support above 4G decoding either:

cat /proc/iomem | grep -i "pci bus"
  00000000-00000000 : PCI Bus 0000:00
00000000-00000000 : PCI Bus 0000:00
00000000-00000000 : PCI Bus 0000:00
00000000-00000000 : PCI Bus 0000:00
  00000000-00000000 : PCI Bus 0000:65
    00000000-00000000 : PCI Bus 0000:66
      00000000-00000000 : PCI Bus 0000:67
      00000000-00000000 : PCI Bus 0000:68
      00000000-00000000 : PCI Bus 0000:87
      00000000-00000000 : PCI Bus 0000:a6
      00000000-00000000 : PCI Bus 0000:c3
  00000000-00000000 : PCI Bus 0000:06
  00000000-00000000 : PCI Bus 0000:c4
  00000000-00000000 : PCI Bus 0000:c6
  00000000-00000000 : PCI Bus 0000:c5
  00000000-00000000 : PCI Bus 0000:05
  00000000-00000000 : PCI Bus 0000:04
  00000000-00000000 : PCI Bus 0000:01
    00000000-00000000 : PCI Bus 0000:02
      00000000-00000000 : PCI Bus 0000:03
  00000000-00000000 : PCI Bus 0000:00
  00000000-00000000 : PCI Bus 0000:00
  00000000-00000000 : PCI Bus 0000:00
00000000-00000000 : PCI Bus 0000:00
00000000-00000000 : PCI Bus 0000:00
00000000-00000000 : PCI Bus 0000:00
  00000000-00000000 : PCI Bus 0000:65
    00000000-00000000 : PCI Bus 0000:66
      00000000-00000000 : PCI Bus 0000:67
      00000000-00000000 : PCI Bus 0000:68
      00000000-00000000 : PCI Bus 0000:87
      00000000-00000000 : PCI Bus 0000:a6
      00000000-00000000 : PCI Bus 0000:c3
  00000000-00000000 : PCI Bus 0000:06
  00000000-00000000 : PCI Bus 0000:01
    00000000-00000000 : PCI Bus 0000:02
      00000000-00000000 : PCI Bus 0000:03
  00000000-00000000 : PCI Bus 0000:c4
  00000000-00000000 : PCI Bus 0000:c5
  00000000-00000000 : PCI Bus 0000:04

If I understand this correctly, this means that there are no memory windows assigned to these busses?

I went to dig a little deeper and read the ACPI Tables and decoded them:

sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.dat
iasl -d dsdt.dat

I found this, which kind of confirms my initial suspicion:

                QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite,
                    0x0000000000000000, // Granularity
                    0x0000000000000000, // Range Minimum
                    0x0000000000000000, // Range Maximum
                    0x0000000000000000, // Translation Offset
                    0x0000000000000000, // Length
                    ,, _Y02, AddressRangeMemory, TypeStatic)
                QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite,
                    0x0000000000000000, // Granularity
                    0x0000000000000000, // Range Minimum
                    0x0000000000000000, // Range Maximum
                    0x0000000000000000, // Translation Offset
                    0x0000000000000000, // Length
                    ,, _Y03, AddressRangeMemory, TypeStatic)

There is no above 4G space defined for the kernel to map something to.

I plugged the eGPU into my work laptop (Dell Latitude 5531) and read out the memory mapping which is 0x6000000000-0x60101FFFFF. That is clearly in the above 4G space, so it’s not an issue with the eGPU.

After that, I tried various boot kernel flags to work around those limitations and haven’t gotten lucky. Mostly it just lead to the system being unstable or not booting at all.

Now, I’m out of ideas and really don’t know how to go from here. I’m honestly disappointed that this is even an issue. Unfortunately, the BIOS isn’t open source, so I have no way of solving this issue myself. I’ve seen this post about coreboot: [RESPONDED] Coreboot on the Framework Laptop - #571 by blur.
If that ever sees the light of day I’ll probably switch to that, but in the mean time, do you have any recommendations for me?
Could this issue be fixed. Am I missing something?

2

I’ve used an eGPU in the past and saw games that both had much better performance and much worse performance. I’d recommend testing at least 5-10 different games (ideally on various engines) to see if issues are game specific or not. Additionally, I’m not sure how strong Linux support is yet for current gen GPU’s. Historically, it’s worse than previous gens. If you can, I’d encourage you to also benchmark on Windows just to fully eliminate any configuration issues on the OS side. I get it though, I’m not a fan of Windows either, but this could at least further validate it’s likely a BIOS issue.

3

I’ll try to swap SSDs with my old Windows computer tomorrow.
My laptop has never seen Windows before, and I haven’t used Windows in a long time, so I hope I don’t f this up.

I did test a RTX 2080ti in the mean time, because I don’t own any older gen AMD card and got equally bad performance.
I could test some other cards:

  • Arc A770
  • Arc B580
  • RTX 2060
  • GTX 1050ti

but I figured, that the 2080 ti is closest in terms of performance and is actually a card I used to use for 4k gaming.

The reason I tested those games is, that these are the games I play most at the moment and thus I care the most about. On my Windows drive, I should have a few other games installed (e.g. Fortnite, GTA V and Valorant) and I’ll test those as well then.

For sake of completeness I’ll probably put my Arch SSD into my old computer and try the 9070XT in there. This should rule out any possibilities of OS misconfiguration and current gen support in Linux.

4

Yeah, the 2080Ti shouldn’t have the “new gpu flu” on Linux anymore. I was testing with my 30 series cards and that was fine.

I’ll just note that you may not have a smooth experience moving a windows SSD. Unlike linux, it cares greatly about machine migrations and license agreements, so it may prove difficult to get running correctly. Doesn’t hurt to try though! Should only take a few minutes to swap and test, compared to the ~2hrs it takes to setup a fresh install.

5

I’ve done the testing now.

Windows, apart from the usual Windows problems, runs fine and I get the following results:

  • Cyberpunk 2077 w/ Ray Tracing Ultra & FSR 3 (auto), no frame gen: 60 FPS
  • GTA 5 w/ Very High RT (max settings), no FSR: 100 FPS
  • Fortnite w/ Epic Settings no FSR: 80 FPS

Then I installed the Arch SSD and the RX9070XT into my old computer with an i7-8700K:

  • RDR2 w/ max settings, no FSR : 70 FPS
  • Cyberpunk 2077 w/ Ray Tracing Ultra & FSR 3 (auto), no frame gen: 60 FPS
  • CS2: 200+ FPS

I also turned off ReBAR and above 4G decoding off on my old computer. This leads to a decrease of about 10 FPS in every game.

These results are not exactly what I thought I would get. It seems like the combination:
Laptop 16 + Arch + eGPU is the problem.

The Framework on Windows 11 performs as expected and also shows, that the USB 4 bottleneck is negligible and the hardware is theoretically capable of performing well.
On the other hand the tests with Arch on my old computer show that the amdgpu driver is working just fine and the performance is exactly where I would expect it to be.

So what does Windows do differently that makes the eGPU perform a lot better than Linux?

6

What desktop env. are you using on linux? If it’s not either a recent version of Plasma or Gnome I’d recommend trying those, as they’ve recently implemented (in the last year or so) immediate frame rendering which I believe had a large impact on eGPU performance.

7

I’m using KDE Plasma.

8

Hmm. I’m really not sure then. Sorry :frowning:

At least you were able to narrow it down to a linux specific issue though, which at least means all the hardware is fine.

1 Like
9

After 40+ hours of debugging, trying different kernels (lts, tkg, mainline) and even compiling it from source, I finally found and solved the problem. The reason for the awful performance is actually wayland.

By coincidence I found the following repo:

The readme actually describes my exact problem.
After installing the script and restarting the laptop, everything now works as expected.
I switched to the cachyos kernel, because the USB4 performance is a little more consistent.

Unfortunately, I’ll have to leave some performance on the table due to the lack of ReBAR.

2 Likes
10

I have seen multiple references to reBAR being detrimental to performance on USB4. Here’s just one example.

11

Do you guys know whether it affects Oculink connections? I’m going to try connecting B580, to my FW16 7840HS not sure what to expect. Just ordered it yesterday….

12

That is quite interesting. The majority of reports from Linux eGPU user said, that ReBAR had a pretty positive impact on their gaming performance. Is this degradation something Framework specific, or an AMD USB4 problem?

13

I don’t have any experience with Oculink, but I assume, that the problems are similar. The Framework BIOS doesn’t have an option to set the boot GPU so you probably have to either apply the fix I mentioned above, or use something like this: GitHub - ewagner12/all-ways-egpu: Configure eGPU as primary under Linux Wayland desktops

I didn’t want to use Oculink, because I still want to use my 7700s and I need hot plug support.

As for the B580, from my own experience with it: It is an absolutely stunning card for the prize, but it performs about 30% - 40% worse without ReBAR. Your mileage may vary, but I think that especially for Oculink and Intel Arc cards ReBAR is a must have.

14

I do not know for certain. This is definitely an interesting situation. It is true that the Intel cards pretty much require ReBAR for decent performance, but I have seen multiple references (don’t have time to find them right now) saying that ReBAR is not good over USB4. Not sure if it’s specific to AMD USB4, but I would hazard to guess that most gamers these days are using AMD CPUs.

OCuLink does not have some of the issues associated with USB4 simply because it is a genuine PCIe connection; it doesn’t tunnel PCIe over a USB4 connection. Latency and bandwidth are much better, but you cannot hot plug (you have to shut the machine down to connect/disconnect OCuLink on the FW). Always tradeoffs.

If you are using a FW16 and considering OCuLink, there are multiple threads, and even a custom OCuLink adapter for the dual M.2 expansion bay. Someone is also working on a full custom 8-lane OCuLink adapter for the FW16.

15

What I noticed, that although I’ve enabled hdr in the Plasma settings, my display is often not recognized as an hdr display.

In mpv, media playback of hdr media defauts tho bt.709 with tone mapping. If I start mpv with the following args; mpv --vo=gpu-next --gpu-api=vulkan --target-colorspace-hint --target-trc=pq --video-sync=display-resample hdr suddenly works fine.

With brave I can’t get hdr running at all.

When launching games with gamescope and --expose-wayland the games that support hdr just start with a completely black screen.

All of that did just work before I started using the eGPU.
Do you know what may cause that. I’d really like to get hdr working again.

16

I’ll borrow a GMKtec EVO-X2 from work and try to test the eGPU on that thing. It should support ReBAR as well as USB 4 and runs a strix halo apu, so it should be quite close to the Laptop 16 hardware wise. Unfortunately, that will take a month until I can have it.

17

Unfortunately B580 doesn’t work via OcuLink with 7840HS board :frowning: