- What happened: Hands-on reports are accumulating that the unofficial tool "nv-uefi-unlocker" speeds up matrix operations and image generation on GeForce GPUs under Windows.
- Why it matters: The results confirm that lifting the Tensor-operation limit can shorten processing time in real applications. However, some configurations are reported to lose the effect after Windows starts, even when the unlock succeeds in UEFI.
- What to watch next: Reproducibility on Windows across different GPUs, plus real-application performance that accounts for boot-time security protections and power limits, result accuracy, and long-term stability.
Hands-on reports are accumulating for "nv-uefi-unlocker," an unofficial tool that lifts the limit on Tensor operations on NVIDIA GeForce GPUs before Windows boots. Users say it sped up matrix operations and image generation on Windows. In a GeForce RTX 4060 Ti test posted on October 28, 2026, image generation time per image fell from 12.1 seconds to 8.0 seconds under specific conditions. The mechanism runs the unlock from UEFI and hands the unlocked state over to Windows, whereas unlocking had previously been done mainly on Linux. However, there is also a reported case of an external GPU that reverted to its original state after Windows started, even though the unlock succeeded in UEFI. To judge practical usefulness, three things need to be checked separately: whether the unlock succeeds in UEFI, whether the state persists after Windows starts, and whether performance actually improves in the target application.
What does it rewrite on a GeForce card before Windows starts?
nv-uefi-unlocker targets a limit on the instruction issue rate of Tensor operations, which take low-precision numbers as input and accumulate results in FP32 precision. It does not raise the GPU's overall FP32 performance, nor does it increase VRAM capacity or memory bandwidth. The supported input formats include FP16 and BF16, but Turing-generation GPUs do not support BF16. Even among supported GPUs, therefore, the usable operation formats differ by generation.
The conventional method intervened from the Linux initial RAM disk (initramfs) before the GPU was initialized. In contrast, according to a test report on an Ada-generation GPU published by the developer, nv-uefi-unlocker starts the GPU firmware at the UEFI DXE stage, before the OS boots, and performs the necessary modification. It then hands control to the Windows Boot Manager, so Windows starts with the unlocked state intact. This differs from approaches that change the Windows registry or rewrite the GPU's VBIOS.
The modification exploits a missing bounds check when signature data is copied. Specifically, it uses a stack overflow and ROP (Return-Oriented Programming), which executes code by chaining existing code fragments, to change the GPU's protection settings and allow writes from the host side. The boot process uses a signed Booter and GSP-RM, but that does not mean NVIDIA has approved the modification.
In the hands-on test the developer published on October 26, the system used was an ASUS ROG Strix G16 G614JV with an RTX 4060 Laptop GPU. The GPU has 20 SMs and 8 GiB of VRAM, and the display was connected directly to the discrete GPU. Running a 4096×4096 FP16 matrix multiplication on Windows with data fitting in the L2 cache, performance rose from 29.89 TFLOPS to 49.02–49.33 TFLOPS. That is an improvement of about 1.65x, but it applies only to this GPU and these measurement conditions.
Support for RTX 20–40 series is a separate question from confirmed Windows operation
In its official README on GitHub, the developer lists support for the RTX 20, 30, and 40 series. However, the support status is divided into GPUs confirmed on real hardware, GPUs verified in the upstream implementation of a similar approach, and GPUs whose code path is implemented but not yet confirmed on hardware. Even if the design can handle a given device ID, operation on Windows is not guaranteed for every product in that series.
The preparation required also differs by generation. RTX 20-series cards require the GSP firmware mode to be set beforehand, while the RTX 30 series reportedly does not. Blackwell-generation GPUs are not among the supported targets. Belonging to a supported series is one thing; being able to keep the unlock effective in an actual PC configuration is another, and the two should be considered separately.
On October 28–29, users of the RTX 4070 Ti SUPER, RTX 4080, and RTX 4060 Ti posted Windows performance results one after another. The reports measure different things, however. A microbenchmark of Tensor instruction issue rate, the throughput of large matrix operations, and image generation time each show the effect of the unlock differently, so the reported multipliers cannot be compared directly.
Tensor instruction issue rate roughly doubles, with large gains in matrix operations
For the RTX 4070 Ti SUPER, a microbenchmark of Tensor instruction issue rate showed performance rising from 61.98 TFLOPS to 125.29 TFLOPS. According to test results posted by user s654632396 on October 28, this is about 2.02x in a comparison using the same conditions and the same binary. The test used a 16 GiB model with an AD103 chip in a desktop PC with an AMD CPU, measured with NVIDIA driver 621.01, tool v2.1.0, and Secure Boot disabled. This test, however, measures how fast a specific Tensor instruction can be issued; it does not mean that overall application speed doubled.
Meanwhile, MingShi350's RTX 4080 16GB results, posted on October 29, use PyTorch to compare matrix operation performance before and after the unlock. The test environment was an unmodified RTX 4080 paired with a Ryzen 9 9950X3D and 64GB of DDR5-6000 memory. The OS was Windows 11 24H2, the GPU driver was 621.01, and the software was PyTorch 2.11.0+cu128 with CUDA 12.8.
For both FP16 and BF16, the measurements applied the setting that disables low-precision reduction (reduced_precision_reduction=False) and used FP32 accumulation. For each matrix size, three measurements were taken, and the best value out of 30 iterations each was adopted. The table below shows the first of the two before-and-after sets that were posted, not an average of the two.
| RTX 4080 test condition | Before unlock (TFLOPS) | After unlock (TFLOPS) |
|---|---|---|
| FP16 input, FP32 accumulation, 4096³ | 100.53 | 185.50 |
| FP16 input, FP32 accumulation, 8192³ | 104.49 | 164.31 |
| BF16 input, FP32 accumulation, 4096³ | 100.37 | 192.18 |
| BF16 input, FP32 accumulation, 8192³ | 104.39 | 172.31 |
| strict FP32 (control) | 34.47 | 34.42 |
Matrix operations with FP16 and BF16 inputs improved significantly, though the gain differs between 4096³ and 8192³. Meanwhile, the strict FP32 control showed almost no change, which indicates that the GPU's overall compute performance did not rise uniformly. The poster suggests the smaller gain at 8192³ may be due to hitting the 340W power limit, but this has not been independently verified as the cause.
RTX 4060 Ti image generation about 1.51x faster, waiting time down about 34%
Shorter processing times have also been reported in a real AI application, not just in matrix operations. In the RTX 4060 Ti 16GB results published by user fj80405 on October 28, image generation was sped up while the GPU power limit stayed at 165W. The test used an MSI RTX 4060 Ti 16GB with a Ryzen 5 5600X and an MSI MAG B550M MORTAR WIFI, running Windows 11 Pro build 26200, driver 610.88, and a self-built nv-uefi-unlocker v2.1.4.
Running the image generation model "Z-Image-Turbo" in ComfyUI to generate 1024×1024 pixel images in 8 steps, processing time per image fell from 12.1 seconds to 8.0 seconds. The GPU, driver, and power limit were left unchanged, and the model and random seed were matched for the comparison. Calculated from these figures, that equals about 1.51x the speed and about a 34% reduction in waiting time.
The speedup is 12.1 ÷ 8.0 = 1.5125, and the waiting-time reduction is (12.1 − 8.0) ÷ 12.1 × 100 ≈ 33.9%. Because speedup and time reduction use different baselines, it would be incorrect to describe the roughly 1.51x speedup as "waiting time cut by 51%." The image generation test also does not show the distribution of results over repeated measurements, or whether the result can be reproduced on multiple GPU units.
The same post also measured FP16-input, FP32-accumulation performance at 8192³. Over three sustained loads of about 4 seconds each, the median rose from 45.72 TFLOPS to 67.30 TFLOPS. The poster attributes the lower performance under multi-second sustained loads, compared with short benchmarks, to the 165W power limit and clocks dropping to 2190MHz. These results also show that the short-term Tensor instruction issue rate alone cannot predict the speedup achieved in long-running computation or in actual image generation.
Some checks of calculation accuracy have also been made. The RTX 4060 Ti poster reported that images generated with the same seed matched down to the pixel before and after the unlock. The developer's test on the RTX 4060 Laptop GPU also found no anomalies in a self-check of data integrity. These are results under specific test conditions, however, and do not guarantee correct results with every AI model or stable operation over a long period. All performance figures and test results are reports by the developer or users, and independent third-party reproduction has not been completed.
Cases where the unlock succeeds in UEFI but the effect is lost in Windows
Not every environment achieves a successful unlock. In a report posted by GWASDW123 on October 29, an RTX 3070 connected over Thunderbolt 3 was unlocked successfully in UEFI, but the effect was lost after Windows started. The test used an ASUS RTX 3070 installed in a Thunderbolt 3-compatible external GPU dock, connected to a Lenovo 83D4 with a Core Ultra 5 125H. Display output used the built-in Intel Arc, and operation was checked with Windows 11 and NVIDIA driver 621.01.
In a test using a local v0.2.0 branch, the unlock reportedly succeeded inside UEFI, and the unlocked state was maintained even after an FLR (Function Level Reset), a PCIe device-level reset. On the Windows side, however, the diagnostic result indicating the unlock state was NOT_UNLOCKED, and no improvement in compute performance could be confirmed. The same GitHub Issue also includes a separate failure log using v2.1.5, but in that case the UEFI processing itself failed, so the course of events differs from the v0.2.0 case.
The reporter states clearly that they could not identify exactly when the unlocked state was lost. A full GPU reset, USB4-related processing, and initialization by the NVIDIA driver are among the possible causes, but none has been confirmed. The explanation that the state was lost when the Thunderbolt tunnel was rebuilt also remains only a hypothesis for now. This one case cannot establish that external GPUs in general are unsupported, but it shows that a success message on the UEFI side does not necessarily mean the unlocked state will persist in Windows.
Actual verification therefore needs to be divided into three stages. First, change the protection settings in UEFI and confirm that the written values can be read back correctly. Next, check whether the unlocked state is still maintained after Windows starts. Finally, measure whether performance improves in the target application. The RTX 3070 case highlights the problem of declaring "unlock succeeded" without distinguishing these three stages.
Disabling Secure Boot and lifting power limits carry risks
Using nv-uefi-unlocker through the normal procedure requires disabling UEFI Secure Boot. The developer also explains a method of registering a self-signed certificate in the UEFI signature database, but either approach changes boot-time trust settings. According to Microsoft's technical documentation, Secure Boot verifies the signatures of bootloaders and other components loaded at startup so that only trusted code runs. Disabling it removes part of the protection against unauthorized code execution before the OS starts.
The changes made by nv-uefi-unlocker are also not permanent. The unlocked state is lost when power is fully cut, so it must be reapplied on every cold boot. If the protection setting has become write-protected again on the Windows side, the unlock cannot be redone on the spot. The developer asks that if processing halts in a STOP state, users not rerun it in the same session but fully power off and return to a normal Windows boot. Even though the design does not write permanently to the VBIOS, there is no guarantee of recovery from every malfunction or hardware damage.
Caution is also needed on power consumption and heat when combining it with other unlocking tools. The developer's test report on an Ada-generation GPU includes a case in which the power limit was lifted using a separate tool, "nvoc," and GPU chip power consumption reached about 163.7W with a hot spot temperature of 104.4°C. That result came from combining the Tensor-operation unlock with the power-limit unlock, however, and does not represent the temperature or power consumption of nv-uefi-unlocker alone. The conditions also differ from the RTX 4060 Ti test that kept its power limit at 165W, so the two should not be treated as the same.
These reports suggest that unlocking the Tensor-operation limit on GeForce GPUs may shorten processing time not only in Windows matrix operations but also in real image generation applications. The effect varies by GPU generation, connection configuration, power limit, and the workload being run, though, and a successful unlock in UEFI does not guarantee better performance on Windows. Going forward, it will be important to verify real-application processing time, calculation accuracy, and long-term stability, taking into account the impact on boot-time security protections.