Okay, figured it out:
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? 
1 Like
Is this BIOS variable flip/patch doable on 13th gen boards? I just got mine and I’m looking into enabling rebar as well.
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.
2 Likes
Hi Tristan, regarding your post about using the A770 on an 11th Gen Framework; may I ask…
- What eGPU enclosure are you using?
- Have you tried gaming on Manjaro? What is the performance like?
Can someone from Framework please post the 13th gen BIOS so we can try the same mod?
2 Likes
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.
Tried digging around - couldn’t find any option for ReBAR in 7040 BIOS version 3.02.
Atleast ya’ll have a bios firmware to mess around with 
(13th Gen Intel user here 
)
(Reposting/quoting Jean’s request in the slightly delusional hope that someone from framework would see it)
2 Likes
I guess 13 owners are forgotten
Here is AMD 13 integrated graphics:
And with Sonnet eGPU enclosure:
Would be nice if we could enable ReBAR support somehow.
1 Like
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)
1 Like
I did try a 5700xt, worked pretty well.
That’s good to hear
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…)
1 Like
Hi! I just found out about this thread and would like to enable Resizable BAR on my Framework 13 Intel 12th gen laptop.
I used the tools to extract the offset and value of the variable to change and found the same values.
However, when I execute setup_var.efi, it fails to modify the variable, telling me the memory is write-protected.
Anyone had this and figured out how to disable this write protection?
Well, have you actually checked which prerequisites are already met and which are not. Specifically the PCIe address ranges for the TypeC PCIe port you are plugging your eGPU into and the TB controller of the eGPU.
Plus the report from GPU-Z on ReBar.
1 Like
Thanks! I looked at the Device manager, base on your example:
So 768 MiB.
Here is the report from GPU-Z:
As a reminder, this is a Framework 13 with Intel 12th gen.
I had this issue too (Framework 13 Intel 13th gen) seems that they flipped the bit on us (thou tbh if Intel waved a gun in Framework’s face, I don’t blame Framework for blinking, for such a niche application it’s hardly worth them fighting intel over it, there are bigger more important battles to fight to benefit the rest of the Framework user base).
I am looking at hacking the bios flash chip and reworking it because damn it I want ReBAR, give me ReBAR or give me firey death 
Just need to save up to upgrade to i7 and then I’ll have a second motherboard to sacrifice to the hardware hacking
Mine is a 13th Gen Intel(R) Core™ i5-1340P, which supports 96GB of ram so definitely should have ReBAR support outside of the “no rebar for laptop” b/s c/o Intel (like with the no >2GB ram on Netbook and no more than 4GB ram on some NUCs both c/o Intel…)
edit rant asside, my lscpu
# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 39 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: GenuineIntel
Model name: 13th Gen Intel(R) Core(TM) i5-1340P
CPU family: 6
Model: 186
Thread(s) per core: 2
Core(s) per socket: 12
Socket(s): 1
Stepping: 2
CPU(s) scaling MHz: 16%
CPU max MHz: 4600.0000
CPU min MHz: 400.0000
BogoMIPS: 4377.60
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm cons
tant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm
2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb
ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clfl
ushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi umip pk
u ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities
Virtualization features:
Virtualization: VT-x
Caches (sum of all):
L1d: 448 KiB (12 instances)
L1i: 640 KiB (12 instances)
L2: 9 MiB (6 instances)
L3: 12 MiB (1 instance)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-15
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Not affected
Spec rstack overflow: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Enhanced IBRS, IBPB conditional, RSB filling, PBRSB-eIBRS SW sequence
Srbds: Not affected
Tsx async abort: Not affected