I am looking into purchasing the Intel ARC B580 and connecting it via USB4 and an eGPU Thunderbolt (?) enclosure, or through an OcuLink connection using a Dual M.2 adapter board.
My question is: will it work as intended? I heard that the B580 requires a feature called ReBAR to be enabled in the BIOS, however I wasn’t able to find anything related to it.
Does this make any sense at all, or is it just a waste of money?
Keep in mind framework 16 laptop do not have thunderbolt support. If I understand it right eGPU uses thunderbolt to handle it’s speed to the laptop if so then it might be hard.
The usb 4 spec is an evolution that includes thunderbolt features even though, for marketing reasons, they cannot call it thunderbolt.
I have two thunderbolt devices that work fine when plugged into the usb 4 ports.
So, thunderbolt eGPU will also work, if you get a thunderbolt spec cable.
Couldn’t find any exact list of that. But all i found was statement that when a port isn’t fully certified and fully built to work for thunderbolt then there will be limitations when using thunderbolt docks, even issues.
So far i saw some 1 having dock issue for his 2 monitors so i asked them if the dock is a thunderbolt dock and if so i suggested him to try non thunderbolt dock and see if problem remains if not. Thne that is 1 issue you could get due to USB 4 isn’t fully thunderbolt supported/certified.
Possibly, but I haven’t found one that doesn’t work yet.
Edit: Note I’m speaking specifically on behalf of the Thunderbolt/USB4 functionality. I don’t believe I use anything that needs ReBAR, so that could be an issue with the B580…
I’ll answer my own question just for the sake of history, in case somebody will be looking for an answer )
So I got Intel Arc B580 (Intel Limited Edition card), Minisforum DEG1 OcuLink dock and OcuLink m.2 adapter from kyle_tuck. Connectedd all together and… Nothing. Dead silence. Dock sees the laptop, it turns on and off when laptop is being turned on and off accordingly, Fans on the B580 spin, but other than that - neither Windows 11 nor Linux don’t see the card at all. lspci, dmesg - not even a characther related to the card.
Digging the internet a little bit I came across similar issues here and there. And the official answer from Intel is that ARC GPUs do not officially support OcuLink. If it works - it’s a luck. Seems in my case it’s not (
Unfortunately I don’t have any other GPU to test that dock works at all, and I need to test the GPU itself with the desktop system to eliminate that uncertainty as well… Will keep posting here my observations in case something changes
That is very disappointing to hear. I know it’s a strange thing to say, but hopefully it’s a bad card? Maybe you can get it replaced.
It’s too bad you didn’t go with the Aoostar AG02 dock with Thunderbolt and OCuLink. Would have given an extra data point at least.
And to answer earlier questions about USB4 on the Framework 16, I used it successfully with multiple TB/USB4 docks just fine, and with various cards (RTX 3080, RX 6750 XT, RX 7600 XT, RX 9070 XT). I did not try it with an Intel GPU though.
If that is a legitimate issue and not a user error, that individual should check for firmware updates for both their motherboard (UEFI/BIOS) and the dock. There is a 99% chance that their problems would be resolved with a firmware update. Some rare firmware bugs are usually the problem in such cases like theirs.
I’ve got Intel Arc B580 connected via OCuLink to AOOSTAR AG01 on Linux (NixOS, kernel 7.0.12). Graphics (e.g. Steam) worked out of the box, while compute (e.g. darktable) needed a small kernel patch:
Without this patch, my Intel Arc wasn’t detected as a compute device - clinfo -l showed:
WARNING: Resizable BAR not detected for device 0000:03:00.0
… and turns out this message is wrong!
Framework 16 supports Resizable BAR (aka ReBAR) just fine, it’s just that the Intel driver needs to have 16 GB of continuous address space available and sometimes there isn’t that much laying around. So, say, allocating 8 GB would work fine, but because B580 has 12 GB of VRAM, that number gets rounded to 16 GB and that’s what is being requested through ReBAR.
You can see this by running dmesg - you will see Attempting to resize bar ... and then can't assign; no space:
xe 0000:03:00.0: enabling device (0000 -> 0002)
xe 0000:03:00.0: [drm] Attempting to resize bar from 256MiB -> 16384MiB
xe 0000:03:00.0: BAR 2 [mem 0x8400000000-0x840fffffff 64bit pref]: releasing
pcieport 0000:02:01.0: bridge window [mem 0x8400000000-0x840fffffff 64bit pref]: releasing
pcieport 0000:01:00.0: bridge window [mem 0x8400000000-0x840fffffff 64bit pref]: releasing
pcieport 0000:00:01.4: bridge window [mem 0x8400000000-0x88007fffff 64bit pref]: was not released (still contains assigned resources)
pcieport 0000:02:02.0: disabling bridge window [mem 0x00000000-0x000fffff 64bit pref disabled] to [bus 04] (unused)
pcieport 0000:01:00.0: bridge window [mem size 0x400000000 64bit pref]: can't assign; no space
pcieport 0000:01:00.0: bridge window [mem size 0x400000000 64bit pref]: failed to assign
pcieport 0000:01:00.0: bridge window [mem size 0x400000000 64bit pref]: can't assign; no space
pcieport 0000:01:00.0: bridge window [mem size 0x400000000 64bit pref]: failed to assign
pcieport 0000:02:01.0: bridge window [mem size 0x400000000 64bit pref]: can't assign; no space
pcieport 0000:02:01.0: bridge window [mem size 0x400000000 64bit pref]: failed to assign
pcieport 0000:02:01.0: bridge window [mem size 0x400000000 64bit pref]: can't assign; no space
pcieport 0000:02:01.0: bridge window [mem size 0x400000000 64bit pref]: failed to assign
xe 0000:03:00.0: BAR 2 [mem size 0x400000000 64bit pref]: can't assign; no space
xe 0000:03:00.0: BAR 2 [mem size 0x400000000 64bit pref]: failed to assign
xe 0000:03:00.0: BAR 2 [mem size 0x400000000 64bit pref]: can't assign; no space
xe 0000:03:00.0: BAR 2 [mem size 0x400000000 64bit pref]: failed to assign
pcieport 0000:00:01.4: PCI bridge to [bus 01-04]
pcieport 0000:00:01.4: bridge window [io 0xa000-0xbfff]
pcieport 0000:00:01.4: bridge window [mem 0x90000000-0x910fffff]
pcieport 0000:00:01.4: bridge window [mem 0x8400000000-0x88007fffff 64bit pref]
pcieport 0000:01:00.0: PCI bridge to [bus 02-04]
pcieport 0000:01:00.0: bridge window [io 0xa000-0xbfff]
pcieport 0000:01:00.0: bridge window [mem 0x90000000-0x910fffff]
pcieport 0000:01:00.0: bridge window [mem 0x8400000000-0x840fffffff 64bit pref]
pcieport 0000:02:01.0: PCI bridge to [bus 03]
pcieport 0000:02:01.0: bridge window [io 0xa000-0xafff]
pcieport 0000:02:01.0: bridge window [mem 0x90000000-0x90ffffff]
pcieport 0000:02:01.0: bridge window [mem 0x8400000000-0x840fffffff 64bit pref]
xe 0000:03:00.0: BAR 2 [mem 0x8400000000-0x840fffffff 64bit pref]: old value restored
xe 0000:03:00.0: [drm] Failed to resize BAR2 to 16384MiB (-ENOSPC). Consider enabling 'Resizable BAR' support in your BIOS
xe 0000:03:00.0: [drm] Found battlemage (device ID e20b) discrete display version 14.01 stepping B0
xe 0000:03:00.0: [drm] VISIBLE VRAM: 0x0000008400000000, 0x0000000010000000
xe 0000:03:00.0: [drm] Small BAR device
In my case the problem was caused by this:
pcieport 0000:00:01.4: bridge window [mem 0x8400000000-0x88007fffff 64bit pref]: was not released (still contains assigned resources)
… and that’s what that patch above fixes - it makes it possible for the kernel to release this “occupied, but not really” block, which then leaves just enough address space to allocate 16 GB via ReBAR.
I’ve tested this setup by running Cyberpunk, Helldivers 2, and llama-cpp (via vulkan backend) - everything seems to be working fine so far.
wow, that’s sounds very promising, cant wait to try it out! I wish I knew how to apply this patch tho :)))) Will’ try to figure it out. Hopefully it’ll help to run OpenCl in linux, because I run Folding@Home 99% of the time. But because it doesn’t work in linux I have to run it in windows
I discovered another interesting quirk about PCIE lane speed.
When PCIE Dynamic Link Power Management is ON in BIOS - I can only get PCI-e x4 1.1 speed in Windows
