physicsdolphin/nv-uefi-unlocker
Hardware & IoTA UEFI pre-driver tool that restores NVIDIA RTX tensor throughput on Windows by running a firmware transaction before the driver loads.
This is a Rust-built EFI application for owners of NVIDIA RTX 20/30/40-series GPUs who want to lift the firmware-level cap on tensor issue rate — the author frames the gain as disabled transistors being re-enabled, not overclocking. The unlock is volatile: no flashing, no persistent change, and a full power loss returns the card to stock, so it must be replayed from a USB stick on each cold boot.
What happens in a real workflow
You build a FAT32 USB root with the project's maker script, which regenerates all NVIDIA firmware assets locally from hash-pinned public inputs rather than shipping them. Boot entries on the stick: the tool's BOOTX64.EFI plus family-specific .bin files. From BIOS you disable Secure Boot, boot the stick, and confirm at the prompt (other keys abort; 30 s timeout returns to Windows). A payload file present on the root selects unlock mode; without it the same chain runs in replay/diagnostic mode and still resets the GPU. The tool then claims the card, runs SEC2 scrubber, FWSEC/WPR2, a signed Booter, the V67 four-write payload, read-back verification, FLR, and chains back to Windows. Logs land in \loader.log.
In the mechanism the author describes, NVIDIA's clamp is a hardware gate on the PRI bus (PLM) that silently drops host writes; the only way through is to have signed firmware perform the writes itself, which the UEFI DXE window permits before the driver loads.
Reported results and scope
Measured FP16 GEMM gains are per-card and stated in the compatibility matrix: 4060 Laptop 28e0 29.89 → 49.33 TFLOPS; 4050 Laptop 22 → 38–42; 4060 Ti 2803 46.78 → 75.28; 4070 2709 roughly 2.0× on sm_89 microbenchmarks; RTX 2070 36 → 60–63 TFLOPS on FP32-accumulate GEMM. Many other IDs are only marked as upstream-silicon-verified or unverified, so check your exact device ID and evidence tier before assuming support. Blackwell and GA100 are out of scope.
Conditions and failure modes
- Entry state matters. In hybrid graphics, a cold boot after iGPU-only shutdown leaves the dGPU powered off (D3cold) and the tool aborts; the documented working path is "restart from Windows" or discrete-only mode. The optional
\tx-require-d0.txtmakes warm entries abort with zero writes. - Turing needs a GSP-mode prerequisite — run the bundled script and actually restart (not resume) before unlocking, or the driver can TDR/Code 43.
- The unlock is easily erased by power loss and resets. Linux runtime D3 (RTD3) suspends the GPU into D3cold and silently wipes it after handoff; the README documents a modprobe/initramfs recipe and a verification table. Thunderbolt eGPUs are a known-volatile environment because tunnel rebuilds act like hot resets; native PCIe slots or discrete-only mode are the supported setting.
- Rollback is bounded. The tool writes nothing to ESP or firmware config; a failed transaction means power off fully, do not retry in the same session, then boot Windows normally. The author warns that stacked unlocking plus power/voltage tuning can exceed the card's thermal and power envelope, and accepts no liability for physical damage.
Licence is GPL-2.0-only; NVIDIA firmware is not redistributed and is regenerated from pinned hashes. The maintainer notes they are not full-time and may be slow to respond to issues.
Written by AI from the project's README, updated October 30, 2026. The project's own docs are the source of truth.