GPU Unlock: Full-Rate Tensor Cores on RTX 20, 30 and 40 Cards

License GPL-2.0-only

License GPL-2.0-only

TL;DR

• Writes SS0 0x88888888 and SS1 0x8 before the NVIDIA driver binds, taking FP32-accumulate matrix math from half rate to full
• The 2x figures are instruction issue rates; the projects own cuBLAS numbers are 12 to 36%, and LLM decode does not move at all
• Linux only, cold boot required, volatile on power loss, GPL-2.0-only, and two of the four projects carry explicit hardware-damage warnings

☍ Announcement ⬇ Download Model

System Requirements

RAM	Irrelevant to the unlock itself; you need kernel headers, a DKMS toolchain and network access, because the payload is generated on your machine rather than downloaded
GPU	RTX 30 (GA102/103/104/106), RTX 40 (AD102/103/106) or RTX 20 (TU102), on Linux only. Six Ampere cards and one RTX 4090 have working reports; every other board is experimental
VRAM	Unchanged. The unlock adds no VRAM: the 22 GB RTX 2080 Ti results come from physically memory-modified cards

Table of Contents

1. What the four viral numbers actually are
2. The limit is a register, and the register has a full-rate setting
3. The control row that reframes the whole thing
4. Issue rate is not throughput
5. What speeds up, and what does not
6. On Ampere, FP16 and BF16 do not gain the same amount
7. Three architectures, three projects, three validation stories
8. This came out of the mining-card graveyard
9. Running it, and the parts that bite
10. The licence situation, precisely
11. Who should touch this
12. Sources and further reading
13. Your next ten minutes

Four numbers went around the internet this weekend. RTX 4090: 165.6 to 331.6 TFLOPS. RTX 3090 Ti: 87.5 to 157.4. RTX 2080 Ti: 59.9 to 111. RTX 3090: 73.0 to 122.8. Every one of them is real and published. They also come from four different repositories, running four different benchmarks, on four different cards, and not one of them is a speedup you will see in your inference stack tonight.

What shipped is three Linux kernel modules that write two GPU registers before NVIDIA's driver binds the card. No VBIOS flash, no patched driver, nothing soldered. The projects are unusually careful about what their numbers mean. The coverage has not been.

What the four viral numbers actually are

These figures circulated as one table, as though they were one result set. They are not. The harness matters more than the headline.

Two of the four are issue-rate microbenchmarks rather than matrix math anyone runs; the other two are dense GEMM benchmarks, which is real work but not a workload. The PyTorch figure also compares a 370 W baseline against a 360 W unlocked run, honest of the author to disclose and awkward to read as a clean doubling.

The limit is a register, and the register has a full-rate setting

The Ampere project's writeup names the hardware. Two registers govern how fast the streaming multiprocessor may issue instructions: FEAT_OVR_SM_SPD (SS0) at 0x0082381c, holding eight 4-bit fields covering DP, FFMA, FMLA16, FMLA32 and IMLA0 to IMLA3, and FEAT_OVR_SM_SPD_1 (SS1) at 0x00823820, whose single field is attributed to IMLA4.

Each field is an override-enable bit plus a three-bit speed selector: 000 full rate, 001 half rate, with quarter and eighth settings present but unconfirmed. The GA102 default is 0x00000001, meaning override on, half rate. The unlock writes 0x88888888 to SS0 and 0x8 to SS1: the same override bit, selector set to full.

This is not a yield bin, a missing unit or a thermal guard. It is a configuration field whose documented purpose is throttling specific classes of matrix instruction, shipped set to half.

Getting at it is the interesting part. Neither selector is writable from the host; both are gated by a Privilege Level Mask, FEAT_OVR_PLM at 0x00823804, defaulting to 0xffffff8f: readable at all four privilege levels, writable only from L3, the heavy-secure context. The projects reach L3 through a stack buffer overflow in NVIDIA's SEC2 Booter firmware. That firmware is encrypted, but NVIDIA published a debug build encrypted under a known public test-key scheme (key index 37), so it could be decrypted, disassembled and mined for return-oriented-programming gadgets. The payload affords exactly one four-byte write, and the gadget chain is already near its size limit, so instead of writing both selectors it writes 0xFFFFFFFF to the privilege mask and lets the ordinary host driver write the selectors afterwards.

The control row that reframes the whole thing

KohakUnlock did the one test nobody else ran. On the same 2080 Ti, it measured FP16 matrix math accumulating into FP16 rather than FP32, as a control.

The control does not move. That card could always do roughly 119 TFLOPS of FP16 matrix math. What it would not do at full speed was accumulate the result in FP32, and the unlock brings that mode up to 111, landing just under the rate the FP16-accumulate path had all along.

Nothing is being overclocked and no hidden capability is appearing. A penalty is being lifted, and it was aimed precisely at the mode you need for training stability and for large GEMMs where FP16 accumulation loses precision. The fast path was always there for work that tolerates accumulation error. The careful path was the one sold at half speed.

Issue rate is not throughput

The Ada project says so itself, directly under its own 2x table: "These are register-resident issue rates, not application GEMM or inference speedups." Its matched owner run is specific. Real cuBLAS GEMM median throughput on an RTX 4090 gained 12 to 34% for FP16, 16 to 20% for BF16 at two shapes, and was "essentially unchanged at 4096 cubed", while the instruction issue rate in the same session went 160.4 to 320.4 TF/s.

Every other application-level measurement lines up with that rather than with the doubling. Ampere users report LLM prefill up 14 to 36% across four reports. KohakUnlock's best MAMF median over a 125-shape sweep went 57.71 to 88.24 TFLOPS, up 52.9%, flagged as two same-model cards rather than a same-card A/B.

The cleanest application number of the lot is Turing's, because turing-unlock published cuBLAS results instead of issue rates, measured against the 56.9 TFLOPS the NVIDIA Turing whitepaper claims as peak FP16-with-FP32-accumulate for the card.

A 2080 Ti at 250 W running 60% past its own spec sheet is a better argument than any synthetic figure.

What speeds up, and what does not

This is the table to read before deciding whether any of it is worth your evening.

Read the decode row twice. If what you do with your GPU is chat with a local model, this changes your tokens per second by roughly nothing: generation is limited by how fast weights move out of VRAM, not by matrix issue rate. Your prompt gets ingested faster. Your replies do not arrive faster.

The FP8 row is being reported backwards elsewhere. A matched FP8 CUTLASS GEMM moved 0.3%, so if you serve an FP8 quant, now a common way to fit a large model onto one consumer card, the unlock does nothing for you. Same for INT8 and the INT4 kernels some loaders use.

On Ampere, FP16 and BF16 do not gain the same amount

The single most actionable thing in any of these repositories is a three-row table in the Ampere README, taken on a 3090 Ti at 450 W.

Everyone quoted the BF16 row. The two precisions start within 0.05 TFLOPS of each other and end 39 TFLOPS apart, and the project describes the SS0 value it writes as the one that "selects the full BF16 rate". On an RTX 30 card, a stack pinned to FP16 therefore collects less than half the available gain. On Ada both precisions double together; on Turing, BF16 and TF32 are not unlocked at all.

Three architectures, three projects, three validation stories

Star counts read from the GitHub API on the date below. Note what the Turing rows do not say: both 2080 Ti reports are 22 GB cards, physically VRAM-modified rather than factory parts. KohakUnlock is explicit that the memory mod has nothing to do with the software unlock.

The gap between accepted and validated is wide. The Ampere module's device table accepts 51 GeForce PCI IDs (12 GA102, 29 GA104, one GA103, nine GA106); six cards have a working report, GA103 has none, and targets=all tries every ID on the list. One card is a documented failure: the OEM RTX 3080 Ti 20 GB (GA102-250, 10de:2205) completes the unlock and its BF16 stays at half rate anyway.

This came out of the mining-card graveyard

The attribution chains lead back through three months of people salvaging dead crypto-mining accelerators: cmpunlocker on 15 July, which restored CMP 170HX cards from 8 GB to 64 GB and still carries the description "a tool to unlobotomize your NVIDIA card"; cmp90hx-unlock on 26 July, the source of the GA102 V67 chain; a 55-page CMP 170HX technical wiki on 28 July, where the privilege-mask bitfield model every GeForce module cites comes from; and cmp50hx-unlock on 19 August, whose README notes it reached RTX 2080 Ti performance on a mining card. The first GeForce module landed on 18 October, a full week before the coverage wave.

So the mining bust paid for this. People with racks of deliberately crippled compute cards had every reason to go looking for the throttle, found a flaw in the boot process, and the same exploit chain turned out to un-segment every GeForce RTX card from the 2080 Ti to the 4090. That is a better story than the TFLOPS numbers, and it is why this will be hard to put back: the technique is three months old, documented across a chain of public repositories, and the payload is generated on your own machine from inputs NVIDIA itself publishes.

Running it, and the parts that bite

lspci -nnk -d 10de: | grep -E 'VGA|3D'

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

# add gpu_unlock.targets=0000:21:00.0 to the kernel command line,
# then FULL POWER OFF, not a reboot

journalctl -k -b | grep gpu_unlock

The gotchas, in the order they will catch you:

• Linux only. Windows exists as single-machine UEFI ports, one of them tied to a captured MSI Z490 profile, with no installer and no binaries distributed.
• Cold boot, not a reboot. The module checks the protected VRAM region and refuses a card whose firmware state is not fresh. A warm reboot worked on one tested card; it is not guaranteed on yours.
• Do not touch nvidia-smi, CUDA, NVML or nvidia-modprobe first. They load the driver by name, and a modprobe blacklist does not stop an explicit named load. Once the driver has bound the card, loading the module does nothing.
• It is volatile. Power loss resets the selectors. Suspend to RAM is handled by a resume hook that costs about a second. Hibernation is not covered.
• If the module reports that firmware did not stop and it is keeping its DMA buffers, power off. Do not force-unload it.
• Keep an unmodified boot entry and check the unlock message and a rate readback every boot. A loaded module and a clean modprobe prove nothing.
• Power limit dominates the result. The lowest Ampere gain on record, +25%, is from cards capped at 225 W.
• Both Turing projects carry hardware-damage warnings in their own words. turing-unlock: tensor cores draw very high power and unlocking them to full speed may damage your hardware. KohakUnlock is blunter, listing a hung GPU or host, failure to boot, data corruption and hardware damage, with no guarantee of recovery, and telling you to have console and power control to hand.

The licence situation, precisely

All four projects declare GPL-2.0-only in their README and ship a licenses/ directory. GitHub's licence detector still reports no licence for Zagitta/gpu-unlock and nlzy/turing-unlock, because neither puts a LICENSE file at the repository root. Screen dependencies through the GitHub API and those two come back unlicensed, wrongly.

No project redistributes NVIDIA firmware, and that shapes the install. Each build fetches pinned NVIDIA inputs over HTTPS, verifies their SHA-256 and generates the payload on your machine; the make dist archive, the Debian source package and the .nosrc.rpm contain no NVIDIA archives and no generated firmware. That is deliberate legal design, and why this is a build rather than a download.

Who should touch this

Fine-tuners running training steps on one or two consumer cards. This is the group the numbers actually serve. FP32 accumulation is what stable training wants, it is exactly the mode that was throttled, and the measured application gains land on the dense GEMMs your steps are made of. A 3090 or a 4090 doing LoRA work overnight is the clearest case for spending an evening on a kernel module, and the bit-identical output checks mean you are not trading correctness for it.

People pushing long prompts, batches or diffusion. Prefill up a third is worth having if you feed large contexts to an RTX 30 card, and image and video pipelines are matrix-bound in the right way. Pair it with the dtype change: on Ampere, BF16 is where the gain lives, and TF32 gains more still.

Almost nobody who just chats with a local model. Decode is memory-bandwidth bound, so your tokens per second will not move, and on FP8 or INT8 quants the unlock measures out under a percent. Weigh that against a cold-boot requirement, a setting that evaporates on power loss, two explicit hardware-damage warnings and a validated-card list of six. If you own an OEM 3080 Ti 20 GB, it is already documented as not working.

Sources and further reading

• Zagitta/gpu-unlock, the Ampere module, its benchmark table and compatibility reports
• How Nvidia Ampere generation GPUs got unlocked, the register, privilege-mask and ROP writeup
• JustAResearcher/gpu-unlock-ada, the Ada port, matched cuBLAS results and FP8 measurement
• nlzy/turing-unlock, the TU102 module and its cuBLAS table
• KohakuBlueleaf/KohakUnlock, the FP16-accumulate control run and the safety scope
• Consensus-Protocol/cmp170hx, the CMP wiki the privilege-mask model comes from
• NVIDIA Turing Architecture Whitepaper, the 56.9 TFLOPS peak the Turing table is measured against

Your next ten minutes

Do not start with make install. Find the row in the workload table your GPU time actually goes into, then check it against your loader's dtype. If you are on an RTX 30 card and your stack says float16, flipping that one flag to bfloat16 is free, reversible and worth 45 percentage points of the headline gain before you compile anything. If your answer is "I run an FP8 quant and talk to it", you have just saved yourself an evening and a hardware-damage warning.

For more throughput out of consumer silicon without touching firmware, we have been round this a few times: running a 125B model on a gaming GPU, exact speculative decoding for exactly the decode-bound case this unlock cannot help, and NVIDIA FLARE on the serving side. For hardware planning there is the self-hosted video stack hardware guide and a dual DGX Spark EXL3 walkthrough. And if you would rather have the gain in the weights than in the registers, Nemotron 3.5 Bolt E4B is the current small-model answer.

Not independently tested. Every performance figure is the relevant project's own published measurement, read from its repository and attributed above to the project and harness that produced it; the four headline cards were measured by four different people on four different benchmarks, so those numbers are not comparable with each other. Register addresses, default values, the privilege-mask model and the exploit description come from the Ampere project's own writeup. Star counts, licence metadata, accepted device lists and repository dates were checked against the GitHub API on the date below. NVIDIA has published no response.
Date checked: 2026-10-25