GitHub Daily Recommendation | gpu-unlock-ada: Double the Tensor Compute of Ada GPUs

One-line summary

Project URL: https://github.com/JustAResearcher/gpu-unlock-ada

gpu-unlock-ada is a kernel-level unlock solution for NVIDIA Ada-architecture consumer graphics cards. It loads a kernel module during Linux startup, ahead of the official driver, and modifies the GPU's streaming multiprocessor speed-gear control registers. This raises the RTX 4090's FP16/FP32 and BF16/FP32 tensor throughput from 165 TF/s to 331 TF/s, nearly doubling performance. INT8, dp4a, and other operator rates stay at baseline. The unlocked state persists after a PCIe function-level reset, and persistent boot configuration is supported.

Currently verified on three models: RTX 4090, RTX 4070 Ti SUPER, and RTX 4060 Ti 16GB. Compatibility with other Ada models is unconfirmed.

What problem it solves

NVIDIA locks down the tensor core speed-selector configuration on consumer Ada GPUs by default, leaving FP16/BF16 tensor throughput below the hardware's physical ceiling. Professional RTX A-series cards are not subject to this restriction, but they cost several times more.

Deep learning training and inference rely heavily on FP16/BF16 matrix multiplication. Libraries such as cuBLAS and CUTLASS call tensor cores through the GPU's default speed gear, so under the same power limit, usable compute is artificially depressed, training iteration times grow, and inference throughput is capped.

gpu-unlock-ada removes this artificial limit by modifying the speed selector at the hardware level, bringing consumer cards close to the tensor-compute level of professional cards. Users do not need to replace drivers or change application code; the performance gain is transparent.

Core concepts

SM speed selector override: The streaming multiprocessor contains speed-gear control registers whose values map to frequency multipliers for different operator types. This project writes SS0 to 0x88888888 and SS1 to 0x8 to enable full-rate tensor operators.

Booter payload: A packaged form of the GPU firmware boot code segment and its signature sequence. It includes the FWSEC-FRTS and V67 signatures and is used to perform register writes in protected mode.

PCIe FLR: PCIe Function Level Reset resets device state without cutting power. After the firmware completes register modifications, it triggers an FLR so that the NVIDIA driver takes over a clean GSP (GPU System Processor) state.

WPR2: A protected-register-region status flag. After firmware initialization, a nonzero value causes the firmware to refuse a repeated run sequence, a safety measure. A cold boot clears the flag; a warm reboot may preserve it and cause a second run to fail.

Architecture breakdown

The project is split into firmware generation and a kernel module.

Firmware generation lives in the firmware/ directory. extract_boot_assets.py extracts the Booter and GSP boot assets from the NVIDIA 610.43.03 driver source, verifies their SHA-256 hashes, and packages them into binary firmware that the module can load. decode_debug_booter.py is used for offline Booter analysis and debugging and requires key control.

The kernel module lives in kernel/gpu_unlock/. main.c is the entry point and handles device enumeration, firmware loading, and asynchronous concurrent scheduling. prep_610.c prepares DMA buffers, layout descriptors, and VBIOS metadata. unlock_610.c executes the V67 unlock transaction, completing the full flow: firmware loading, register writes, and FLR triggering.

The module must be loaded from the initramfs, ahead of the official NVIDIA driver. During device enumeration it checks whether each PCI device ID is on the supported list; matched cards get an asynchronous task. All cards run the unlock flow concurrently, and failure on one card does not affect the others.

The AD102 payload comes from published data in TOTORONG/AD103_win_unlocker, integrated into this project's Linux kernel module path.

Key implementation walkthrough

Device enumeration and parameter validation

static int __init gpu_unlock_init(void)
{
	struct pci_dev *pdev = NULL;
	bool all;
	int ret;

	/* Loaded ahead of nvidia on every boot; the command line is the opt-in. */
	if (!targets || !*targets)
		return 0;
	all = !strcmp(targets, "all");
	if (!all)
		report_unmatched();
	while ((pdev = next_supported(pdev))) {
		if (pdev->device == GU_AD103_RTX_4070_TI_SUPER &&
		    (all || strcasecmp(targets, pci_name(pdev)))) {
			pci_err(pdev, "gpu_unlock: experimental AD103 requires a single exact PCI target\n");
			continue;
		}

What it does: At module initialization, the kernel command-line parameter gpu_unlock.targets is checked. If empty, the module returns immediately and stays silent. When targets is all, all supported cards are enumerated; otherwise only PCI addresses matching the argument are processed. An AD103 (RTX 4070 Ti SUPER) is skipped with an error message when all or a non-exact match is detected.

Why it is written this way: The module loads before the NVIDIA driver on every boot, so the command-line parameter is the user's opt-out switch. The AD103 chip is experimental and its payload stability is not fully verified; forcing the user to explicitly specify a single card address and enable the experimental flag avoids accidentally triggering it in a multi-card configuration.

What would happen without it: Without the parameter guard, the module would try to unlock every detected card, potentially modifying hardware state without the user's confirmation. Without the single-address check for AD103, all would trigger the experimental chip and add unknown risk.

Firmware asset packaging

def build_bundle(source_text: str) -> bytes:
    image, _, _ = _array_bytes(source_text, "IMAGE_PROD")
    header, _, _ = _array_bytes(source_text, "HEADER_PROD")
    signatures, _, _ = _array_bytes(source_text, "SIG_PROD")
    patch_loc, _, _ = _array_bytes(source_text, "PATCH_LOC")
    patch_meta, _, _ = _array_bytes(source_text, "PATCH_META")
    num_sigs, _, _ = _array_bytes(source_text, "NUM_SIGS")
    if len(header) != 36 or len(patch_loc) != 4 or len(patch_meta) != 12 or len(num_sigs) != 4:
        raise ValueError("unexpected BooterLoad record size")
    fields = struct.unpack("<9I", header)
    loc = struct.unpack("<I", patch_loc)[0]

What it does: Six C arrays (IMAGE_PROD, HEADER_PROD, SIG_PROD, PATCH_LOC, PATCH_META, NUM_SIGS) are extracted from the NVIDIA driver source text. The lengths of the header, patch-location, patch-meta, and signature-count fields are validated, then unpacked into integer structs.

Why it is written this way: NVIDIA's driver source embeds the firmware image and signature sequences as C arrays. Parsing the text directly to extract byte streams avoids dependence on NVIDIA's private build tooling. Fixed-length checks ensure the data structures have not changed and correspond to the SHA-256 hashes hardcoded in the module.

What would happen without it: The module would have no way to obtain an authenticated Booter payload. The hardware security module would refuse to execute unsigned firmware, and the register write would fail. Manually constructing a signature is nearly impossible, so relying on official driver assets is the only viable path.

Hands-on

Clone the repository, compile, and install the module:

git clone https://github.com/JustAResearcher/gpu-unlock-ada.git
cd gpu-unlock-ada
make install

make install automatically runs extract_boot_assets.py to generate the firmware, compiles the kernel module, copies it to the corresponding directory under /lib/modules/, and updates the initramfs.

Cold-boot the machine, edit the kernel command line in the GRUB boot menu, and add the parameter specifying the target GPU:

gpu_unlock.targets=0000:03:00.0

Multiple cards are separated by commas:

gpu_unlock.targets=0000:03:00.0,0000:04:00.0

Unlock all supported cards (excluding experimental models):

gpu_unlock.targets=all

AD103 or AD106 models must be specified individually and have the experimental flag enabled:

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

After boot, check the kernel log to confirm the unlock. A successful result prints gpu_unlock: unlocked. Run a cuBLAS GEMM test to verify that FP16/BF16 throughput has doubled.

For persistent configuration, write the parameters to the GRUB_CMDLINE_LINUX line in /etc/default/grub, run update-grub, and reboot. Keep the original boot entry for rollback.

Application scenarios

FP16 training acceleration on research servers: Deep learning teams run PyTorch and TensorFlow training on Linux servers and make heavy use of mixed precision (FP16/FP32). After installing the module, specify the GPU's PCI address in GRUB, verify the logs after a cold boot, then persist the boot entry. Matrix multiplication throughput doubles during training and iteration time shrinks. Check the logs on every boot to confirm the unlock state; the first attempt must be a cold boot to clear the WPR2 flag.

Selective unlock on multi-GPU workstations: A workstation with four RTX 4090 cards can get full PCI addresses via lspci and pass them comma-separated to the targets parameter. Cards used for rendering stay locked, while cards dedicated to compute are unlocked. AD103/AD106 must use a single address with the experimental flag; all will not select them and avoids accidental operation.

cuBLAS GEMM throughput optimization: High-performance computing applications call cuBLAS or CUTLASS directly for matrix multiplication. After unlocking, run FP16/BF16 GEMM benchmarks to measure the real gain and verify speedup for specific matrix shapes. The README records shape dependence: a 4096^3 BF16 matrix shows essentially no change, while other shapes improve significantly. This is not whole-application acceleration; it only affects tensor operators.

Independent analysis

Independent analysis: the repository gained 692 stars within 24 hours, showing strong community interest in Ada GPU unlocking. Three open issues center on compatibility with unverified models and long-term stability, which means users have already started real deployments.

The RTX 4090 README table records FP16-to-FP32 accumulation rising from 165.6 TF/s to 331.6 TF/s. An independent owner measured 160.4 to 320.4 TF/s on commit 8855e7b, showing high data consistency. The RTX 4070 Ti SUPER went from 95.0 to 189.9 TF/s under its 240W power limit, doubling power efficiency. INT8 and dp4a operator rates stay at baseline, which proves the modification only affects the tensor path controlled by the speed selector.

Compared with the official NVIDIA driver's default state, FP16/FP32 compute is doubled while INT8 and FP32 scalar operations stay at baseline, concentrating the gain on the target data types. Compared with the original Zagitta/gpu-unlock, this version integrates an AD102 payload, supports Ada, and keeps the GA102/104 paths, so architectural continuity is good. Compared with professional RTX A-series cards, pro cards are already full-rate and are not on the support list; this module specifically removes the artificial limit on consumer cards.

The project depends on the published payload from TOTORONG/AD103_win_unlocker and uses NVIDIA 610.43.03 firmware assets verified by SHA-256 hash. The firmware generation flow is fully reproducible, and users can audit the Python scripts and C code themselves, making it more transparent than closed-source tools.

Limitations and risks

Verified only on the RTX 4090, RTX 4070 Ti SUPER, and RTX 4060 Ti 16GB; other Ada models have unconfirmed compatibility. The RTX 4070 Ti SUPER has validation data from only a single card, a small sample size.

FP8 measurements show a 0.3% gain on a single GEMM, with no obvious improvement. Other FP8 kernels were not tested, so performance changes are unknown. A 4096^3 BF16 matrix shows essentially no change; users must verify shape-dependent gains themselves.

The module loads from the initramfs and requires the explicit gpu_unlock.targets kernel parameter. It involves firmware generation and EFI configuration, so the barrier is higher than for user-space tools. Users must compile and manage the initramfs themselves, and reinstalling the module is required after every kernel update.

The first cold-boot attempt must be a full power-off restart. A warm reboot may preserve WPR2 state and cause the firmware to refuse a second run. The README records one successful warm reboot on the RTX 4070 Ti SUPER; behavior on other boards is uncertain.

There is no long-term stability testing, so validating on non-production hardware first is recommended. GPU vendor firmware updates may change register layouts or signature sequences and break the module. Users must also assess the authorization and legality of the external payload; NVIDIA may respond with driver updates or UEFI Secure Boot policies that block this kind of modification.

Verdict card

Who it is for: Linux deep learning researchers who need to maximize FP16/BF16 tensor throughput on Ada GPUs, have system administration privileges and kernel module compilation experience, and are willing to accept the risk of experimental tooling.

Who it is not for: People primarily on Windows, people without kernel module compilation experience, anyone with strict production stability requirements, or anyone holding an unverified GPU model.

Recommended path: Start with a single-card cold-boot verification, keep the original boot entry, and gradually expand to multi-card or persistent configuration. Run your own GEMM tests to confirm the actual gain and do not make decisions based on README data. Monitor kernel logs and GPU temperature, and if anything abnormal appears, switch back to the un-unlocked boot entry immediately.

---

Project URL: https://github.com/JustAResearcher/gpu-unlock-ada

Original: https://tools.wflynn.cn/aitools/github-trending

Follow the WeChat official account "YourTools" for daily GitHub trending and open-source tool briefings: