Answered from the project's own documentation wherever possible. Where the honest answer is "nobody has measured that yet", that's what it says.
Checked against the gpu-unlock and gpu-unlock-ada READMEs · 2026-10-25
On GeForce RTX 30 series cards, NVIDIA halves the rate at which FP16/BF16 fused multiply-add instructions can issue into FP32 operations, relative to professional cards on the same silicon. gpu-unlock writes the hardware speed selectors (SS0 0x88888888, SS1 0x8) before the stock driver binds the card, restoring the full rate. It does not overclock anything, raise power limits, or change what any instruction computes — in the reports that compared outputs, they were bit-identical.
Calibrated answer: the mechanism is deliberately conservative — it runs early at boot, skips cards that are already bound or powered down, and nothing is written to the card permanently; removing one kernel parameter restores stock behaviour on the next boot. The project is nevertheless experimental and unofficial, and it does perform a firmware sequence and a PCIe reset on your card at every boot. Its documented failure mode: if a card's firmware never stops during the sequence, the module logs it and keeps the relevant DMA buffers — you must power off before retrying. There are no guarantees, and you should weigh "user reports so far" accordingly. If that risk profile bothers you, don't install it.
The project itself makes no claims either way, and NVIDIA does not endorse it — treat any warranty or support implications as your own risk, the same as any unofficial low-level hardware modification. As for "bans": there is no account or service involved in running local compute on your own card, and nothing in the project interacts with games or anti-cheat systems. What we can't do is promise you how a manufacturer would treat a warranty claim on a card that was run this way — nobody publishes that, so anyone who guarantees you an answer is guessing.
The kernel module is Linux-only. Two related data points exist: a user report in the Ampere project notes the same unlock worked from a UEFI port of the technique on Windows (for an RTX 3070 Ti), and the Ada fork documents an experimental Windows UEFI reference port for one specific MSI RTX 4070 Ti board (matched cuBLAS gains of about +80% FP16 / +76% BF16). Neither is a supported, installable Windows release. If you need this on Windows today, there is no official answer.
Unknown — and that's the complete answer. There is no verified gaming FPS data for gpu-unlock in the project's documentation or linked reports. The published gains are all in compute workloads (GEMM, LLM inference, diffusion). Games lean on a mix of shader, texture and bandwidth paths that this unlock doesn't target. Anyone quoting you specific FPS improvements without published methodology is speculating.
GeForce cards on GA102, GA103, GA104 and GA106 chips — most of the RTX 30 series. Tested and reported: RTX 3090 Ti, 3090, 3080 10 GB, 3070 and 3060 12 GB. The RTX 3050 (GA107) is not covered. The OEM 3080 Ti 20 GB (GA102-250) is a known exception where BF16 stays at half rate. Full detail on the compatibility page; RTX 40 series cards are a separate fork.
Depends which half of the LLM. Prefill is compute-bound and user reports put it at +14–36%. Decode is memory-bandwidth-bound — the unlock raises a ceiling decode never reaches, so decode speed stays put. That's physics, not a failed install: verify with journalctl -k -b | grep gpu_unlock rather than by watching tokens.
Reboots, yes — that is the documented design: the module lives in the initramfs and re-applies at every boot as long as the gpu_unlock.targets= parameter is present; kernels installed later pick up the module and a rebuilt image from the kernel’s own install hooks. Driver updates are the specific pain this project avoids: because the NVIDIA driver itself is never patched, a new driver release doesn’t need a new patch — the module just runs before it, as before. Suspend-to-RAM is handled (it re-unlocks on resume, adding about a second); hibernation is not covered.
Yes — name it by PCI address: gpu_unlock.targets=0000:21:00.0 (addresses as printed by lspci -D), or list several comma-separated. Reports cover up to four cards in one machine, the display card, and cards passed through to a VM with vfio-pci.
Delete gpu_unlock.targets= from your kernel command line and reboot — the module then does nothing. Removing the packages also removes the module and its initramfs integration. For a single stock boot, edit the parameter out in your bootloader's edit screen. See the rollback section of the install guide.
Nothing — it's open source. The kernel module and packaging are GPL-2.0-only; the generated payload derives from a pinned CMP reference, and NVIDIA firmware remains under NVIDIA's own terms. The project page accepts voluntary support if you want to chip in for the author's GPU habit.
No. GPU Unlocker is an independent guide that documents the project, its numbers and its risks. The code and the authoritative documentation live at github.com/Zagitta/gpu-unlock (Ampere) and github.com/JustAResearcher/gpu-unlock-ada (Ada fork). If this site and a README ever disagree, the README is right — and we'd like to hear about it.
Most likely the timing, not the card. The module only acts in the initramfs, before the NVIDIA driver binds the card; a card that is already bound or powered down at that moment is skipped, and loading the module by hand after boot does nothing to a bound card. Check the boot log with journalctl -k -b | grep gpu_unlock, confirm gpu_unlock.targets= is actually on your kernel command line (cat /proc/cmdline), and make sure your card is a GA102, GA103, GA104 or GA106 model — anything else is logged and ignored.
Power off completely before trying again. That message is the project's documented failure mode: if a card's firmware never stops during the sequence, the module logs it and deliberately keeps the DMA buffers that firmware may still be using until the next power off. Don't keep poking it — a full power off is the documented recovery, and the install guide's rollback section covers the same ground.
You most likely have the OEM RTX 3080 Ti 20 GB built on the GA102-250 chip — the one documented exception in the project's tested-cards list. On that card the unlock completes, but BF16 throughput stays at the half rate. The retail 12 GB 3080 Ti is a different case (chip covered, no report yet). Full detail on the compatibility page.