Install the SM speed-select override, module by module

Three kernel modules unlock the tensor throughput NVIDIA reserves for other parts of the chip. This site is the build-and-install side of the project: which module your card needs, the exact commands, the parameter names and the checks that prove it worked. Which cards are supported and what was measured on them is recorded separately on the reference site.

Pick your module

Two of the three share the module name gpu_unlock; the Turing one is a different module with a different parameter. Install the one your chip belongs to — the wrong parameter does nothing at all, silently.

ModuleChipsKernel parameterUpstreamInstall
gpu_unlock
main @ 6081407
GA102, GA103, GA104, GA106gpu_unlock.targets=Zagitta/gpu-unlockampere
gpu_unlock
v1.1.1
AD102, AD103, plus the Ampere listsgpu_unlock.targets=JustAResearcher/gpu-unlock-adaada
turing_unlock
main @ 417f333
TU102, TU104, TU106turing_unlock.targets=nlzy/turing-unlockturing

Build and install

None of the modules ships prebuilt binaries. Each one builds on the target machine, because the payload is generated against the NVIDIA firmware already installed there. The same make install front end covers every distribution family.

Ampere / Ada

git clone https://github.com/Zagitta/gpu-unlock.git
cd gpu-unlock
sudo make install

Turing

git clone https://github.com/nlzy/turing-unlock.git
cd turing-unlock
sudo make install

Ampere (RTX 30 series)

Turing (RTX 20 series)

Opt in on the kernel command line

A module that loads but is not asked to do anything leaves the card locked. The parameter is the switch, and it has to survive into the boot entry.

# all accepted cards
gpu_unlock.targets=all

# one card, by PCI address
gpu_unlock.targets=0000:21:00.0

# RTX 20 series — a different module, a different parameter
turing_unlock.targets=all

Verify before you make it permanent

The unlock is invisible when it fails, so check each step rather than assuming.

  1. Boot once with the parameter in place and watch the kernel log for the unlock line
  2. Confirm the card is in the accepted device-ID list for your module
  3. Re-measure a path that the override is supposed to change, on the same card

The hardware risk is documented, not theoretical

The modules write speed-select registers and perform an FLR before the driver binds. Keep an unmodified stock boot entry, validate one cold boot before making anything persistent, and treat the AD103 path as experimental — it was validated on a single card.

Card support and measured results live on the reference site

Supported device IDs, per-card status and the same-card stock-vs-unlocked measurements are maintained on the companion reference site, which is where the evidence lives. This site covers the build, the boot order and the checks.

Upstream projects

This site documents these repositories; it does not fork them.