Arc Rebar: A Boot Time Fix Unlocks Intel Arc VRAM on Legacy Boards

By Indie Kings | October 26, 2026

Updated October 26, 2026: arc-rebar, a boot time tool from developer Rod Burlamaqui, makes an Intel Arc GPU expose its full VRAM on motherboards whose BIOS has no Resizable BAR option at all, and the before and after numbers from its test bench show why anyone who has hit the small BAR wall will want it: a 256 MiB window becomes a 16 GiB one, and a 4K blur filter that stalled at zero frames starts running.

Image: a desktop video card via Wikimedia Commons.

The actual defect, one pinned BAR

The documentation, fetched directly from the project's GitHub repository, does what most work in this niche skips: it explains the failure in full. Intel Arc cards carry an integrated PCIe switch on the card itself, and that switch's upstream port has its own small BAR, 8 MB, which firmware on boards without ReBAR logic places inside the root port's prefetchable memory window. When Intel's xe driver asks the kernel to enlarge the GPU's VRAM BAR, it releases the bridge windows up the chain but never a bridge's own BAR, so the 16 GB request finds its space still pinned by an 8 MB allocation that nothing is using and fails with ENOSPC. The test machine had 63 GB of free address space above 4 GB, and the request still failed, which is the clean proof this is an assignment logic bug rather than a space problem.

How the fix works and what it needs

Intel's own engineers identified the same defect and filed a kernel quirk for it, covering the relevant device IDs 0x4fa0, 0x4fa1 and 0xe2ff, and that patch stalled in review and is not in mainline kernels as of 7.1. arc-rebar does the equivalent from userspace: a plain POSIX sh script that runs from the initramfs at every boot, before the GPU driver loads, writing one PCI register with setpci to select the ReBAR size and then re-enumerating the PCIe root port so the kernel lays out the address map the firmware would have produced if it understood ReBAR. The prerequisites are real and the tool checks them: pci=realloc on the kernel command line, Above 4G Decoding enabled in BIOS, a memory mapped window above 4 GB at least as large as your VRAM rounded up to a power of two, and the card on a dedicated root port with no riser, external switch or Thunderbolt adapter in between. It was written for Debian and Ubuntu with initramfs tools, and porting to dracut or mkinitcpio counts as a modification under its license.

The measured before and after

The verified test bench is the kind of machine this tool exists for: a Supermicro X9DRH-7TF with Intel's C602 chipset, two Xeon E5-2670 v2 processors and a 2015 BIOS, carrying an Arc B580 12 GB on Debian 13 with kernel 7.1.8 and the xe driver. The documented results: the CPU visible VRAM window went from 256 MiB to a 16 GiB BAR2 covering all 12 GB of VRAM, the Vulkan heap went from 11.68 GiB device only plus a 256 MiB host visible scrap to a single 11.93 GiB heap, the largest single OpenCL allocation jumped from 256 MiB to 1 GiB, and measured memory bandwidth in a saxpy workload went from 15 GB/s to 392 GB/s. A 4K Vulkan blur filter in ffmpeg, which had stalled at zero frames, runs between 39 and 50 fps afterward, while VAAPI encode and decode was unaffected before and after. Corroboration matches the data: VideoCardz covered the tool on October 25, 2026, Guru3D on October 26, both treating the numbers as a single developer's test, not a prediction for every Arc owner.

The documentation is also careful about what the tool does not do. It does not make VRAM bigger, since a 12 GB card gets a 16 GB window only because BAR sizes are powers of two and the card offers no 12 GB option; it does not change PCIe link speed, since the test board itself is Gen3; it does not fix the separate VAAPI SIGBUS crash, which is the author's sibling project; and it does not accept firmware updates as an alternative, because the project tested flashing from FWCODE 21.1137 to 21.1182 and Option ROM 23.1051.0.0 to 23.1066.0.0 and the BAR still came up at 256 MB, proving the constraint is host side. Because nothing the tool writes survives a power cycle, it is re-programmed at every boot and there is a norebar escape hatch. The license terms are precisely stated: free for personal use, commercial and enterprise use requires separate licensing under section 9 of the license, no warranty, use at your own risk, and the project credits andersevenrud's public guide to doing the same fix on a Supermicro H11SSL-i as prior art.

Project card

Item	Detail
Project	arc-rebar by Rod Burlamaqui, on GitHub as Intel-ARC-Rebar
Purpose	Expose the full VRAM of an Intel Arc GPU on BIOSes without Resizable BAR support
Mechanism	Initramfs POSIX sh script, one setpci register write plus root port re-enumeration, each boot
Requirements	pci=realloc, Above 4G Decoding, MMIO window above 4 GB, dedicated root port, no riser or external switch
Supports	Debian and Ubuntu with initramfs tools, kernel 6.12 or newer recommended with the xe driver
Test bench	Supermicro X9DRH-7TF, C602, dual Xeon E5-2670 v2, 2015 BIOS, Arc B580 12 GB, Debian 13, kernel 7.1.8
Result	BAR2 256 MiB to 16 GiB, single 11.93 GiB Vulkan heap, saxpy 15 to 392 GB/s, 4K blur filter 39 to 50 fps
Firmware flashing	Tested and proven not an alternative, FWCODE and Option ROM updates changed nothing
Missing upstream	Intel's kernel quirk for device IDs 0x4fa0, 0x4fa1, 0xe2ff stalled in review, not in 7.1 mainline
Safety	Nothing survives a power cycle, register re-programmed every boot, norebar escape hatch
License	Personal use free, commercial and enterprise use separate licensing, no warranty
Repo stats	32 stars, 3 forks, 10 commits

FAQ

What problem does arc-rebar solve?
It gives Intel Arc GPUs their full accessible VRAM on motherboards whose BIOS never offered a Resizable BAR option, without firmware changes, kernel patches or driver changes.

Why did the small BAR request fail with ENOSPC when space was free?
Because an 8 MB BAR belonging to the card's integrated PCIe switch sat inside the root port's prefetchable window, and the kernel releases bridge windows but never a bridge's own BAR when resizing.

Do I have to flash anything?
No, and the project proved firmware updates are not an alternative by testing FWCODE and Option ROM upgrades that changed nothing.

What hardware does it need?
Above 4G Decoding, enough MMIO space above 4 GB, the GPU on a dedicated root port with no riser or switch, and Intel's xe driver on a 6.12 or newer kernel.

Is the setup stable across reboots?
Yes, and deliberately reversible: the register write happens at every boot from the initramfs, so a full power cycle clears it and a norebar mode reverses it.

Is the tool free for everyone?
Personal use is free, but commercial and enterprise use requires separate licensing under the project's license, with no warranty offered.

Bottom Line

The interesting arc of this project is that the root cause was never Intel's GPU or even the old BIOS, it is one line of kernel resource management logic that refuses to release a bridge's own BAR, and the entire community fix is eleven clever bytes of PCI configuration space surgery at the exactly correct moment of the boot sequence. The measured numbers, a sixteenfold VRAM window opening and a zero frame filter reaching playable rates, belong to a single machine, so treat them as a proof of mechanism rather than a promise for every Arc owner, as the coverage from VideoCardz and Guru3D correctly did. Until Intel's stalled kernel quirk lands upstream, this is the kind of tool that keeps perfectly good workstations from becoming e-waste, and its licensing terms, free for personal use but not open source, are honest about whose problem it is willing to be.

Sources

GitHub RodBurlamaqui/Intel-ARC-Rebar README, root cause, requirements, before and after table, license terms
Guru3D coverage of the tool, October 26, 2026