[Success Report] RTX 3080 20GB mod (2206/146D) on Windows 11 — UNLOCKED with ReBAR 32 GiB active, 1.75× tensor A/B

[favabean13]

First of all, thank you for this tool! It worked on my memory-modded RTX 3080 20GB — the same ID, subsystem and VBIOS as #163, but on a Z690 board and with Resizable BAR active at 32 GiB using my UEFI modification here https://github.com/favabean13/NV_30_DXE

Tensor throughput went up ~1.75× while the FP32 control stayed flat.

RTX 3080 20GB — GEMM A/B (gemm_bench.py, PyTorch 2.14.1+cu126, N=8192, median of 7 runs)

Precision	Locked	Unlocked	Change
FP16 (FP32 accumulate)	65.4 TFLOPS	114.2 TFLOPS	+75%
BF16 (FP32 accumulate)	66.8 TFLOPS	116.6 TFLOPS	+75%
TF32	32.1 TFLOPS	56.9 TFLOPS	+77%
FP32 (control)	22.3 TFLOPS	22.5 TFLOPS	+1%

All three tensor paths gained the same ~1.75× and the FP32 control didn't move, so the gain is from the unlock, not clocks or power. The locked run was after a full shutdown and a normal boot without the stick, with the same settings.

What was done

Hardware / software

• RTX 3080 20GB memory mod — GA102 10de:2206, SUBSYS 146D10DE, VBIOS 94.02.27.00.14, BDF 01:00.0, PCIe Gen4 x16
• MSI MPG Z690 EDGE WIFI (MS-7D31), BIOS E7D31IMS (H.O0), i9-12900KS
• Windows 11 26H2 build 26300.9711, driver 617.42 (legacy mode, EnableGpuFirmware = 0), Secure Boot off
• Resizable BAR enabled through my own DXE module (NV_30_DXE): it sets the GA102 0x610 frame-buffer override and resizes BAR1 to 32 GiB during PCI enumeration

Steps

1. ssdiag --inventory: ga102 (Ampere) - IN-SCOPE, no pre-flight cautions
2. Built the stick with make-usbroot.ps1 -Family 30 (nv-uefi-unlocker [version]), copied usbroot contents to a FAT32 stick
3. Booted the stick from the MSI one-time boot menu and confirmed at the version screen; automatic handoff to Windows
4. ssdiag in Windows: VERDICT [ampere]: UNLOCKED (override values live) — SS0 0x88888888, SS1 0x00000008, PLM 0xffffffff (OPEN), READOUT_1 full speed, CANARY: cleared + SS live
5. GEMM benchmark unlocked, then full shutdown, normal boot without the stick, benchmark again locked

ReBAR after the unlock's FLR

• BAR1 stayed at 32 GiB (size_idx 15; Windows still shows the "Large Memory Range" 0x6000000000–0x67FFFFFFFF)
• The vendor 0x610 override was cleared by the reset, so the ReBAR capability now advertises only 256M/128M/64M while the current size is 32 GiB
• CPU access was unaffected: a Vulkan test held ~19.25 GiB of VRAM mapped at once, confirmed in dedicated GPU memory in Task Manager. NVIDIA Control Panel still reports Resizable BAR: Yes

[physicsdolphin]

Thanks — recorded. Two things here are worth more than the throughput numbers.

1. The BAR1 behaviour across the FLR is new. The live window (set through 0x610 during enumeration) survives the reset, while the vendor frame-buffer override itself is wiped and the capability falls back to 256M/128M/64M. That matches the model we already had from the PSTRAPS work — power-on default vs. the window written during enumeration — but this is the first time anyone showed the two halves separating in one run, and the 19.25 GiB Vulkan mapping is what makes it more than register trivia. It also means a replay has to set the override again instead of assuming it sticks.

2. The A/B is the right shape: all three tensor paths at 1.75–1.77×, FP32 flat, locked leg from a separate power-cycled boot with the stick out. Nothing about clocks or power can explain a uniform tensor-only gain.

Recorded in docs/compatibility.md (the 2206 row and the GA102 section) and as a bilingual entry in docs/community-reports. Its companion report #210 — same card model, subsystem and VBIOS on a Z790 board with Secure Boot on and a shim/MOK chain — is filed next to it, so the 2206 20GB mod now has a two-platform record.

One request if you still have the machine up: was SizeOfImage untouched by your DXE module, and does the 32 GiB window survive a full power cycle (not just the FLR)? The second one tells us whether the strap side is involved at all, which separates "enumeration-time CTRL write" from "strap reprogram".

Your NV_30_DXE is linked in the entry — it is the only public build of that shape we know of.

[favabean13]

Thanks! Answers below.

1. SizeOfImage: untouched on both sides. I ran your official package unmodified, with Secure Boot off: no .sbat section added and no re-signing, so the loader's SizeOfImage is stock. My DXE module also never touches the card's option ROM, GOP or VBIOS, or any PE image. It only writes PCI config space during enumeration (in PreprocessController, EfiPciBeforeResourceCollection):

a masked RMW of 0x610 (value 0xC80, mask 0xF80 → 0x1001 becomes 0x1C81)
the BAR1 size field in the ReBAR control register (size index 15 = 32 GiB)
S3 boot-script entries replaying those writes (plus the upstream bridge's bus numbers) on resumee
Source: https://github.com/favabean13/NV_30_DXE

2. Full power cycle: the 32 GiB window does not survive on its own. It's re-created on every boot by the enumeration-time CTRL write, with no strap involvement:

Straps untouched: in the ssdiag output, PSTRAPS: BAR1 index 0 = 64MiB ... override_en = 0. The module never writes PSTRAPS or anything in BAR0 MMIO.
Rail-off loses it: before the module recorded S3 entries, every wake from S3 (rail off) crashed with 0x141 → 0x116 until a reboot re-armed it. Once the S3 boot script replayed 0x610 + CTRL, wake worked. So a full power loss clears both 0x610 and the CTRL size, and only the FLR (AON island alive) kept the CTRL size.
Cold boot with the module disabled: BAR1 current 256 MiB, supported 256M/128M/64M.
So it's "enumeration-time CTRL write" (0x610 override + ReBAR CTRL), not a strap reprogram.

Suffice it to say, it did "clear" the override but the large BAR1 window remains after OS and driver initialization.

I hope this helps!