Linux module unlocks double FP16 tensor speed on the RTX 4090

What's going on

A project called "gpu-unlock-ada" (version 1.1.1) has appeared on GitHub. It's a Linux kernel module for the GeForce RTX 4090 (AD102 chip) and, experimentally, the RTX 4070 Ti SUPER (AD103). According to the project, it lifts a performance throttle: tensor throughput was capped at about half via a setting (SM Speed Select). Reddit user CeFurkan shared the repo in r/comfyui, claiming the RTX 4090 is "also limited in software." That thread also linked to a post about a similar unlock for the RTX 3000 series (according to its title, confirmed by @KohakuLab and @ComfyUI, with nearly doubled TF32). The source gives no details on that.

The module runs at boot, before the regular NVIDIA driver takes over the card. It changes the "SM Speed Select" setting. SM stands for Streaming Multiprocessor, the GPU's compute blocks. After that, the unmodified NVIDIA driver loads as usual. You don't need a patched driver or a UEFI application.

What was measured

Tensor cores are the specialized units for the matrix math that AI models run on. The figures below are the project's own claims, not an independent test:

"Accumulation" means intermediate results are summed in higher precision (FP32). INT8, dp4a (an integer dot-product instruction) and regular FP32 stayed close to baseline. The unlock survived a PCIe function-level reset (FLR), initialization by NVIDIA driver 615.78.08, and CUDA benchmarks.

On an RTX 4070 Ti SUPER (PCI ID 10de:2705) with the same 240 W limit, the project measured 95.0 → 189.9 TF/s (FP16) and 95.0 → 189.7 TF/s (BF16). TF32/FP32 rose from 47.49 to 94.51 TF/s (1.99×). INT8 stayed at 379.5 TOP/s and INT4 at about 754.8 TOP/s. A verified FP8-E4M3 CUTLASS GEMM (a matrix multiplication) gained only 59.326 → 59.495 TF/s, or 0.3%. Other FP8 kernels weren't tested. Deterministic FP16/BF16 GEMM results matched exactly.

The authors stress that these are issue rates with data in registers, not speedups of real GEMM or inference workloads.

How it works

On the RTX 4090, the module runs the signed NVIDIA firmware, checks the payload's completion marker and the required permissions, writes the values SS0 0x88888888 and SS1 0x8, and then triggers an FLR before the driver binds. Before and after, the effective Speed Select readout must show the expected value.

The payload comes from TOTORONG/AD103_win_unlocker on Hugging Face, including the analysis of a decrypted debug booter. The Linux module and packaging build on Zagitta/gpu-unlock, and the GA102 chain on WildFlash1st/cmp90hx-unlock. The production booters are authenticated and decrypted inside the GPU. The payload uses instruction addresses derived from the debug analysis.

Supported cards and installation

The RTX 4090 (10de:2684) is detected automatically. The legacy GeForce/CMP lists for GA102/GA104 and GA103/GA106 remain. Upstream reported success for the RTX 3090, but not every older card was re-tested here. The RTX 4070 Ti SUPER is an experimental target, validated on one card. It needs gpu_unlock.ad103_experimental=1 plus the exact PCI address, and targets=all never selects it. Other Ada cards, RTX A-series and data center cards are not accepted.

To install, clone the repo and run make install (or make install-arch, install-deb, install-rpm). You need kernel headers and the DKMS toolchain. The build downloads NVIDIA sources and binaries (610.43.03) over HTTPS, checks SHA-256 hashes and generates the firmware locally. Prebuilt firmware packages aren't distributed. You enable it via the kernel command line, e.g. gpu_unlock.targets=0000:03:00.0 (get the address from lspci -D). The initramfs generators mkinitcpio, initramfs-tools and dracut are supported.

Try it: what you need

You need an RTX 4090 (or, experimentally, an RTX 4070 Ti SUPER), Linux with kernel headers and DKMS, a bootloader that lets you set kernel parameters, and space for the firmware cache (under ~/.cache/gpu-unlock). It's a Linux kernel module, so Windows, Mac and Colab are out. For the first attempt, fully power the machine off and back on so the firmware states are fresh. It hasn't been validated with display output or multi-GPU setups, and the screen stays black until nvidia-drm takes over.

Risks and pitfalls

Before your first attempt, make sure nvidia-smi, CUDA, NVML and nvidia-modprobe aren't running, since they can load NVIDIA's driver. Once the driver has bound, nothing can be unlocked anymore. After a warm reboot, the WPR2 protected region (a protected memory area) may stay set, and the module will then refuse to run. If the module reports that the firmware didn't halt, power the machine off, and don't force-unload the module. Keep a bootloader entry with the unchanged default configuration. The source doesn't say whether the card runs into thermal or power-draw problems at double throughput.

Analysis

If this holds up, it would matter a lot for people running ComfyUI, training and local inference: FP16/BF16 matmuls with FP32 accumulation were widely believed to be deliberately capped at half rate on GeForce cards (this market segmentation is well known, but the source doesn't spell it out). Much remains open. The RTX 4090 measurement rests on one card and one cold boot. The cleaned-up module needs a rerun on the hardware. Numerical validation in real applications and independent reproduction are missing. Practical speedups for image models aren't shown, and FP8 showed no gain. The module also digs deep into firmware and boot, which can affect your warranty or stability. If you test it, treat it as an experiment.