gpu-unlock Linux module doubles FP/BF16 issue rate on RTX 3000 cards

gpu-unlock, a GitHub project hosted under the Zagitta account, is a Linux kernel module that unlocks the FP/BF16 instruction issue rate on Nvidia's RTX 3000-series cards, bringing it up to the rate of their professional equivalents. According to the README, the effect is that it doubles the instruction issuing speed of FP/BF16 FMA into FP32 operations on GA102, GA103, GA104 and GA106 cards.

The technique combines two earlier ideas. It takes the CMP unlocker's V67/PLM method and pairs it with the pre-driver timing of the UEFI approach. The module runs the unlock, writes the speed selectors (SS0 0x88888888, which selects the full BF16 rate, and the 4-bit SS1 0x8 IMLA4) and performs a function-level reset (FLR) before the unmodified NVIDIA driver binds the card. It is neither a UEFI application nor a patched NVIDIA driver. The README says the benefit of this early kernel-module approach is that it does not require manual patching each time Nvidia releases a new driver version.

The README includes a table of results reported by users, headed by a 3090 Ti dense 8192³ GEMM benchmark at 450 W (five-sample medians, FP32 accumulation). The module accepts every GeForce ID listed in kernel/gpu_unlock/main.c, but the table covers only the cards someone has reported on, and the project asks owners to add a compatibility report whether the unlock worked or not. The README stresses that the gains are dense GEMM throughput from each report's own benchmark, so they are not directly comparable. The power limit matters a lot: the lowest figure (+25%) comes from cards capped at 225 W.

Matrix-heavy work speeds up: LLM prefill (+14 to 36% in reports #9, #15, #25 and #33), diffusion and FlashAttention. LLM decode, which is limited by memory bandwidth, and INT8 work stay about the same. The reports that compared outputs found them bit-identical before and after. Reports also cover up to four cards in one machine, the card driving the display, and cards passed through to a VM with vfio-pci (#17).

Installation is a clone and a build: git clone, cd gpu-unlock, make install. The make target detects Arch, Debian/Ubuntu or Fedora/RHEL/CentOS families from /etc/os-release and builds and installs a package; explicit make install-arch, install-deb and install-rpm targets exist for other cases. Every build downloads pinned NVIDIA/CachyOS inputs over HTTPS and checks their SHA-256. The module then does nothing unless the kernel command line opts in with gpu_unlock.targets=all (every unbound GA102/GA103/GA104/GA106 card) or a comma-separated list of PCI addresses as lspci -D prints them. The packages put the module and its firmware into the initramfs so it loads before nvidia can bind a card; mkinitcpio, initramfs-tools and dracut are supported.

At boot, cards are unlocked concurrently, in about a second in all however many there are, each on its own; a card that is already bound or powered down is skipped. The display card works too, but its screen is blank from the reset until nvidia-drm takes over. Suspend to RAM powers the cards off and resets the speed selectors, so after resume the module unlocks again every card it unlocked at boot, adding about a second to resume. Hibernation is not covered. Loading the module by hand after boot does nothing to a card that nvidia has bound. To stop unlocking, remove gpu_unlock.targets= from the kernel command line.

The kernel module and local packaging are GPL-2.0-only. The generated payload derives from the pinned CMP reference, and NVIDIA firmware remains under its own terms.

Key facts

gpu-unlock is a Linux kernel module that, per its README, doubles the instruction issuing speed of FP/BF16 FMA into FP32 operations on GA102, GA103, GA104 and GA106 GeForce cards.
It runs the unlock and an FLR before the unmodified NVIDIA driver binds the card, so no driver patching is needed for each new release.
User-reported gains vary: LLM prefill +14 to 36% in four reports, with the lowest dense GEMM figure (+25%) from cards capped at 225 W; LLM decode and INT8 stay about the same.
The module does nothing unless the kernel command line includes gpu_unlock.targets=all or specific PCI addresses; unlocking takes about a second and is redone after suspend to RAM.
Code is GPL-2.0-only; NVIDIA firmware remains under its own terms.

Why it matters

Matrix-heavy GPU work such as LLM prefill, diffusion and FlashAttention is where the unlock helps, and the project claims it brings GeForce cards to the issue rate of their professional equivalents. Its design is the notable part: by acting before the stock NVIDIA driver binds the card, it avoids the earlier need to patch the driver after each release. It combines the CMP unlocker's V67/PLM technique with the pre-driver timing of the UEFI approach, without being a UEFI application.

Who it affects

Owners of GeForce cards built on GA102, GA103, GA104 or GA106 who run Linux, including multi-card machines (reports cover up to four cards), cards that drive a display, and cards passed through to a VM with vfio-pci. People running LLM prefill, diffusion or FlashAttention workloads stand to gain; those mostly doing LLM decode or INT8 work should expect about the same performance.

How to use it

Clone https://github.com/Zagitta/gpu-unlock, enter the directory and run make install, which asks for a sudo password, detects the distribution and builds and installs the package. Then append gpu_unlock.targets=all (or specific PCI addresses, comma-separated) to the kernel command line, keeping existing options. The README gives steps for GRUB on Debian/Ubuntu/Mint and Arch/CachyOS, grubby on Fedora/RHEL, systemd-boot and UKI setups. Reboot, then check with journalctl -k -b | grep gpu_unlock and lspci -nnk. Setting gpu_unlock.resume=0 turns off the re-unlock after resume. The code is GPL-2.0-only.

How solid is it

The performance figures are results reported by users, not measured by the project itself, and the README says they are not directly comparable because each report uses its own dense GEMM benchmark. Power limits change the outcome a lot. The reports that compared outputs found them bit-identical before and after. The list of cards that have been reported on is shorter than the list of IDs the module accepts.

Risks and caveats

The display card's screen goes blank from the reset until nvidia-drm takes over. If the firmware on a card never stops, the module logs it and keeps the DMA buffers that firmware may still use until the next power off, so power off before trying again. Hibernation is not covered, and loading the module by hand after boot does nothing to a card nvidia has bound. Suspend to RAM adds about a second to resume. The source gives no NVIDIA position, warranty or terms-of-service statement about the unlock, and NVIDIA firmware remains under its own terms.

“It is neither a UEFI application nor a patched NVIDIA driver.”

— gpu-unlock project README