[1] Intel GPUs actually can't work without it, because they do not have legacy "windowing" mode where portions of 256MB BAR window are mapped to different areas in GPU memory
[2] This tool implies that it's possible to handle root port side entirely in firmware, but it's new to me at least, so I can't vouch for that :)
Other similar mods included adding NVMe Boot capabilities to older Firmwares that didn't supported them so that you could boot from modern NVMe drives if you used some kind of adapter (As none of those Motherboards have M.2 Slots, but you can use them with a PCIe-to-M.2 adapter card). Also adding required stuff to get certain CPUs booting in Motherboard that were never officially supported (Depending on generation, could be as simple as adding new CPU Microcode).
(Posting this under the assumption others will also appreciate a bit of quick context.)
GPUs has been using a 256 MiB PCI MMIO window regardless of how much VRAM they actually have since... nearly forever? At least since PCIe is a thing, since I recall than AGP Aperture Size was seteable in era accurate BIOSes. PCIe 3.0 specification introduced a feature known as Resizeable BAR, where the PCI Device can tell a compatible Firmware how much MMIO it actually wants. GPUs uses that to tell a ReBAR capable UEFI Firmware that it wants more MMIO (Usually as big as the GPU VRAM), or uses legacy 256 MiB otherwise.
Sounds scary. Like there is a good chance to brick the motherboard permanently. I think i'm going to skip this for my ye olde pc with crappy GTX 1660 Ti card. Can't afford a new system.
I moved away from chrome a while ago, but last time I installed it on linux it was a pain, and firefox and its derivatives are essentially at feature and speed parity or better than chrome across the board.
[deleted]
Claude tells me the BAR is outside the encrypted part of the card firmware so theoretically should be possible?
https://www.downtowndougbrown.com/2026/08/fixing-an-emachine...
https://www.tomshardware.com/pc-components/cpus/modder-uses-...
Coreboot in desktops is perhaps in the best shape it has been in more than a decade because you have the MSI Z690-A/Z790-P series for LGA 1700 (Which were current gen when released, and still viable if you want Intel with DDR4, albeit the boards aren't available in retail anymore) and the recently released port for the MSI B850-P for AM5 Phoenix. It was a major leap from previously, where it only supported ancient platforms or unobtanium reference boards. I bashed Coreboot a lot for that, but now you actually have usable options. Same with Servers, with the Gigabyte MZ33-AR1 for AMD Turin. When was the last time you saw Coreboot running on current gen boards available in retail, if ever?
(Incidentally this is also one of my gripes with the Intel Macs, wanting to put Linux on one but having zero configurability pre-OS is a huge pain. Meanwhile a standard PC BIOS with the equivalent hardware has plenty of options. Maybe I'll get around to (vibe)porting a regular BIOS to mine...)
If you want to you may want to point your vibes for vibecoding towards making a libpayload universal menu for Coreboot , that way you at least conform with the architecture.
https://youtu.be/eSz2VPH64SE?t=343
https://docs.dasharo.com/dasharo-menu-docs/dasharo-system-fe...
I do recall hearing the same thing than you but for those that used SeaBIOS and needed to recompile and reflash just to change boot order...
e.g. they do seldom if ever take patches for adding support or fixing issues in older boards. They just sit there ignored.
A fork or entire new project with different focus is sorely needed.
[dead]
And if my experience from embedded development is in any way transferable, they're probably fairly spread out and probably takes a fairly big chunk of address space too.
MMIO (Memory Mapped I/O) is essentially memory (Whenever RAM or ROM) from OTHER devices that is directly visible on the CPU Address Space. My understanding is that from the CPU side, MMIO is mostly transparent (Except for the massive increase in latency) because it gets used like if it was interacting with its own workspace with regular instructions like MOV.
What PCIe ReBAR changes is that before, you could only see a 256 MiB window onto the GPU VRAM, so there was an added overhead since the GPU may need to relocate things from inside that window somewhere else on its total VRAM (So yes, it may be interpreted as if what you see from the CPU side is just some kind of exchange buffer). I believe the best way to describe how it operates is comparing it to EMS (Expanded Memory) from the DOS days since it also worked with a similar, if not the same idea. You could only see a portion of the total memory from what was installed on the EMS card (A 128 KiB window located on the upper part of the 1 MiB address space from the 8086 CPU), so you had to switch which Page (Region) of the memory was visible, adding a lot of overhead and most likely requiring an additional buffer in main RAM to move data from one Page to another. However, since I have no knowledge if the GPUs really work like that I can't confirm. I never knew whenever the 256 MiB is "fixed" (You always see the same Region) or if you can decide which section of the VRAM to make visible.
Most PCI devices expose some memory and/or I/O ports to the CPU. That memory (or I/O ports) is mapped to somewhere in the address space visible to the CPU. Besides the memory and I/O ports, all PCI devices also expose a separate set of configuration registers; among these registers, there are the Base Address Registers (BARs), which configure where the memory or I/O ports is mapped.
Here's an example output from "lspci -vv" for a GPU:
Region 0: Memory at 7c00000000 (64-bit, prefetchable) [size=8G]
Region 2: Memory at 7e00000000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at f000 [size=256]
Region 5: Memory at fca00000 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at fcb00000 [disabled] [size=128K]
Capabilities: [200 v1] Physical Resizable BAR
BAR 0: current size: 8GB, supported: 256MB 512MB 1GB 2GB 4GB 8GB
BAR 2: current size: 256MB, supported: 2MB 4MB 8MB 16MB 32MB 64MB 128MB 256MB
Why is this useful? This particular GPU has 8GB of VRAM; it's quite obvious that region 0 is a direct view into that VRAM. When using the maximum BAR size, the CPU can directly read and write anywhere into the VRAM; when using a smaller BAR, the CPU can only see a small window into the VRAM, and has to use less direct methods to access it.
(As an aside: go right now and do a "sudo lspci -vv" on your computer, if you see a Resizable BAR capability which isn't using the maximum size, you can probably gain a bit more speed for free by going into the BIOS and enabling "Resizable BAR" and/or "Above 4G decoding". If you can't find these options, well, AFAIU that's what this project is all about..)
IIRC Linux doesn't need resizable bar enabled in the BIOS since the kernel will resize the bar if supported by the GPU, Windows however relies on the UEFI doing it which is where it being enabled in the BIOS is needed.
[1] This is nothing new in the tech industry. Intel rebrands DVFS as SpeedStep, IOMMU as VT-d, AMD rebrands the NX bit as Enhanced Virus Protection, etc.
It's not like ReBar is a single toggle "Make Things Faster", but a different option in how it can map gpu memory to the cpu. The driver still needs to use it - and decide where it's use vs the "staging buffer" approach would actually be be benefitial.
Isn't it just being able to shift the window of GPU memory visible to the CPU?
If a program runs slower when you give it more RAM, the problem isn't giving more RAM.
Literally the second sentence in the repo:
> This provides performance benefits and is even required for Intel Arc GPUs to function optimally.
What is a BAR let alone a resizable one? Readme just jumps in, which is fine, but I’m not sure why this is on HN or why I should care.
In the old days, they were a fixed size. If your GPU has 16 GB of ram and you want to access all of it via memory addresses, you'd need a 16 GB BAR ... but lots of (older) systems wouldn't be able to map in a large BAR because of a lack of address lines (or wahtever), so GPUs had stayed with 256MB for VRAM access because it was compatible. With a smaller BAR than the VRAM, you have to use some sort of windowing / paging setup. Resizable BAR lets the BAR start small so older systems will work, but grow larger with capable systems.
Much better than having a jumper to set the BAR to big or small, and you can skip VRAM window management.
reports on github show 0% speedup for 1xxx series
There do exists individual users that work on newer stuff, after the MSI Z690-A / Z790-P there were 2 people that did ports for H610 since at that point the platform was supported and they only had to port the Motherboard. However, they are rather rare, since the kind of user that Coreboot seems to attract are from the privacy and security anti-ME/PSP crowd that don't even want to use newer platforms, which is the exact opposite of my view.
A lot of the work companies does may be just for their internal systems or reference platform and these may not get to the hands of end users, ever. I still recall Phoronix articles covering Coreboot releases always taking a jab at the new supported Motherboards until the MSI Z690-A DDR4 port from 2022.
[1] https://en.wikipedia.org/wiki/Advanced_eXtensible_Interface
For historic reasons (e.g. 32 bit address spaces, plus the need to reserve the space for multiple pci peripherals) it has been a narrow, movable aperture.
Resizable BAR lets the size of the aperture be chosen (which is usually chosen to allow all of VRAM to fit in and be directly accessible).
When you insert a GPU into a PCIe slot, the memory mapped regions in memory can't be put in a hard wired location because any arbitrary device can be inserted and it can provide an arbitrary amount of memory (yes the GPU provides its own memory to the CPU). A BAR reserves a memory mapped region in the CPU space that is backed by the PCIe device.
When the BAR is smaller than the memory of the inserted device, the CPU cannot communicate with all of the memory on the inserted device directly anmore. This means if you want to perform a write to a region in the GPU outside a BAR region you have to go through the BAR region anyway. It's not a RAM buffer for PCIe packets.
>I assume it's not like memory mapped peripherals on an AXI bus which is why you need the buffer?
The PCIe controller is an AXI peripheral...
Wasn't helped by my experience reacting very strongly to story of early Arc drivers being problematic because the devs were too used to GPU being just a ring-bus away ;-)
Also, ReBAR can get complicated as you can see from other responses above. The articles on the web are also not really good as they tend to replicate marketing material and make vague statements about performance, but fail to explain how specifically performance is improved.
Same as his: to voice my frustration about something on the internet.
Wrong.
> I'm still clueless on what the purpose and use-case is for ReBAR
Are you seriously debating this?
Or to put it differently, I would take the sentence "He asked for a purpose and a use-case not an explanation." and replace the word "not" with a comma.
I agree with "He asked for a purpose and a use-case". (This is what your quote supports.)
I disagree with "not an explanation".
When asking for a purpose and use case, they were asking for an explanation.