BAR 0 means available space when ReBAR is on … and BAR 2 when ReBAR is off
So when ReBAR is not enabled, the CPU only gets access to a limited VRAM portion of the GPU.
Okay interesting, the tool’s BLOB release files work, but when building from source it can’t open the file… sigh
Now, why is this not available in the BIOS settings? Given how far back for older boards some vendors are making this available this makes me very sad.
Also, coreboot?
I have exactly the same experience with my ARC A750 eGPU and an 11th Gen Framework… I jumped through the hoops to get that tool running (did nobody mention that you’ve got to get a UEFI Shell up somehow, too - and learn to use it (hint: it’s like DOS - FS0: is the USB stick, cd to the path, run it like a program, etc)? haha). Admittedly I didn’t get a “Before”, but in the After, it’s got a half-opinion - says it’s disabled in BIOS, but enabled in the specs.
Maybe it’s just confused by Thunderbolt?
BTW, the ARC A750 worked wonderfully (Satisfactory in DX12 at least locked at 60fps - the ARC is full of quirks and in DX11 it was struggling at 20fps, and Vulkan was a corrupt garbage fire) even before ReBAR tweak was applied.
Can anyone who has an AMD mainboard check if there happens to be a ReBAR option in the BIOS? I doubt that they changed it this time but I’m hoping so. It’s really frustrating that they refuse to add a control for it even though it’s already implemented under the hood.
As a Linux user who successfully utilized an 11th gen + rx590 eGPU setup in the past, I would love to see if this 7840U would run well with an ARC A580 or RX6700XT these days. Thank you for posting this data.
Check what address range AMD preallocates to the TypeC PCIe ports. With Intel, this range is by far not big enough to fit any GPU’s full VRAM. That’d need to be solved first. Only then is it a question of whether the BIOS would support ReBar itself (which it actually might, according to some reports here and it detecting ReBar for some eGPUs in some applications, even though it is not working). Unknown if there are deep limitations of the TB/USB4 controllers.
Here the example of DevMgr, view resources by connection:
Only ~450 MiB per port. Such limits have been pretty standard. My desktop Maple Ridge controller uses ~740 MiB (but that is dual port). Still a far cry from 8 or more GiB.
(Note there will be 2 ranges. One is smaller and for IO, the larger one is the one for the actual VRAM)
Maybe of interest here: in my response to FW13 AMD 7040 BIOS ReBAR support
I noticed that my 12th gen Framework now reserves 64 GiB for 3 of the 4 TB/PCIe ports. And the TB3 Alpine Ridge Controller in my Razer Core X gets actually assigned the full 64 GiB if attached directly (for a Goshen Ridge TB4 hub every downstream port gets a third curiously).
I sadly only have an old GPU in my Core X that does not support ReBar. So I cannot test anything else easily.
I am not 100% sure what affected this change, because at the time of my last screenshot here I am quite sure that it was only the ~450 MiB per port I showed there. I am running Windows 11 24H2 and the new drivers from the currently beta 13th&12th gen driver package. So probably one or the other allowed this.
The system may now be more ready for ReBar to actually work.
Although, like I said, the top left port is excluded from that and only gets the previous amount address space for some reason (Intel specs say 42 Bit addressing for the PCIe complex, 39 Bit addressing for physical memory, so at least 512GiB. No reason why it should run out of memory on 32 GiB RAM and 3x 64 GiB of USB4-PCIe reserved…)