Instalar GPU Unlock

1. Pick the fork that matches your card

The Ampere fork (Zagitta/gpu-unlock, v1.0.0) covers GA102, GA103, GA104 and GA106. The Ada fork (JustAResearcher/gpu-unlock-ada, v1.1.1) is that same module with AD102 (RTX 4090) and an experimental AD103 canary added, so it also handles the Ampere device list. The Turing fork (nlzy/turing-unlock, v2.0.0) is a separate module for the RTX 20 series: TU102, TU104 and TU106.

The Ada fork keeps the original GeForce/CMP GA102 and GA104 lists plus the newer GA103/GA106 list. Professional RTX A-series and data-centre parts are not accepted by any of them. Turing and Ampere/Ada modules are not interchangeable — a TU102 card will not be touched by `gpu_unlock`.

2. Clone and build the packages locally

None of the three forks ships prebuilt binaries: each builds on the target machine, because the firmware generation step is pinned to the NVIDIA firmware you already have installed.

# Ampere or Ada (RTX 30 / 40 series)
git clone https://github.com/Zagitta/gpu-unlock.git
# or: git clone https://github.com/JustAResearcher/gpu-unlock-ada.git

# Turing (RTX 20 series)
git clone https://github.com/nlzy/turing-unlock.git
cd turing-unlock
make install

All three forks use the same `make install` front end, which detects the distribution family. Explicit targets are `make install-arch`, `make install-deb` and `make install-rpm`. Kernel headers and a DKMS toolchain must already be present. The Turing build downloads two pinned NVIDIA files and verifies their SHA-256 — they stay in `~/.cache/turing-unlock/inputs`, and `make inputs` fetches them ahead of time.

3. Let the package wire the module into the initramfs

The unlock only applies if the module loads before the NVIDIA driver binds the card — `gpu_unlock` on Ampere/Ada, `turing_unlock` on the RTX 20 series. Loading it manually afterwards cannot unlock it, because the module refuses a card that already has a driver bound (`-EBUSY`). Each package therefore puts its module and firmware into the initramfs and loads it there.

# mkinitcpio: /etc/mkinitcpio.conf.d/zz-gpu-unlock.conf
# initramfs-tools: /usr/share/initramfs-tools/modules.d/gpu-unlock.conf
# dracut: /usr/lib/dracut/dracut.conf.d/gpu-unlock.conf

With initramfs-tools and dracut the module is rebuilt for every installed kernel that has headers, and images are rebuilt on install and on removal. Kernels installed later get the module from their own install hooks. mkinitcpio ignores drop-ins for an image built with `-c <config>` or a preset `_config` — put `gpu_unlock` (or `turing_unlock`) right before `nvidia` in that config's MODULES yourself.

4. Opt in on the kernel command line

The module does nothing unless the kernel command line asks for it. Set `gpu_unlock.targets=` to `all` for the Ampere path, or to explicit PCI addresses.

gpu_unlock.targets=all

There is no `softdep nvidia pre:` rule on purpose: kmod honours only the first `softdep nvidia` line it reads, so another package's rule would silently win. Boot order is handled by the initramfs drop-in instead.

5. Turing uses a different parameter name

The RTX 20 series module is `turing_unlock`, so the option is `turing_unlock.targets=` — not `gpu_unlock.targets=`. It accepts `all` or a comma-separated list of PCI addresses printed by `lspci -D`; case does not matter. Without the option the module loads and returns without touching anything.

# all accepted Turing cards
turing_unlock.targets=all

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

# add it per bootloader
# GRUB (Debian/Ubuntu): edit GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, then sudo update-grub
# GRUB (Arch): same file, then sudo grub-mkconfig -o /boot/grub/grub.cfg
# Fedora/RHEL: sudo grubby --update-kernel=ALL --args="turing_unlock.targets=all"
# systemd-boot / UKI: add it to the boot entry or /etc/kernel/cmdline

Targets are matched by PCI address, and the module serialises cards behind one mutex, so they are unlocked one at a time. If a driver already owns the card, the module leaves it alone and logs `unlock failed (-16)` (EBUSY) — that is a load-order problem, not a card problem. The module does a PCIe FLR first if the card state needs it. On success the card is not reset; a failed step may reset it, and the screen then stays blank until `nvidia-drm` takes over.

6. AD103 needs two opt-ins and one exact address

RTX 4070 Ti SUPER (`10de:2705`) is experimental and validated on a single card. It requires both `gpu_unlock.ad103_experimental=1` and `gpu_unlock.targets=` set to that card's single exact PCI address. `targets=all` never selects it.

gpu_unlock.ad103_experimental=1 gpu_unlock.targets=0000:21:00.0

Other Ada IDs, professional A-series and data-centre parts are not accepted. Shared firmware across Ada chips does not establish support for untested cards.

7. Know what happens across suspend

This applies to `gpu_unlock` (Ampere/Ada) only: it reapplies the override on resume, which can reset a display card. Add `gpu_unlock.resume=0` to the kernel command line — or write `0` to `/sys/module/gpu_unlock/parameters/resume` — to turn that off. Hibernation is not covered either way.

`turing_unlock` has no resume parameter and no resume hook; it runs once from the initramfs and has no module parameters besides `targets`.

8. Persist the boot entry only after a cold boot works

Validate one cold boot and one warm reboot on the exact card first. Only then make the bootloader entry persistent. Keep an unmodified stock entry available, and re-verify `gpu_unlock: unlocked`, the rate readback and GPU health after each boot.

The tested canary uses a kernel-version-specific image; regenerate and revalidate it before removing its pinned kernel during an upgrade.

9. Do not let the driver load early

Avoid `nvidia-smi`, CUDA, NVML and `nvidia-modprobe` before a manual cold-card attempt: they can load NVIDIA by name, and ordinary modprobe blacklist rules do not block explicit named loads. The packaged initramfs flow avoids the need for manual firmware staging.