What gpu unlock gets back, and what it does not
One thing comes back, and it is the reason anyone runs gpu unlock: the tensor core issue rate for FP16, BF16 and TF32 math with FP32 accumulate. [official README]
+65–87%
Synthetic GEMM gain
Card by card, stock power limit.
[official README]
The split is the whole decision: prefill, fine-tuning and image generation gain; chat decoding does not.
Comes back
Prefill and prompt processing · time to first token · LoRA and BF16 fine-tuning · image generation · FlashAttention kernels.
Stays flat
Token decoding · INT8, FP8 and INT4 inference · games · plain FP32 CUDA work.
That split decides whether any of this is worth your afternoon, and no number below is measured here: every range is the project's own.
What gpu unlock restores inside the chip
NVIDIA leaves eight 4-bit speed selectors at half rate in the register block that governs FP16, BF16 and TF32 issue, so the same die reports half the tensor throughput of its professional sibling. Nothing in the stock driver can unlock GeForce tensor core performance from there: those selectors sit behind a privilege bit the driver is not allowed to set. The module gets one write from inside the heavy-secure context, flips the selectors, and resets the card so the unmodified driver binds to a part that reports full speed. [official README]
Three registers decide this, all documented inside the project's mechanism write-up. SS0 at 0x0082381c holds eight 4-bit selectors — DP, FFMA, FMLA16, FMLA32 and IMLA0 through IMLA3 — each with one override bit and three bits of rate. SS1 at 0x00823820 covers one more, IMLA4.
On a consumer card the fields that govern FP16, BF16 and TF32 sit at half; setting every field to "override on, full rate" gives SS0 = 0x88888888 and SS1 = 0x8.
As shipped (defaults)
0.5×SS0 = 0x00000001, SS1 = 0x00000001. FP16, BF16 and TF32 selectors at half rate.
After the write
1×SS0 = 0x88888888, SS1 = 0x8. Override on, full rate, every field.
The default PLM value explains why you cannot write those from userspace. 0xffffff8f ends in 1000 1111: the low nibble lets all four privilege levels read, and bits 7:4 being 1000 means only L3, the heavy-secure context, is allowed to write. A store from anywhere else is silently dropped. [official README] That one privilege bit is why an exploit has to exist at all.
Nothing is flashed, no driver file is replaced, and the card keeps no change of its own. The write chain that gets one store inside that context is the next section.
How gpu unlock gets one write from the wrong side of the fence
leak
A debug firmware leak
NVIDIA once shipped debug-signed Booter firmware alongside the production image. Debug images use a known test key, so the firmware could be decrypted and taken apart.overflow
A stack overflow
One of the things that fell out was a classic overflow on the SEC2 processor: overflow the buffer, control the return address, and the secure processor walks a chain of your choosing.one write
A single 4-byte write
The payload that came out of it, v67, does one useful thing: write four bytes to an address you choose.chain
Six of them, chained
In recipes.c the Ampere chain is six writes, in frames of 0x18 bytes, starting at stack offset 0xff54 with cleanup from 0xffe4. The chain exists to land one of them on PLM.[official README]
unlock
The fence comes down
Once PLM reads 0xFFFFFFFF the host can set the two speed registers through ordinary PCI config access. A function-level reset follows, and the card comes back reporting the rate you just set.
Ada reuses the same body with the addresses remapped through the firmware map: 0x686 becomes 0x1e02, 0x1110 becomes 0x257e, 0x84c8 becomes 0x7a02, 0x81ee becomes 0x771e. [official README]
That remapping is why a new generation is not a small patch: someone has to find the equivalent writes in a booter they can actually read.
What gpu unlock is worth, card by card
RTX 3060 12 GB
+87%2751RTX 3060 Ti
+82%3768RTX 3070
+81%4072RTX 3080 10 GB
+73%65113RTX 3090
+65%75125RTX 3090 Ti (450 W)
+80%88157RTX 4070 Ti
+84%81150RTX 4080
+87%104193RTX 4090
+100% (peak)165329
Pending backfill
Cards with no published before/after pair
The project publishes one BF16 pair per card. Boards outside this list are not plotted rather than estimated.
What you actually get when you unlock GeForce tensor core performance depends on two things: whether your workload runs on the unlocked lane, and how much power the card is allowed to draw.
Which workloads gain
LLM prefill / prompt
25–55%Compute bound, on the disabled path. [official README]
Time to first token
25–30%Same prefill work, seen from the other end (time saved, not gained). [official README]
LoRA and BF16 fine-tuning
25–50%Large GEMMs with FP32 accumulate. [official README]
Image generation
30–55%FP16 matmuls in every diffusion block. [official README]
Video generation (BF16)
15–20%Same math, more of the run spent outside it. [official README]
FlashAttention / SDPA
50–60%Kernel level, before scheduling overhead. [official README]
llama.cpp / Ollama
0–15%Bandwidth bound, mostly at long context. [official README]
Token decoding
noneMemory bound. Issue rate is not the limit. [official README]
INT8, FP8, INT4
noneThese paths never touch the selectors. [official README]
Games and FP32 CUDA
noneNot tensor math. [official README]
The power limit decides how much of the ceiling you keep. [official README] One 3090, reported at five power levels at the same clocks:
- One RTX 3090, one workload, five power limits — as reported, not reproduced here. [issue #107]
250 W
- Reported gain
- +25%
275 W
- Reported gain
- +35%
300 W
- Reported gain
- +42%
350 W
- Reported gain
- +48%
375 W
- Reported gain
- +50%
And one 4090 that runs out of power before it runs out of tensor cores: matrix-multiply peak +100%, PyTorch matmul 0% to 5%. [issue #218]
Neither is a promise for your machine. They are the two published end-to-end measurements, and both point the same way: the card, not the register, is the ceiling.
Is your card in the gpu unlock table
Ampere (RTX 30)
51 IDsStable
The only generation with a long run of user reports behind it.
Ada (RTX 40)
17 IDsExperimental
Works; a 4090 runs out of power before it runs out of tensor cores.
Turing (RTX 20)
19 IDsExperimental
Three of the open failure reports end in the same error.
GA100 (A100)
—Not listed
The family exists in the source and carries no device IDs. A100 is out of scope.
GA107 (RTX 3050)
—Pending patch
Community patches exist and stay unmerged. Do not count on them surviving an update.
Blackwell (RTX 50)
—Not supported
The FAQ says unlikely to happen. The booter generation changed.
- Stablein cards[], reports agree
- Experimentalin cards[], thin reports
- Pending patchcommunity only
- Not supportedno path today
The whitelist is 87 PCI device IDs in cards[], split across three generations, and model names are not the key; one name can sit on two dies. [official README] A card outside that list stays locked, however the box is labelled. gpu unlock compatibility, keyed by PCI device ID is the full table, and the three Turing failure reports behind that row are issue #242, issue #247 and issue #248.
Two edge cases have their own notes: RTX 50 series compatibility and Blackwell support, and RTX 3050 compatibility and the GA107 patch status.
Where gpu unlock takes you next
The rest of the site is three routes, and none of them belongs on this page:
- The gpu unlock install walkthrough: three checks before you start, four package paths, and the parameter that opts a card in.
- gpu unlock compatibility: the 87 device IDs, plus what the reports say about Ampere, Ada and Turing.
- The -16 page: what it means when the driver claims the card before the module reaches it.
How gpu unlock fails in practice
- -16
The driver grabbed the card first
-16 EBUSY: the device already has an owner.
- -2
The firmware never made it in
-2 ENOENT: the image is missing the payload.
- -110
A warm reboot is not a cold boot
-110 ETIMEDOUT: the card stops answering.
- no line
The module never ran
No log line at all: gpu unlock is not in the image.
Two more codes exist and neither is fixable from your side: -19 ENODEV is a Turing payload mismatch, and -22 EINVAL is an alignment mismatch on some GA106 boards. [official README] The Turing and GA106 rows come from the failure reports in issue #242 and issue #184.
The -110 case is worth reading before you start, because the card can stay unusable until you physically cut power. A reboot does not clear it. [issue #23]
What can go wrong with gpu unlock, and how to undo it
- What is and is not reversible, in one place.
Card firmware
- State after a cold boot
- Untouched. Remove the kernel parameter and you are back where you started.
A card that fails mid-probe
- State after a cold boot
- Stops answering until power is cut. That is the -110 case above.
Warranty
- State after a cold boot
- Unknown. No public evidence either way.
Rolling back
- Remove the
gpu_unlock.targetsparameter from your kernel command line and reclaim the card on the next cold boot. - Uninstall the package rather than deleting files: it owns the module and the initramfs drop-in.
- If a run left the firmware unable to settle, shut the machine down instead of restarting it. The module keeps its DMA buffer until the next power cycle.
The failure modes, the rollback steps, and how to tell an imitation site from the repository
Three things gpu unlock is not
- Not a vGPU unlock. vGPU tools slice one physical card into virtual GPUs for VMs. Different problem, different code, and most of the search results for "gpu unlock" are about it.
- Not an LHR bypass. LHR limits Ethereum hash rate on some cards. It has nothing to do with tensor issue rates.
- Not a VBIOS mod. Nothing is flashed. A guide that has you back up and rewrite a VBIOS is describing a different thing, and a riskier one.
Where the official gpu unlock source lives
One repository, no website, no token, no installer. Read VERSION (2.0.0 at the time of this check), read the commit that last touched whatever file a claim comes from, and treat any other version number you see on a third-party page as unverified.
Licensing is a little awkward and worth stating precisely: the kernel module and the local packaging are GPL-2.0-only according to the README and the files under licenses/, and the generated buffer derives from a pinned CMP reference. The repository has no root LICENSE file, so GitHub's own license field reads null. That is an artefact of layout, not a different licence.
gpu unlock questions that come up first
Do I need to reinstall the driver after unlocking?
No. The module runs before the driver and hands the card over unchanged. Rebuild the initramfs when the kernel changes, or the module disappears with the old kernel.
Will this make my model generate tokens faster?
No. Decoding is memory bound. Prefill, time to first token and fine-tuning get faster; conversation speed does not.
Can I undo it?
Remove the kernel parameter, rebuild the initramfs, cold boot. The card itself was never modified.
Does it work on a laptop?
Sometimes, and less reliably. Many laptops power the discrete GPU down when idle, which silently resets the unlock. The project calls the results mixed.
Can NVIDIA block this later?
Nobody has published an answer. The project's FAQ does not address it, and the threads that raise it have no reply from the maintainer.
Checked VERSION 2.0.0commit 1fc6d62