GPU Unlock: Restoring GeForce Tensor Cores Before the Driver Loads

By Indie Kings | November 2, 2026

Updated November 2, 2026: gpu-unlock is a Linux kernel module that its author says restores the full FP16, BF16 and TF32 tensor-core rate on GeForce RTX 20, 30 and 40 cards before the NVIDIA driver loads. The project has 14,307 stars, 1,391 forks and 111 open issues, and it does not flash a VBIOS or patch the driver.

Image: GitHub social preview card for the gpu-unlock repository.

What the module changes

The project's premise is stated in its README: NVIDIA ships GeForce cards with their tensor cores limited to half speed for FP16, BF16 and TF32 math with FP32 accumulation, while the same silicon sold as an RTX A-series or professional card runs at full rate. gpu-unlock tries to remove that limit at boot, before the stock NVIDIA driver binds the card.

That distinction matters. This is not a patched driver, and it is not a VBIOS flash. The README says gpu-unlock combines the cmpunlocker V67/PLM technique with the pre-driver timing of a UEFI approach. A kernel module runs early in boot, writes two speed selectors, performs a function-level reset and then lets the unmodified NVIDIA driver load. The project says the change survives driver updates because the driver is never modified.

The repository was created on October 18, 2026, and GitHub lists it at 193 KB. It already has 14,307 stars, 1,391 forks and 111 open issues. The README labels the module and local packaging GPL-2.0-only, while GitHub's license detector reports no recognized license file. The project has one tagged release, an Unraid package published on October 27, and the code is written in C.

The appeal is easy to understand. A used RTX 3090 carries 24 GB of VRAM, and the unlock is aimed at exactly that kind of buyer. The risk is equally easy to understand. This is a kernel-level change to a GPU's boot state, not a settings toggle, and the README's safety case rests on a technical argument rather than a long warranty record.

The README says Ampere support is stable with more than 100 user reports. Ada Lovelace and Turing are marked experimental. Blackwell, including the RTX 50 series, is not supported and the FAQ says support is unlikely to arrive. Windows is handled by a separate, unofficial port that the maintainer does not maintain.

The benchmark claim

The headline numbers are large. The README's table lists dense BF16 matrix multiplication with FP32 accumulation at stock power limits, and it shows gains from 65 percent to 100 percent depending on the card. The numbers below are copied from that table. They are not a controlled benchmark run by Indie Kings.

Card	BF16 before	BF16 after	Gain
RTX 3060 12 GB	27 TFLOPS	51 TFLOPS	+87%
RTX 3080 10 GB	65 TFLOPS	113 TFLOPS	+73%
RTX 3090	75 TFLOPS	125 TFLOPS	+65%
RTX 4070 Ti	81 TFLOPS	150 TFLOPS	+84%
RTX 4090	165 TFLOPS	329 TFLOPS	+100%

The README is careful about the gap between peak rate and real workloads. An RTX 4090 runs out of power before it runs out of tensor cores, so large matrix multiplies at stock power limits gain much less than the peak number suggests. The project lists typical gains of 25 to 55 percent for LLM prefill, 25 to 50 percent for BF16 fine-tuning, 30 to 55 percent for image generation and 50 to 60 percent for FlashAttention or SDPA kernels. LLM token decoding, which is memory-bound, is listed as unchanged.

Those workload numbers come from user compatibility reports filed in the repository's issues, according to the README. That makes them useful field data, not a lab result. A reader should treat the table as the project's claim and check the linked issue threads for the exact card, driver, power limit and workload behind each figure.

The README also says outputs are bit-identical before and after, and that only speed changes. That claim is plausible for a change that alters tensor-core scheduling rather than arithmetic, but it is still a claim from the project. Anyone using the unlock for training or inference should validate outputs on their own workload before trusting a long run to it.

How the boot-time unlock works

The install path is short. The README says to clone the repository and run make install, which detects Arch, Debian or Ubuntu, and Fedora or RHEL families and builds the matching package. The user then appends gpu_unlock.targets=all to the kernel command line, or lists specific PCI addresses such as 0000:21:00.0. The module is placed in the initramfs and loaded before nvidia can bind a card.

At boot, the module writes the speed selectors the README names: SS0 0x88888888, which it says selects the full BF16 rate, and the 4-bit SS1 0x8 IMLA4 selector. It then performs a function-level reset before the NVIDIA driver takes over. The display card is supported, but the screen goes blank from that reset until nvidia-drm starts.

The project uses a generated firmware buffer derived from a pinned CMP reference. The README says builds download NVIDIA and CachyOS inputs over HTTPS and generate firmware only in the build directory and the binary package. The source archive and source packages are built to exclude NVIDIA archives and generated firmware. NVIDIA's firmware remains under its own terms.

Suspend and resume add another layer. Suspend to RAM powers the card off and resets the speed selectors, so the module unlocks the card again before NVIDIA resumes it. The README says this adds about a second to resume. Hibernation is not covered. A laptop that fully powers down its discrete GPU when idle can silently lose the unlock, and the README suggests options nvidia NVreg_DynamicPowerManagement=0x00 in /etc/modprobe.d/ as a partial workaround.

Checking the result is deliberately plain. The README points to journalctl -k -b | grep gpu_unlock for the module log and lspci -nnk -s 0000:[ID]:00.0 for the driver binding. It does not ship a benchmark suite or a validation tool. The user is expected to run a workload and compare before and after.

Supported cards and rollback

Ampere is the safe-ish tier. The README lists the RTX 3050, 3060, 3060 Ti, 3070, 3070 Ti, 3080, 3080 Ti, 3090 and 3090 Ti, plus the RTX 3070 and 3080 laptop GPUs, as stable with more than 100 user reports. Ada is experimental across the RTX 4060, 4060 Ti, 4070, 4070 SUPER, 4070 Ti, 4070 Ti SUPER, 4080, 4080 SUPER, 4090, 4090 D and the 4050 and 4060 laptop GPUs. Turing is experimental across the RTX 2060 through 2080 Ti and Titan RTX.

Blackwell is out. The README says the RTX 50 series is not supported and unlikely to be. That matters because the newest buyers are the ones least able to use the project. A reader with an RTX 5090 should stop at the compatibility table rather than assume the tool will grow into the card later.

Rollback is simpler than install. Removing gpu_unlock.targets= from the kernel command line stops the unlock on the next boot. For a one-off boot, the bootloader's edit screen can remove the argument. Removing the packages also removes the module and the initramfs drop-ins. The README says a card that kept power through suspend to idle remains unlocked and is only read, while a card bound to another driver is left alone.

The risk section is where the project is thinnest. The FAQ says it is very unlikely to hurt a GPU because it only removes a market-segmentation limit, and that standard throttling and power management remain. That is the maintainer's assessment. The README does not cite a failure-rate study, a warranty position from NVIDIA or a long-term test across many cards. It also warns that if the firmware on a card never stops, the module keeps DMA buffers until the next power off and the user should power off before trying again.

The README's security note is worth repeating. It says the GitHub repository is the one and only official source, and that crypto projects, websites and third-party installers are not associated with it. A kernel module that runs before the operating system is a bad place to trust a random download.

FAQ

Does gpu-unlock flash a modified VBIOS?
No. The README says it uses a kernel module at boot, writes two speed selectors, performs a function-level reset and then lets the unmodified NVIDIA driver bind the card. It is not a VBIOS flash and not a patched driver.

Which cards are supported?
Ampere RTX 30 cards are listed as stable. Turing RTX 20 and Ada RTX 40 cards are experimental. Blackwell RTX 50 cards are not supported, and the README says support is unlikely.

Does it work on Windows?
Not officially. The project is Linux-only. The README links an unofficial Windows port but says the maintainer does not run Windows and does not plan to maintain it.

Will it survive a driver update?
The README says yes, because the driver is not modified. The unlock runs before the driver loads and writes the card state at boot. Suspend, hibernation and laptop power management can still reset or bypass it.

Is it safe for the GPU?
The README says it is very unlikely to cause harm and that normal throttling remains. That is the project's assessment, not an independent guarantee. The change is kernel-level, the warranty and vendor-terms questions are not addressed, and a failed run can leave a card in an unexpected state until the next power off.

How do I undo it?
Remove gpu_unlock.targets= from the kernel command line and reboot. Removing the packages also removes the module and its initramfs configuration. The README documents both paths.

Bottom Line

gpu-unlock is a 193 KB Linux project that claims to restore the full FP16, BF16 and TF32 tensor-core rate on GeForce RTX 20, 30 and 40 cards. It works at boot through a kernel module, not through a VBIOS flash or a patched driver. The repository has 14,307 stars, 1,391 forks and 111 open issues, with Ampere marked stable and Turing and Ada marked experimental. Blackwell is unsupported.

The benchmark table is striking, but it is built from user reports and the project's own README, not a controlled independent test. The real-world gains are smaller than the peak numbers, especially on power-limited cards, and memory-bound token generation does not benefit. The install is short, the rollback is documented, and the README is unusually direct about what the tool does not cover.

Our take: this is a serious project for someone who already runs Linux, understands a kernel command line and wants more tensor throughput from an existing Ampere card. It is not a first experiment for a production machine, a laptop with aggressive GPU power management or an RTX 50 card. The 14,000 stars show demand for the idea. They do not substitute for a backup, a recovery plan and a workload test.

Sources

GitHub Zagitta/gpu-unlock README, supported GPUs, benchmark tables, install steps, boot flow, suspend and resume, FAQ and license, accessed November 2, 2026
GitHub API metadata for Zagitta/gpu-unlock, stars, forks, open issues, creation date, last push, language, size and license detection, accessed November 2, 2026
GitHub release unraid, published October 27, 2026, Unraid packaging notes, accessed November 2, 2026
GitHub commit history for Zagitta/gpu-unlock, latest commits through October 28, 2026, accessed November 2, 2026