@Kuri0 Hey, thanks a lot for the sources, I’ll also be following Xelafic’s thread about his tests.
I got curious again about enabling REBAR on older gens since in august on Techpowerup we got 2 releases of modded nvflash one of which apparently manages to pull a rather suspicious command which is
–gpumode physical_display_enabled_8GB_bar1
which unfortunately so far just results in an unsupported error for older cards
I think what we need to enable REBAR on Turing and below is mainly a way to edit this part of the VBIOS in the first place and then possibly face NV drivers to make the edit work
PS @chinobino sorry forgot to reply to you anyways, yes I agree that’s extremely unlikely NV ever makes VBIOS updates to older gens, that’s why i’m hoping some point, us the community might be able at to crack trough all these annoying NV soft locks
@Cancretto I had a read through of the Techpowerup thread for ‘(omg)vflash’ before the OP left but it seems that nothing new was discovered as crossflashing was already possible with the modified nvflash.
I have a 2070 with rebar support in my Z370 BIOS but have given up on Nvidia ever adding Turing support.
I too wish the modding community could do something but it seems to be quite locked down.
@chinobino Yeah the tool was interesting but expectations were probably a bit too high for it, we still have Kefi’s nvflasK and his whole NV modding project which hopefully turns out to be really good.
I have a 2070 with rebar support in my Z370 BIOS but have given up on Nvidia ever adding Turing support.
What do you mean by that? Have you managed to mod the 2070 VBIOS or override in some way the 256MB BAR on the card itself?
@Cancretto Sorry I should have worded that better - I just mean that I am stuck with a motherboard that supports rebar but a graphics card that does not.
It could be possible that the method tried by Xelafic on GitHub works on Turing with Windows driver. But it’s hard to setup and test.
But it’s quite complicated to do unlike Resizable BAR (which is just one write to PCIe config space), it requires that the GPU BAR and PCI Bridge both be assigned before PCI allocation to set the BAR size to 16GB or whatever before setting them both back to previous values.
Xelafic’s code is in assembly which I hardly understand.
I think we may atleast see it working on Linux soon because the driver can be modified there (open source).
Remember the NVIDIA driver can enable ReBAR per-game or globally using the NVIDIA Profile Inspector. Of course the feature is meant for RTX 3000 cards, since RTX 2000 has not been unlocked (to use ReBAR). But somehow I expect there’s a chance the Profile Inspector would enable ReBAR in the driver anyway, even for RTX 2000, if ever unlocked…
Here is my translation of the assembly from @Xelafic to plain C:
Warning: this is hardware-specific and I did not test this, looks like I found a bug in there when configuring GTX 1080…
There is one instruction I have skipped, since it changes a local variable on the stack, that is then never used: mov [rsp+0x30],rax
I don’t quite understand much what the resulting code does anyway: looks like the straps bits, documented in envytools and linked by Xelafic, would be able to configure ReBAR.
But before accessing the straps bits some setup is necessary for both the (south / north ?) bridge on the PCI and the PCI GPU, just to expose those bits at their known address.
This setup must immediately be restored after the straps bits (with the ReBAR size) where set.
Let me know if you understand the hard-coded numbers for the bridge … or if you know some MMIO documentation involving the low-level port I/O
So @Kuri0 do you have any idea how to temporarily enable BAR0 (to access the straps bits inside) before BAR1 size is negotiated ? Enough to write code for that ?
Sorry I still do not understand how PCI bring-up works … but somehow I still want ReBAR for my RTX 2000 … (don’t laugh… )