Nvidia GPU Unlock for Full FP16 on RTX 3000 Cards

Hobbyists now run the gpu-unlock Linux kernel module on RTX 3000 series cards to raise FP16 and BF16 instruction rates. The nvidia gpu unlock targets GA102 through GA106 chips and matches the rates found on professional cards that use the same silicon. According to the project's GitHub page the module writes specific registers early in boot so the change takes effect before the NVIDIA driver loads. This explainer covers the exact hardware change, the workloads that benefit, the cards that respond, the steps to install the module, and the limits still present in the current reports.

Key takeaways

• - The module doubles the issue rate of FP16 and BF16 fused multiply-add instructions on GA102, GA104 and GA106 dies.
• - Dense matrix workloads such as GEMM see direct throughput gains once the higher instruction rate is active.
• - Only cards from the listed GA families have confirmed full-rate results on the project's GitHub page.
• - The module must load before the NVIDIA driver and currently supports Linux systems only.
• - Power draw increases on matrix-heavy tasks because the card sustains the extra instruction throughput.

What the unlock changes on RTX 3000 cards

The unlock raises the rate at which GA102, GA103, GA104 and GA106 chips can issue FP16 and BF16 fused multiply-add instructions. On these dies the change brings the consumer cards up to the full rate that the corresponding professional parts already run at. According to the project's GitHub page, the module doubles the instruction issuing speed of FP/BF16 FMA operations that accumulate into FP32.

A clear before-and-after example appears on the page for an RTX 3090 Ti running a dense 8192 cubed GEMM at the 450 W power limit with FP32 accumulation. FP16 throughput rises from 87.46 TFLOPS to 118.39 TFLOPS. BF16 throughput rises from 87.50 TFLOPS to 157.41 TFLOPS. TF32 throughput rises from 42.58 TFLOPS to 82.61 TFLOPS. These numbers come from five-sample medians on the same card before and after the change.

The size of the gain depends on how much power the card can draw. The page notes that the lowest reported gain of 25 percent came from cards limited to 225 W. Higher power budgets let the extra issue slots stay busy longer, so the observed uplift grows.

The higher issue rate shows up as extra throughput on matrix workloads that use these formats, while the underlying math units and memory paths remain unchanged. Outputs stay bit-identical in the reports that checked them. The same rate increase applies across the four GA chips listed, though measured gains differ by card model and power cap.

Why the change matters for matrix workloads

The unlock raises the rate at which an RTX 3000 series card can issue FP16 and BF16 fused multiply-add instructions, which directly lifts dense GEMM throughput. According to the project's GitHub page, a 3090 Ti at 450 W moves from 87.5 TFLOPS to 157.4 TFLOPS in BF16 GEMM and from 87.5 TFLOPS to 118.4 TFLOPS in FP16 GEMM, with TF32 showing a similar doubling. These are the same matrix operations that dominate the prefill stage of large language models, where the model processes the entire prompt at once. Users report 14 to 36 percent faster prefill on the unlocked cards, enough to shorten the first token latency that users notice most. Diffusion models rely on repeated matrix multiplies inside the U-Net or transformer blocks, so the same throughput increase shortens image generation steps. FlashAttention kernels also spend most of their time in these GEMM patterns and show corresponding gains. Decode passes, by contrast, stay limited by memory bandwidth rather than arithmetic rate, so they show no measurable change. INT8 workloads likewise remain unaffected because the unlock targets only the FP and BF16 issue paths. The GitHub reports note that outputs stay bit-identical before and after the change, confirming that accuracy is preserved while only the execution speed of the matrix kernels improves.

Who can use the unlock and on which cards

The tested cards that reach full FP16 and BF16 rates all come from the GA102, GA104 and GA106 families. According to the project's GitHub page the module has produced working unlocks on these PCI IDs:

• RTX 3090 Ti (10de:2203)
• RTX 3090 (10de:2204)
• RTX 3080 10 GB and the 20 GB memory-upgraded variant (both 10de:2206)
• RTX 3070 (10de:2484)
• RTX 3060 12 GB (10de:2504)

In every case users measured dense GEMM gains between 56 percent and 81 percent once the speed selectors were rewritten. The single clear exception is the OEM RTX 3080 Ti 20 GB (GA102-250, 10de:2205). The unlock routine finishes and the driver loads, yet BF16 throughput stays at the original half rate.

User reports on the same page show the module working in systems with up to four cards at once. Several people run the cards with active display output and still see the full rate. Others pass the unlocked GPUs through VFIO to virtual machines; the early kernel-module timing appears to survive the hand-off to the guest driver without extra steps. No reports exist yet for any GA103 part, and the RTX 3070 Ti entry lists only an older UEFI method, not this module.

If your card carries one of the working IDs above, the module should apply. If it matches the 10de:2205 OEM part, the change will not increase matrix throughput. Check the exact PCI ID with lspci before you build or install anything.

How the kernel module performs the unlock

The kernel module loads very early in the boot sequence on Linux systems. It combines a register write technique from an earlier CMP unlocker with the timing of a UEFI based method, according to the project's GitHub page. The module first writes the value 0x88888888 into the SS0 selector. That pattern sets the full BF16 issue rate. It then writes the 4 bit value 0x8 into the SS1 selector, which enables the IMLA4 path. After these writes finish, the module triggers a Function Level Reset, or FLR, on the GPU. The reset clears any pending state while leaving the new selector values in place. Because the entire sequence completes before the standard NVIDIA driver binds to the device, the consumer card appears to the driver as if it supports the higher matrix throughput from the start.

This pre binding placement removes the need to edit the NVIDIA driver binary after every vendor release. A user therefore installs the module once through the normal kernel build and packaging steps, and it continues to work across driver updates without further changes. The approach stays inside a standard loadable kernel module rather than a patched driver or a UEFI application, so it fits into existing Linux boot flows on systems that support early module loading. Reports on the GitHub page show the sequence succeeds on GA102 and GA104 cards when the power limit allows the extra throughput.

What remains unknown after the first reports

The compatibility table on the project's GitHub page lists tested results only for certain GA102, GA104 and GA106 cards. GA103 silicon shows a blank entry with the note "No reports yet," which means no user has confirmed whether the module even completes its sequence on those parts or whether the speed selectors take effect. That leaves open the question of whether the same register writes that work on GA102 will produce the expected FP/BF16 rate change on GA103 boards.

Beyond the initial boot-time unlock, nothing in the table or surrounding notes addresses how the change holds up across driver updates. The module runs before the NVIDIA driver binds, yet future releases could alter timing windows, reset sequences or power-management paths that the current code assumes remain fixed. Long-term stability under sustained matrix workloads, repeated suspend-resume cycles or mixed-precision training runs is likewise unreported. The table records only short benchmark passes on a handful of cards; it supplies no data on error rates, silent corruption or gradual performance drift after weeks of operation.

Power-limit interactions also stay unmeasured for most chips. The lowest reported gains came from cards already capped at 225 W, but the table does not show whether the unlocked issue rate pushes other SKUs into thermal or power throttling that the stock firmware would have avoided. Until more users add entries for the missing GA103 IDs and until the module is exercised against newer NVIDIA driver branches, these gaps remain.

Steps to install and enable the module

To get the module on your system, start by cloning the repository with git clone https://github.com/Zagitta/gpu-unlock.git. Change into the new directory and run the build command that the project's GitHub page lists as make targets=all. This single step compiles the kernel module, prepares the firmware payload, and places the signed files where the early boot process can find them.

After the build finishes, run sudo make install. The command copies the module into the running kernel tree and updates the initial ramdisk so the module loads before the stock NVIDIA driver claims the card. Reboot once to confirm the files landed in the right places.

The module still needs an explicit signal at boot. Edit the kernel command line to include the required parameter. On systems that use GRUB, open /etc/default/grub, add the flag inside the GRUB_CMDLINE_LINUX_DEFAULT line, then run sudo update-grub. On systemd-boot, edit the .conf file for your current entry under /boot/loader/entries/ and append the same flag to the options line. EFI stub users pass the parameter directly from the firmware boot menu or through a custom loader script. After the edit, reboot and check dmesg for the unlock messages before the NVIDIA driver binds.

The early load order matters because the module must write the speed selectors and issue the function-level reset while the card is still in a neutral state. If you maintain multiple kernels, repeat the make install step for each new kernel header package so the module stays available across updates.

Power and cooling considerations after the change

Higher throughput from the unlock pushes the GPU harder on matrix operations, so power draw rises when the card can actually use the extra instruction rate. The project's GitHub page notes that the smallest reported gain came from cards limited to 225 W, which shows how tightly power caps control the outcome. On cards allowed to draw more, such as a 3090 Ti run at 450 W during the 8192³ GEMM tests, the same change produced larger speed-ups because the hardware stayed closer to its new peak rate longer.

You will see the difference most clearly in sustained dense workloads. LLM prefill, diffusion models, and FlashAttention kernels keep the execution units busy, so average power climbs and the card spends more time near its thermal limit. Decode passes and INT8 work stay mostly unchanged because they remain memory-bound rather than compute-bound.

The GitHub page lists successful unlocks on GA102 and GA104 cards and records that output values stayed bit-identical before and after the change. It does not publish post-unlock temperature or fan-speed numbers, so you should measure thermals yourself once the module is loaded. Run a repeatable matrix benchmark at your normal power limit, log GPU temperature and power with nvidia-smi, then compare against the locked baseline. If core or memory junction temperatures rise beyond your comfort range, lower the power target by 20-30 W or improve case airflow before running long jobs. Some users already keep four cards in one system; extra heat from the unlock makes case airflow and spacing worth checking early.

The bottom line

If you run Linux and need higher FP16 throughput on a supported RTX 3000 card, clone the repository and test the module on a spare system first. Track the project's GitHub page for new card results and any driver conflicts that appear after future NVIDIA updates. Cards that already meet your needs at stock rates require no change. The long-term stability of the register writes remains unproven across driver revisions, so keep an eye on reports from other users before relying on the unlock in production workloads.

Frequently asked questions

Does the unlock work on Windows?

The gpu-unlock module is a Linux kernel module that loads before the NVIDIA driver on Linux systems. The project's GitHub page gives installation steps only for Linux and contains no mention of Windows support. No Windows driver or equivalent tool appears in the supplied material, so the unlock as described does not apply to Windows at this time.

Will it void my warranty?

The project's GitHub page does not discuss warranty impact or NVIDIA policy. Hardware modifications that alter clock or instruction behavior can in principle affect warranty claims, yet the page supplies no guidance on this point. Users must decide for themselves whether the change risks support coverage, since the documentation leaves the question open.

Can I still use the card for gaming after unlocking?

The module changes only the issue rate for FP16 and BF16 matrix instructions. Gaming workloads rely mainly on FP32 and other paths that remain untouched, according to the description. The project's GitHub page reports no gaming tests, so normal gaming use should continue, but any side effects on driver stability or thermals stay unconfirmed in the current material.

How much extra power does the card draw?

Higher FP16 throughput raises power draw when the GPU sustains the new instruction rate on matrix work. The project's GitHub page notes the increase without giving measured wattage figures. Actual extra draw depends on the workload, card model, and cooling, none of which receive specific numbers in the supplied documentation.

What happens if NVIDIA releases a new driver?

The module writes registers early in boot and may lose effect or cause conflicts after a driver update changes the same registers. The project's GitHub page lists no compatibility data for future drivers. Users will need to check new reports or wait for module updates, since the current material gives no assurance that the unlock will survive driver revisions.

Sources

• GitHub - Zagitta/gpu-unlock: Unlock FP/BF16 instruction issue rate on Nvidia 3000's cards to their professional equivalents · GitHub