Hi I am trying to get Resizable BAR working on unsupported motherboards which support it in hardware (PCIe 3.0/Ivy Bridge) so I am creating a DXE driver to setup Resizable BAR right after PciRootBridgeIoProtocol becomes available so that enumeration detects it correctly. So far I have proven it is possible to get it working through a application which sets up Resizable BAR and then loads Windows.
While it works once Windows (with Nimez driver for my RX 580) has loaded it causes some problems such as corrupt/black screen on boot animation and not working at all when using GOP driver (which is a problem since most mobos don’t let you enable 4G decoding and also not use GOP).
So I’m creating a DXE driver to setup Resizable BAR right after PciRootBridgeIoProtocol becomes available. I’ve tested reading settings from Setup variable and BAR sizes with “load -nc” and “bcfg add driver” (testing writing Resizable BAR after PCI Host Bridge allocation will result in crash unless the GPU BAR/bridge window is moved).
I’ve created an FFS by following https://github.com/pbatard/efifs/wiki/Adding-a-driver-to-a-UEFI-firmware but when I insert the module (above PciHostBridge) using UEFITool 0.28 I notice that that while PciHostBridge and every other module have “Attributes: 40h State: F8h” my module has “Attributes: 00h State: 07h”.
Could this cause any problems I want to be careful as I don’t have a BIOS flasher and have to depend on Gigabyte Dual BIOS working in case something goes wrong. I also notice the “S3Restore” module is getting rebuilt when I insert my module. My board is B75M-D3H with F16d GC (beta for NVMe that I found on this forum)
EDIT: All right…show me numbers that confirms the bandwidth/performance on the use of it, ON and OFF, on your system, to then apologize, redraw the “Cosmetic” term and give congrats…but you cant shows us because the system is a mess as you refereed, right?
Thats ok if not possible, i understand.
I’ve read the PCI 3.0 Specification and amdgpu Linux kernel driver. All it takes for Resizable BAR to be enabled is writing the new size to the PCI_EXT_CAP_ID_REBAR extended capability after reading the maximum supported size provided that there’s enough free virtual address space for it.
Linux amdgpu automatically does this and it works my system (though it has to move the BAR and bridge window before to make space). However the Windows AMD graphics driver doesn’t move/resize the BAR and expects the BIOS to do it which is why we see an option to enable it on new motherboards.
I’ve confirmed that Resizable BAR can work in Windows on Ivy Bridge which is shown on my screenshot. It was taken using a older commit of my program (GitHub - xCuri0/ReBarUEFI at 4e9175badbf7a4d75ef6ac4c4c92897dc559b7ae) which works by setting up the BAR and bridge window locations like how Linux does and then resizing it to the maximum size (8GB) before loading Windows bootmgfw.efi.
Using the -s option for GenFfs I was able to build a working FFS. I’m able to resize BARs during PCI initialization but the problem is there isn’t enough MMIOH space free on my system (with iGPU enabled like during PCI initialization) for 8GB BAR so I’m only able to use small sizes like 512mb (still bigger than 256mb but it’s not going to benefit performance).
The FFS driver will probably work on HEDT systems which are more likely to have enough MMIOH space available. FFS driver is on GitHub Releases if anyone wants to try it (configure through setting ReBarState variable).
It should be possible to increase the MMIOH size through modding ACPI tables (AmiBoardInfo) and PciHostBridgeDxe though.
