NVIDIA GPU Unlock: RTX 4090 Tensor Core Throughput Doubles

NVIDIA GPU Unlock: RTX 4090 Tensor Core Throughput Doubles

Open-source developers have uncovered previously restricted compute throughput in several NVIDIA GeForce GPUs without replacing hardware, flashing a modified video BIOS, or patching the official NVIDIA driver.

In one of the most striking demonstrations, an NVIDIA GeForce RTX 4090 increased its measured Tensor Core instruction throughput from 165.6 TFLOPS to 331.6 TFLOPS when executing FP16 input operations with FP32 accumulation. BF16 input with FP32 accumulation showed a similarly dramatic improvement, rising from 165.5 TFLOPS to 330.6 TFLOPS.

The results extend beyond the RTX 4090. Community experiments involving the RTX 3090 Ti, RTX 3080, RTX 3070, RTX 3060, RTX 2080 Ti, and selected RTX 40-series configurations have reported substantial gains in specific compute workloads.

The underlying technique is not conventional overclocking. Instead, the projects modify GPU configuration registers that control the instruction issue rates of particular compute operations. By applying these changes during the GPU boot process, developers have demonstrated that certain Tensor Core execution paths can operate at higher throughput while retaining the original NVIDIA driver.

However, the distinction between theoretical instruction throughput and application performance is critical. Doubling the throughput of a particular instruction does not mean that AI training, inference, or gaming performance will also double.

This article examines the open-source projects, benchmark results across GPU generations, underlying mechanisms, real-world AI performance, and the limitations that remain.

🚀 1. RTX 4090: Nearly Double the Tensor Core Instruction Throughput

#

The most prominent demonstration comes from the open-source project gpu-unlock-ada, developed by JustAResearcher.

The project targets NVIDIA Ada Lovelace GPUs and initially demonstrated the technique on an RTX 4090 equipped with the AD102 GPU.

FP16 and BF16 throughput before and after unlocking

#

The original RTX 4090 tests measured the throughput of Tensor Core operations using reduced-precision input data and FP32 accumulation.

The reported results were:

The developer subsequently increased the benchmark loop count from 20,000 to 40,000 iterations to check whether the result was an artifact of the measurement procedure.

The longer tests produced the following throughput:

These measurements remained consistent with the original results, supporting the conclusion that the affected instruction paths had gained substantially higher throughput.

An independent RTX 4090 owner subsequently reproduced the result using reviewed project code. The retest used Linux kernel 7.2.11-arch1-1, NVIDIA driver 615.78.08, the same GPU before and after unlocking, and an unchanged 450 W power limit.

The independent measurements were:

Both operations again approached a 2× increase in measured instruction throughput.

For the original experiment, the test configuration used an AD102 GPU with 128 streaming multiprocessors (SMs), Linux kernel 7.2.4, and NVIDIA driver 615.78.08, with a 450 W power limit.

The independent retest is important because it shows that the observed gain was not limited to a single benchmark execution. Nevertheless, these results establish performance behavior on the tested configurations rather than universal compatibility across every RTX 4090 board or firmware revision.

What changed inside the GPU?

#

The technique works by modifying GPU configuration registers associated with the execution rates of specific instructions.

According to the project’s technical report, the configuration change takes place during the GPU’s firmware execution and boot sequence, before the standard NVIDIA driver initializes the graphics card.

The GPU’s firmware execution flow is used to obtain the necessary permissions to modify protected register settings. The program then changes the relevant instruction-rate selectors and performs a PCIe Function Level Reset (FLR).

Afterward, the unmodified NVIDIA driver takes control of the GPU and initializes normally.

The original experiment used this sequence to demonstrate that the configuration persisted through the reset and subsequent driver initialization. An independent owner later repeated the stock-driver handoff and throughput comparison.

The crucial distinction is that the method does not add Tensor Cores or physically increase the number of execution units. It changes the configuration governing how selected operations are dispatched through existing hardware resources.

Not every operation gets faster

#

The RTX 4090 results also reveal important limits.

These results indicate that the technique targets selected instruction execution paths rather than universally increasing all GPU compute capabilities.

FP16 input with FP16 accumulation already achieved substantially higher throughput before the modification. INT8 and ordinary scalar FP32 operations also remained near their original performance.

The practical implication is that the optimization is most valuable when a workload spends significant time executing the specific instruction types affected by the register configuration.

📈 2. RTX 30 Series: Major Gains on Ampere GPUs

#

The same general approach has been applied to NVIDIA Ampere GPUs through the open-source project gpu-unlock, developed by Zagitta.

The project combines low-level GPU configuration research with a Linux kernel module that performs the necessary changes before the proprietary NVIDIA driver takes control.

Reported results cover several RTX 30-series graphics cards, with substantial improvements in BF16, TF32, and selected FP16 operations.

RTX 3090 Ti approaches twice the TF32 throughput

#

The RTX 3090 Ti produced particularly strong results under a 450 W power limit.

These measurements show that changing the execution-rate configuration can translate into substantial performance gains for actual matrix multiplication workloads, not just isolated instruction benchmarks.

The results differ from the RTX 4090 case because the reported Ampere benchmarks measure matrix-operation throughput rather than relying exclusively on low-level instruction microbenchmarks.

This distinction matters when comparing results across architectures. Instruction throughput, dense matrix-multiplication throughput, and application-level performance are related but separate metrics.

Results across the RTX 30 series

#

Community testing has also reported improvements on other Ampere graphics cards.

The RTX 3070 and RTX 3060 figures represent reported percentage gains; comparable absolute measurements were not provided in the source material.

Although the magnitude varies by GPU and workload, the results suggest that the performance limitation is not exclusive to the latest Ada Lovelace architecture.

The Ampere implementation uses the same broad principle: modify relevant GPU instruction-rate settings before the standard driver loads, then benchmark the resulting configuration.

How the Ampere unlock works

#

The project draws on earlier CMP GPU unlocking research and low-level firmware execution techniques.

NVIDIA GPUs contain protected configuration registers, including speed-select controls commonly referred to as SS0 and SS1. These controls affect the execution rates of particular instruction classes.

The technique combines a privileged firmware execution path with a method involving Return-Oriented Programming (ROP) and modification of the Privilege Level Mask (PLM). These operations are used to obtain the permissions needed to write the protected configuration registers.

The project’s implementation configures SS0 to 0x88888888 and SS1 to 0x8 for the relevant execution paths.

The process is integrated into a Linux kernel module that runs before the normal NVIDIA driver binds to the GPU. Following the register changes, the module performs an FLR so that the GPU can be handed back to the standard driver.

This architecture allows the modified configuration to take effect without patching the installed NVIDIA driver itself.

However, an unchanged driver is not equivalent to an officially supported operating state. The GPU still relies on a low-level configuration outside its normal supported configuration, and compatibility must be established separately for each tested hardware and software combination.

🧪 3. RTX 3080: Matrix Benchmarks and Real AI Workloads

#

The RTX 3080 experiments provide a useful bridge between low-level throughput measurements and practical applications.

A developer tested an RTX 3080 10GB under a 320 W power limit, measuring both matrix-operation throughput and sustained workloads.

Matrix multiplication gains under a fixed power limit

#

For FP16 input with FP32 accumulation, the reported matrix-operation throughput increased from 64.88 TFLOPS to 110.14 TFLOPS, a gain of approximately 70%.

The developer also ran a continuous 120-second test that alternated between FP16 and BF16 matrix operations.

The test indicates that the additional throughput was not achieved by raising the configured power limit.

The reported calculation outputs also matched before and after unlocking across FP16, BF16, and TF32 matrix-operation tests.

That numerical comparison is an important validation step. An optimization that produces higher throughput is not useful if it introduces incorrect computation results.

However, matching outputs for the tested operations does not establish correctness for every possible matrix shape, numerical edge case, or application. A production deployment would require broader validation.

The measurements instead demonstrate that the selected instruction-rate modification can translate into sustained matrix-compute gains on the tested RTX 3080 configuration.

Why the gains differ between workloads

#

Not every operation benefited.

The RTX 3080 tests found little change in FP16 input with FP32 accumulation under a configuration that already achieved approximately 112 TFLOPS in the relevant comparison, while INT8 and ordinary FP32 operations also showed little or no improvement.

As with the RTX 4090, the result depends on which compute path the workload uses.

Application performance also depends on data movement, launch overhead, memory bandwidth, kernel configuration, and the ability of the scheduler to keep the GPU’s compute units busy.

This is why a gain measured in a targeted matrix benchmark should not automatically be applied to unrelated applications.

Real-world LLM inference: Prefill improves, decoding does not

#

The most interesting application-level reports involve large language model inference.

One RTX 3090 user running a 27-billion-parameter BF16 model through vLLM reported approximately:

• 33% higher prompt-prefill speed.
• 24% lower time to first token.

Another developer using two RTX 3080 cards with expanded VRAM reported approximately 33% to 36% improvements in large-model prefill tests.

These results are more modest than the near-doubling observed in selected low-level operations, but they illustrate how instruction throughput can affect real AI applications.

The important detail is that token generation speed remained largely unchanged in both reported experiments.

Why prompt prefill benefits more than token generation

#

LLM inference involves two distinct computational stages.

Prompt prefill processes the input prompt and builds the initial model state. This stage performs substantial parallel matrix computation and can benefit from increased Tensor Core throughput.

Autoregressive decoding generates output tokens sequentially. Each token depends on the preceding state, and practical decoding performance is often constrained by weight and cache movement, memory bandwidth, batch size, or other execution bottlenecks.

If the workload is primarily limited by GPU compute, increasing the throughput of relevant matrix operations can accelerate it significantly.

If the workload is limited by memory traffic, increasing compute throughput alone may provide little additional benefit.

The RTX 3090 and RTX 3080 reports are consistent with this distinction: prefill accelerated, while per-token generation speed changed little.

For AI practitioners, the lesson is straightforward. Benchmark the exact model, inference engine, batch size, sequence length, and hardware configuration that matter to the deployment. A Tensor Core throughput improvement is a useful indicator, but it is not a substitute for end-to-end performance testing.

🕰️ 4. RTX 2080 Ti: Revisiting Turing’s Hidden Compute Potential

#

The investigation has also reached NVIDIA’s Turing architecture.

Released in 2018, the GeForce RTX 2080 Ti is an older GPU, but it still contains Tensor Cores capable of accelerating suitable matrix operations. Developers have now demonstrated that selected Turing configurations can also benefit from changes to instruction execution rates.

Two open-source projects provide useful examples, although their hardware configurations and implementation methods differ.

Linux-based experiments with turing-unlock

#

Developer nlzy adapted the general approach to Turing GPUs in the turing-unlock project.

The reported tests used a Dell RTX 2080 Ti with a non-standard 22 GB VRAM configuration under a 250 W power setting.

This is not a typical retail RTX 2080 Ti, which normally ships with 11 GB of VRAM. The modified card therefore needs to be considered separately when interpreting the results.

Using cuBLAS matrix multiplication with FP16 input and FP32 accumulation, the developer measured the following throughput:

The gains varied with matrix size, indicating that workload characteristics and execution efficiency continued to affect the final result.

For context, NVIDIA’s Turing architecture documentation lists approximately 56.9 TFLOPS as the RTX 2080 Ti’s peak FP16 Tensor Core throughput under the relevant published specifications.

A measured result exceeding that nominal figure does not mean that the physical GPU has acquired additional Tensor Cores. Rather, it indicates that the original execution-rate configuration and the assumptions behind the reported peak require careful interpretation when comparing the specific instruction-level and benchmark measurements.

The key finding is that the tested card delivered substantially higher measured matrix throughput after the configuration change.

Independent Turing research using a UEFI execution path

#

A separate project, Turing-unlock, investigated an ASUS RTX 2080 Ti using the TU102 GPU and a standard 11 GB VRAM configuration.

Unlike the Linux kernel-module approach, this implementation executes its configuration-modification procedure before the operating system loads, using a UEFI-based mechanism.

The developer reported the following results for low-level matrix multiply-accumulate (MMA) instructions:

These figures closely match the approximate doubling seen in the RTX 4090 instruction-throughput tests.

The results also demonstrate why a direct comparison between instruction-level measurements and application benchmarks is necessary.

In an 8192 × 8192 cuBLAS matrix multiplication test, the same project reported throughput increasing from 48.15 TFLOPS to 85.17 TFLOPS, an improvement of approximately 76.9%.

Although the actual matrix-multiplication gain was substantial, it remained below the nearly 2× increase in the low-level MMA benchmark.

The two Turing projects support the broader observation that execution-rate restrictions may affect specific Tensor Core operations across multiple GPU generations. They do not establish that every RTX 20-series graphics card is compatible or that all Turing workloads benefit equally.

🪟 5. Windows 11: Early Experiments on an RTX 4080

#

Most of the projects described above focus on Linux. However, developers have also demonstrated a related technique in a Windows 11 environment.

The project AD103_win_unlocker investigates modifying GPU configuration before Windows takes control of an RTX 4080.

UEFI configuration before Windows startup

#

The reported test hardware was an RTX 4080 based on the AD103 GPU with a modified 32 GB VRAM configuration.

This is not a standard retail RTX 4080 configuration, so its results should not be generalized to all RTX 4080 cards.

The implementation uses a UEFI application to perform the configuration changes before Windows boots. It then hands control to the operating system, allowing the GPU to operate with the original NVIDIA driver.

The published matrix multiplication measurements were obtained through WSL2 on the Windows host.

The results suggest that the configuration-modification technique is not limited to Linux kernel modules.

However, the experiment remains a single-card demonstration using modified hardware and a specific boot configuration. It does not establish universal compatibility across ordinary RTX 4080 cards, other RTX 40-series models, or arbitrary Windows and driver versions.

🔬 6. Why Instruction Throughput Does Not Equal Application Performance

#

Across these experiments, one pattern appears repeatedly: low-level instruction throughput often improves more than real application performance.

Understanding this difference is essential when assessing whether a GPU unlock provides meaningful value.

Instruction throughput measures a narrow part of execution

#

A microbenchmark designed to measure instruction throughput attempts to keep the tested compute units busy while minimizing unrelated overhead.

For example, a benchmark can repeatedly execute a particular Tensor Core operation using controlled data and carefully chosen launch parameters.

If the operation’s issue rate changes from one instruction per cycle to a higher effective rate, the measured throughput can increase dramatically.

However, this measurement does not account for every bottleneck in an application.

Matrix multiplication adds execution overhead

#

A practical matrix multiplication implementation involves more than issuing Tensor Core instructions.

It can include:

• Loading and moving input data.
• Managing shared memory and register usage.
• Synchronizing threads and execution blocks.
• Scheduling operations across streaming multiprocessors.
• Handling matrix dimensions that do not align with ideal tile sizes.
• Writing output data and coordinating kernel execution.

Consequently, the proportion of total execution time affected by the unlock depends on the workload.

A compute-heavy, well-optimized matrix operation may capture a substantial fraction of the available improvement. A workload dominated by memory transfers or synchronization may capture considerably less.

The RTX 4090 results illustrate this difference. Although the targeted FP16 and BF16 instruction throughput nearly doubled, FP16 cuBLAS matrix multiplication improved by approximately 12% to 34%, depending on matrix size.

For a 4096 × 4096 matrix multiplication, the reported FP16 result increased from 153.2 TFLOPS to 206.0 TFLOPS, a gain of approximately 34.4%.

BF16 performance was less consistent. Tests at 1024 × 1024 and 8192 × 8192 improved by approximately 19.6% and 16%, respectively, while the 4096 × 4096 test showed little change.

These differences demonstrate that a higher instruction issue rate does not guarantee proportional gains from a complete compute kernel.

Power limits and clock speeds still matter

#

The reported gains were achieved without increasing configured power limits or applying conventional manual overclocking.

Nevertheless, actual performance remains affected by operating clocks, cooling, power management, and workload-dependent utilization.

The RTX 4090 experiments retained a 450 W power limit, while the RTX 3080 sustained-workload test operated at approximately 318 W.

Holding a power limit constant helps isolate the effect of the configuration change, but it does not guarantee identical performance characteristics across all workloads or operating conditions.

AI inference performance depends on the bottleneck

#

In LLM inference, prompt prefill and token generation may be constrained by different resources.

Prefill often performs large, parallel matrix calculations, making it a natural candidate for benefiting from higher Tensor Core throughput.

Decoding, on the other hand, can be dominated by the cost of moving model weights and intermediate data through memory, especially at small batch sizes.

This explains why an approximately 33% improvement in prefill throughput can coexist with almost unchanged token generation speed.

The correct evaluation metric therefore depends on the deployment requirement: prompt processing latency, time to first token, sustained tokens per second, total throughput, or energy efficiency.

⚠️ 7. Security, Compatibility, and Hardware Risks

#

Although these projects demonstrate substantial performance improvements, they are experimental low-level modifications rather than ordinary driver settings.

They should not be treated as universal performance upgrades.

The official driver remaining unchanged does not mean the method is supported

#

The projects modify protected GPU configuration through firmware execution or pre-OS mechanisms.

The standard NVIDIA driver may load successfully afterward, but it is operating on a GPU whose configuration differs from the normal supported initialization path.

A successful boot and benchmark do not establish that every relevant hardware condition, firmware version, driver update, or workload is safe.

Firmware execution introduces additional risk

#

The techniques described in these projects rely on privileged execution paths, register modification, and boot-time handoff procedures.

Incorrect configuration or unexpected firmware behavior could cause initialization failures, system instability, or loss of GPU access.

Some implementations also depend on GPU-specific firmware behavior and hardware identifiers. A technique demonstrated on one GPU should not be assumed to work on another model simply because both belong to the same architectural family.

Kernel and driver compatibility must be verified

#

Linux projects may depend on the kernel module build environment, bootloader configuration, initramfs generation, firmware inputs, and the order in which device drivers are initialized.

The Windows implementation relies on a different boot-time mechanism and has a different validation scope.

Driver updates may also affect compatibility or change the conditions under which the modified configuration persists.

Benchmark correctness is necessary but not sufficient

#

Several of the projects report matching matrix outputs before and after unlocking, which supports the numerical correctness of the tested operations.

However, a limited collection of matching outputs does not prove correctness across all input values, matrix sizes, numerical formats, or application kernels.

For workloads involving model training, scientific computing, or production inference, broader testing is necessary to check numerical behavior, reliability, and sustained operation.

Distinguish compute unlocks from power-limit modifications

#

These projects primarily target instruction-rate configuration rather than raising the GPU’s electrical power limit.

That makes them fundamentally different from hardware power modifications, such as the shunt modification described in PUDN’s RTX 4090 Laptop GPU performance report, which changes the behavior of power measurement circuitry.

Likewise, firmware-based feature unlocking is distinct from ordinary overclocking, which typically changes clock frequency, voltage, or power targets.

The distinction matters because a workload can become faster by changing its effective instruction throughput even when the configured power limit remains unchanged.

However, the absence of a power-limit increase does not eliminate the risks associated with modifying protected GPU configuration.

For additional context on the broader GPU-unlocking landscape, KAD’s analysis of NVIDIA CMP 170HX memory unlocking discusses a different form of low-level GPU modification and explains why unlocking a feature does not guarantee that every hardware resource will operate reliably.

📊 8. Summary of NVIDIA GPU Unlock Results

#

The reported experiments cover several GPU generations and different benchmark levels.

These figures are not directly comparable. They combine low-level instruction benchmarks, matrix multiplication measurements, and results obtained on different physical GPU configurations.

Their common finding is narrower but important: selected Tensor Core execution paths on certain NVIDIA GPUs can achieve substantially higher measured throughput after low-level configuration changes.

🌌 Conclusion: Unlocking Existing GPU Hardware Through Open Research

#

The recent NVIDIA GPU unlock projects highlight an important distinction between a GPU’s physical resources and the performance delivered by a particular execution configuration.

On the RTX 4090, selected FP16 and BF16 Tensor Core instruction paths achieved nearly twice their previous measured throughput without changing the configured power limit, replacing the GPU, or modifying the official NVIDIA driver.

Similar techniques have produced substantial matrix-compute gains on several RTX 30-series cards, while experiments on the older RTX 2080 Ti suggest that the underlying behavior is not limited to recent architectures. Initial Windows 11 experiments also indicate that alternative boot-time mechanisms can reach comparable results on a specifically modified RTX 4080.

The most important qualification is that doubling selected instruction throughput does not mean doubling overall GPU performance. Real workloads also depend on memory bandwidth, scheduling, matrix dimensions, utilization, and application-specific bottlenecks.

For AI developers, these projects are especially interesting because compute-heavy workloads such as prompt prefill can benefit significantly, even when memory-bound token generation remains largely unchanged.

For researchers, the findings demonstrate the value of open-source hardware analysis and reproducible benchmarking. They also reinforce the importance of distinguishing measured performance gains from universal hardware guarantees.

Ultimately, the potential benefit depends on three conditions: whether a particular GPU supports the required configuration, whether the target workload uses the affected instructions efficiently, and whether the resulting system remains correct and stable.

The emerging research does not turn every GeForce GPU into a universally faster accelerator. It reveals something more specific: in certain circumstances, existing hardware may deliver significantly more compute throughput than its default instruction-rate configuration suggests.