Resizable BAR (Base Address Register) is a PCIe capability. This is a mechanism that allows the PCIe device, such as a discrete graphics card, to negotiate the BAR size to optimize system resources. Enabling this functionality can result in a performance improvement.
10-15% means you get to buy a cheaper GPU. The fact that we were using a bounce buffer for transfers to a high performance device in the first place seems rather wild to me, although I can understand the legacy reasons
A shame that the one machine I have that I wish to use ReBar on I cannot. The Mac Pro 2019 has a complicated PCI-E topology with PCI-E switches (all bar 2 PCI-E slots on the system go via the PCI-E switch topology) and no ability to tune/enable settings like sub-numa clustering or ReBar. Paired with a signed EFI and the T2 controller things look bleak for getting the most performance out of that system.
It would be pretty neat to get the most out of an NVIDIA GPU in Linux on this platform
From my understanding consumer sandy bridge<->broadwell line was "cursed" when it came to memory controller in general, including flat out not supporting DDR3 spec in full (multiple versions being physically incapable of generating control signals for certain standard-compliant DDR3 modules)
As far as I know, the memory controller IP on the die, as in the part actually interacting with DDR3 channels, didn't change much over that time.
And not including support for bigger ranks probably saved some amount of circuitry or allowed higher speed, just like moving permission checks to happen last before writeback in the CPU core :|
For people (like me) who don’t know what a resizeable BAR is and whether or not they want one: https://www.pcguide.com/gpu/what-is-resizable-bar/
From an Intel support page[0] :
[0] https://www.intel.com/content/www/us/en/support/articles/000...Article quotes a 10-15% improvement in FPS for some popular games.
I’ll wait to invest the time until this is actually a game changer instead of just hype.
10-15% means you get to buy a cheaper GPU. The fact that we were using a bounce buffer for transfers to a high performance device in the first place seems rather wild to me, although I can understand the legacy reasons
A shame that the one machine I have that I wish to use ReBar on I cannot. The Mac Pro 2019 has a complicated PCI-E topology with PCI-E switches (all bar 2 PCI-E slots on the system go via the PCI-E switch topology) and no ability to tune/enable settings like sub-numa clustering or ReBar. Paired with a signed EFI and the T2 controller things look bleak for getting the most performance out of that system.
It would be pretty neat to get the most out of an NVIDIA GPU in Linux on this platform
As much as I’d like to get resizable bar on my Turing GPU, the amount of homegrown “this might work” patching necessary is really off putting.
Great project, but emphasis on Almost[0].
It will not work in the one computer where I need it; On Haswell, 32GB RAM + 16GB BAR is currently not possible[1].
0. https://github.com/xCuri0/ReBarUEFI/wiki/Common-issues-(and-...
1. https://github.com/xCuri0/ReBarUEFI/issues/20
From my understanding consumer sandy bridge<->broadwell line was "cursed" when it came to memory controller in general, including flat out not supporting DDR3 spec in full (multiple versions being physically incapable of generating control signals for certain standard-compliant DDR3 modules)
That sounds pretty bad, as it's 4.5 generations (sandy/ivy bridge, haswell+refresh and broadwell).
Fortunately, it doesn't matter anymore; Moved that 7900gre to my new machine (Ryzen 9800x3d + 2x 48G DDR5 w/ECC).
As far as I know, the memory controller IP on the die, as in the part actually interacting with DDR3 channels, didn't change much over that time.
And not including support for bigger ranks probably saved some amount of circuitry or allowed higher speed, just like moving permission checks to happen last before writeback in the CPU core :|