Summary
Recently [Rod Burlamaqui] released the arc-rebar project on GitHub, enabling Intel GPUs to work significantly more efficiently if the system’s mainboard does not support resizable BAR. It does require a Debian or Ubuntu installation and of course a supported Intel GPU. Although the resizable base address register (ReBAR) feature has been part of the PCIe specification for a while, its use was quite limited until Intel released its Arc series of graphic cards. These use this feature to map much more of the GPU’s video RAM (VRAM) into the PC’s address space than the standard 256 MB, assuming that the system is capable of decoding addresses above 4 GB, i.e. allow for 64-bit BARs. For GPU manufacturers like AMD and Nvidia this wasn’t so much of an issue as their GPU designs developed in a world where ReBAR didn’t exist, while Intel’s new GPU generations were designed with ReBAR as a core feature, which naturally cripples performance if the mainboard does not have it enabled during PCIe bus enumeration. This initramfs-based fix runs before the GPU driver loads and performs the requisite BAR configuration. In testing with an Intel Arc B580 GPU on a 2015-era Intel Xeon mainboard the difference between the default and the fixed bandwidth was a bump from a pitiful 15 GB/s to a respectable 392 GB/s, showing how this one fix can breathe new life into older systems. BAR in this case would be a very useful word to have defined. As a computer professional with 30 years if experience, I will have to look that term up. Indeed. It’s clearly not the one related to FOO. It’s in the article, although out of context. “Although the resizable base address register (ReBAR) feature” BAR is base address register. For memory mapped devices, it’s where the system “puts” the device in the global memory address space. On Linux, do lspci -v and the “Memory at X” part is the BAR. Devices can have more than 1 BAR, corresponding to multiple memory-mapped windows. It’s called a base address register because the system actually programs in the base address of the device into a register on the device, as opposed to older devices (pre-PCI, although there might have been a few busses beforehand that had a similar method) where you hard-coded the I/O address using jumpers. The author unfortunately has a superiority complex, and hasn’t realized that sometimes knowing B doesn’t mean you know A. In elementary and highschool most of us take substantially the same courses, and have generally similar upbringings. This creates an opportunity for people to think knowledge of subject matter should be uniform. Instead, it’s a bit like a shotgun, with distinct patterns but sometimes many holes. This particular person also happens to think a learning disability gives them superpowers, and that your lack of understanding has nothing to do with their lack of explaining or providing context. I’m susbtantially done with this author, their diatribe on IPv6 multicast/broadcast was a disgrace to the profession. The article title here isn’t quite right. The problem as described in the actual (LLM-assisted/authored :/) ReadMe is that these specific Arc GPUs have an internal PCIe bridge whose BAR size is fixed to 8MB and which are automatically tied to the pcieport Linux kernel driver. When the xe kernel driver tries to set the GPU’s BAR size, it can’t do it because the PCIe bridge happens to be in an overlapping address range. This script addresses the problem by removing the pcieport kernel driver from that bridge, setting the GPU BAR size manually, and then having the kernel re-probe for devices, at which point it now sees the larger-BAR GPU. It’s a very slick hack, but it’s very Arc-specific and does not at all substitute for the prior art in this field which generically enables ReBAR by injecting DXE modules into the UEFI (i.e. what we usually call the BIOS). Thanks for alluding to the fact that other projects also exist. Do you have any names? Nevermind, I found it: https://github.com/xCuri0/ReBarUEFI A notable difference here is that ReBarUEFI typically requires you to modify your firmware, where as the project in the article, “Intel-ARC-ReBar”, does not seem to have that requirement. However, I find Rod’s licensing weirdness off-putting. He clearly states this is not an open source project. He also has a misunderstanding of how licensing works in general: “Intel Arc B580 Limited Edition. Photo © Intel Corporation, from Intel’s newsroom press kit for the Arc B-Series launch (Dec 2024), reproduced with credit. The photo is Intel’s and is not covered by this project’s licence.” Stating who owns the copyright of something does not give you permission to use that copyrighted material. If the newroom press kit’s license covers your use, then you’re using with permission, not with credit. Then there’s the use of “Intel ARC” in the name of his project. I’m pretty sure this is not a licensed Intel software package. ARC is probably also trademarked. There are a lot of issues here, which makes me question how deep they may go. Enabling ReBAR in the BIOS also helps performance for Nvidia and AMD GPUs.