ReBarUEFI adds Resizable BAR to UEFI motherboards that never shipped with it

A firmware patch for a missing feature

ReBarUEFI, an open-source project by developer xCuri0, has drawn attention on Hacker News with a straightforward pitch: it brings Resizable BAR to UEFI motherboards that never shipped with the feature. Resizable BAR lets a CPU address a graphics card's full memory pool directly rather than through a small fixed window, cutting transfer overhead; AMD sells the same capability under the Smart Access Memory name. According to the project's GitHub page, the technique produces measurable performance gains, and Intel Arc GPUs essentially depend on it to run as intended.

What the tool does

The project ships a UEFI DXE driver that users insert into their motherboard's firmware image, following a wiki guide, and then flash. Once the modified firmware is running, 4G decoding must be enabled and CSM disabled. A companion utility called ReBarState — available as a release for Windows, or built with CMake on Linux — sets the BAR size, which is stored in an NVRAM variable. The README suggests most systems can use the largest available setting, with smaller sizes as a fallback if a configuration proves unstable.

The README also claims most firmware accepts the unsigned or patched modules even with Secure Boot enabled, so games with anti-cheat protections are not automatically blocked. Owners of NVIDIA Turing cards (RTX 20 and GTX 16 series) are directed to a separate tool, NvStrapsReBar, because those GPUs handle the capability differently.

How it works

The driver is baked into the firmware's DXE volume, so it executes on every boot. At startup it replaces the PreprocessController function of the PciHostBridgeResourceAllocationProtocol with its own version: after calling the original function, it checks whether the installed GPU advertises Resizable BAR capability and applies the size chosen in ReBarState. The PciBus driver later performs PCI enumeration, notices the enlarged BAR, and allocates address space to match.

Patching around firmware limits

Per the README, most UEFI implementations handle 64-bit BARs poorly, so the project includes UEFIPatch-based fixes. These remove artificial 4GB, 16GB and 64GB BAR size caps, stop 64-bit BARs from being silently downgraded to 32-bit, and widen usable MMIO space across a range of Intel platforms: Skylake, Kaby Lake and Coffee Lake boards can use the full 512GB (39-bit) range, as can Haswell and Broadwell after the fix of an earlier 64GB limit, while Sandy and Ivy Bridge systems reach 64GB — sometimes requiring DSDT edits. Additional patches address an NVRAM whitelist issue that triggered a ReBarState error, USB 3 ports failing in the BIOS setup screen on Ivy Bridge through Broadwell boards, and Above 4G decoding on X79.

Without 4G decoding, users are limited to a 1GB BAR — sometimes 512MB, or up to 2GB by lowering TOLUD — and the wiki explains how to surface hidden 4G decoding options in boards that lack the toggle.

Fallbacks and caveats

If an unsupported BAR size stops the system from booting, clearing the CMOS — occasionally removing the battery entirely — disables Resizable BAR again. PCIe Gen2 systems were once thought incompatible, but the README records at least one success on an i5-2500K. Linux users can skip firmware modification altogether: recent kernels resize and allocate GPU BARs automatically when 4G decoding is on, with the pci=realloc kernel parameter and DSDT fixes available for stubborn boards. No equivalent Windows path exists without modifying the BIOS.

On performance, the maintainer reports up to 12% higher frame rates on a test bench built around an i5-3470 and a Sapphire Nitro+ RX 580 8GB, using a modest 2GB BAR. The project credits EDK2, the UEFITool and UEFIPatch suite by NikolajSchlej, Ghidra — used to work around artificial firmware limits — QEMU and OVMF for testing, plus a list of community contributors, and it maintains a list of confirmed working motherboards.

The obvious caveat is inherent to the method: flashing modified firmware carries the usual risk of an unusable board, and results vary by hardware.

Why it matters

Resizable BAR arrived piecemeal: board vendors rolled it out selectively, and large numbers of Sandy Bridge-through-Coffee Lake era systems — machines now often paired with cheap used or entry-level GPUs — were left out entirely. ReBarUEFI turns what vendors treated as a hardware support question into a software patch, and the maintainer's own numbers suggest the gains survive even at reduced BAR sizes, which matters on platforms with tight address space. It is also the practical route to acceptable Intel Arc performance on older boards, since those cards are tuned around the feature. More broadly, the project shows how many firmware limits are policy rather than capability — ceilings a community could locate and remove with a disassembler and a patch file. For owners of otherwise serviceable older hardware, that is a rare free performance upgrade, provided they accept the flashing risk.