News › performance
By The Linux Camp News, October 25, 2026
RTX 3090 Ti support reached upstream main by October 25, 2026. The Linux module changes compute issue rates before Nvidia’s driver loads, but application gains depend on workload and power limits.
Zagitta’s GPU unlock Linux kernel module has gained upstream RTX 3090 Ti support: on October 25, 2026, the testing issue’s author reported that the experimental fork was no longer necessary. The project identifies itself as GPU unlock 1.0.0 and targets FP16/BF16 compute issue rates on selected Nvidia RTX 30-series cards. The documentation and reports retrieved October 25 establish that integration status, not the original release date. 3 1
The intervention happens before Nvidia’s driver takes ownership of the GPU. The module writes hardware speed selectors and performs a function-level reset, or FLR, before the unmodified driver binds. According to the project, this doubles the instruction issue rate for FP16/BF16 fused multiply-add operations that accumulate into FP32: low-precision multiplication with a higher-precision running result. That is a change to how quickly those operations can be issued, not a promise to double application throughput. Moving the intervention ahead of driver initialization also avoids manually patching each Nvidia driver release. 5 1
Chip-family targeting is not a board-level compatibility guarantee. The October 25 README lists no GA103 reports and says the RTX 3070 Ti has not been tested with this module. More importantly, an OEM RTX 3080 Ti 20 GB completes the unlock sequence but retains half-rate BF16. Operators therefore need both a matching device and a throughput check; completion of the sequence alone does not establish the intended performance change. 1 2
The headline RTX 3090 Ti result comes from experimental validation, not the packaged stock-driver configuration. In dense matrix multiplication with dimensions of 8192, FP32 accumulation and a 450 W limit, five-sample medians rose from 87.50 to 157.41 TFLOPS for BF16 and from 87.46 to 118.39 for FP16. That test used a modified Nvidia driver and custom early-boot hook. A separate user subsequently confirmed operation with the unmodified upstream package and a stock driver, but that confirmation should not be substituted for the original benchmark’s test conditions. 6 3
Power limits explain why a near-doubling per clock can produce much smaller gains per second. One user’s four-card test, with unchanged 225–250 W caps, reported clocks falling from 1.1–1.4 GHz to 0.7–0.9 GHz after unlocking. Throughput per clock nearly doubled, but net gains were only 22–35%. The operational inference is to compare before and after at the same power cap while tracking clocks, rather than treating a TFLOPS figure from another machine as an expected result. 4
Workload selection matters just as much. The README summarizes reported LLM prefill gains of 14–36%, while memory-bandwidth-limited decode and INT8 work remain roughly unchanged. A separate llama.cpp Q8_0 test found no measurable application improvement despite successful unlocking. That report covered only one short-prompt workload, three runs per configuration and one boot per configuration. It supports testing the actual inference pipeline, not a blanket conclusion that quantized inference either benefits or cannot benefit. 1 7
Deployment changes the boot path rather than an application setting. Packages place the module and firmware in the initramfs, the early-boot image, so they run before Nvidia binds. Explicit kernel-command-line opt-in is required: gpu_unlock.targets=all selects eligible unbound cards, while full PCI addresses select individual devices. This makes per-card trials possible without opting in every eligible GPU. Loading the module manually after Nvidia already owns the card does not unlock it. 5 1 3
The project’s read-only check, journalctl -k -b | grep gpu_unlock, inspects unlock messages from the running boot; it is not an application benchmark. To stop unlocking on subsequent boots, remove gpu_unlock.targets= from the kernel command line, including through the bootloader’s one-off edit screen when needed. A firmware-stop failure has a stronger recovery requirement: the module retains DMA buffers that firmware might still access, and the project instructs users to power off before retrying. 1