GPU UnlockCurrent support status
The RTX 5090 is a Blackwell GB202 GPU. The main Zagitta/gpu-unlock README lists Blackwell as not supported. The independent phiraml/gpu-unlock-blackwell repository documents research and measurements, but says that a public GB20x booter payload does not exist and that its port has not started. Those statements do not describe an available installer.
The distinction is important when a search result says that a limitation was “found” on RTX 5090. Detecting different throughput between instruction modes is not the same as implementing a reliable firmware transaction, handing the card back to the driver and publishing a validated release. This page explains the evidence that exists without presenting a speculative unlock procedure.
There is no RTX 5090 unlock download or executable setup sequence here. A Linux instruction intended for an older generation should not be applied on the assumption that all RTX cards share one firmware path.
What the stock card measured
| Instruction mode | Peak TFLOPS | Ratio to FP16 / FP16 |
|---|---|---|
| FP16 input / FP16 accumulation | 334.68 | 1.000 |
| FP16 input / FP32 accumulation | 226.14 | 0.676 |
| BF16 input / FP32 accumulation | 222.29 | 0.664 |
The source’s raw record identifies a GeForce RTX 5090 with 170 SMs and compute capability 12.0, NVIDIA driver 610.88, a 575 W cap, WSL2 with Linux 6.6.87.2-microsoft-standard-WSL2, PyTorch 2.11.0+cu129 and CUDA 12.9. These describe the measured setup; they are not requirements for an unlock that has not been implemented.
The displayed peaks are rounded from the source record. All three columns describe a stock card. In particular, 334.68 is the FP16-accumulate reference, not an “after unlock” measurement for BF16. Re-labeling that reference as an unlocked result would create a comparison the research did not perform.
How to read the measurement
The research harness compares accumulation modes across five matrix shapes on the same card, boot and power cap, taking the best of three. Its reported shapes include 4096 × 4096 × 4096 and several larger rectangular combinations. The peak for a mode comes from that sweep, so the summary is not a single whole-application timing.
The FP16/FP32 ratio of roughly 0.68 and BF16/FP32 ratio of roughly 0.66 indicate a lower measured rate relative to the FP16/FP16 reference in this harness. The repository interprets the evidence as a speed-select restriction. It does not follow that every kernel loses the same fraction, or that a future implementation would produce a reciprocal application speedup.
The environment is WSL2. That fact does not establish a native Windows UEFI unlock, nor a validated bare-metal Linux firmware transaction. Separate the measurement host from the implementation stage being researched. A benchmark can expose an interesting difference without providing the privileged pre-driver path needed to change it.
What is missing for a public port
The research identifies the missing public Blackwell debug booter as the first major blocker. Earlier-generation work used a debug image to examine the relevant instruction addresses and construct a payload for the signed production booter. According to this repository, an equivalent public GB20x debug image is not available.
A usable port needs more than a target register address. The source describes several linked requirements:
- A suitable firmware image and enough analysis to understand the exact Blackwell booter path.
- A payload chain with instruction addresses checked for that particular image.
- Correct permission and speed-selector handling, with readbacks that establish what changed.
- A module that claims an eligible card before the driver, performs the transaction and resets it safely.
- Driver handoff, output validation and matched measurements on the actual hardware.
The repository’s source inspection reports explicit booter-dispatch variants for older chips and a shared fallback for other chips. It describes the Blackwell image as remaining inside a closed NVIDIA object rather than appearing in the same public form as earlier examples. That is the project’s documented analysis, not a release announcement or a promise that obtaining one artifact would complete every remaining step.
Why an Ada payload is not a Blackwell solution
Some surrounding infrastructure can be reused. The research names payload-container tooling, firmware extraction, packaging and parts of the loader architecture as useful starting points. Reusing an archive format or an initramfs workflow does not make the actual firmware instruction chain portable.
The chain depends on specific booter instruction addresses and chip behavior. Copying an Ada address, changing a device-ID list or renaming a package cannot substitute for deriving and validating the Blackwell path. A project can compile and still have no hardware-proven transaction for this generation.
The RTX 4090 evidence illustrates the difference: that Ada work records permission and selector readbacks, reset behavior, driver initialization and numerical checks. The RTX 5090 research currently provides stock measurements and a port plan, not an equivalent completed sequence. Results from older generations therefore remain context rather than support evidence for GB202.
What the numbers cannot predict
The stock ratios do not predict gaming FPS, image-generation latency or LLM tokens per second. Those metrics include other execution paths and bottlenecks. An application may be limited by memory traffic, data preparation, synchronization, a power cap or a kernel that does not use the measured mode heavily.
Even on cards with a working experimental unlock, published library results can improve less than instruction issue rate, and some workloads remain unchanged. The benchmark guide separates those cases. A hypothetical Blackwell gain should not be inserted into a table beside actual stock/unlocked measurements from another architecture.
Do not treat the source’s 575 W test cap as an invitation to increase your power limit. It is a condition attached to the measurement, and changing it would change the comparison. The data does not establish cooling requirements, maximum safe power, lifetime reliability or the thermal behavior of a future implementation.
What could change support
A future status change would need public, inspectable implementation evidence for the actual Blackwell target. Useful milestones would include a working payload, a defined device-admission policy, successful pre-driver execution, controlled driver handoff and reproducible checks. A source commit that only adds packaging or a device name would not establish all of those outcomes.
Performance claims would then need a matched stock/unlocked comparison with the exact card, software revision, driver, precision, shape and power policy identified. Application claims would need application measurements, not just a selector readback or a stock issue-rate ratio.
This is a description of the evidence needed to assess a future claim, not a statement that the work is scheduled. The inspected research says the port has not started. No completion date is supplied here, and the main project’s unsupported status should remain the basis for installation decisions until verified evidence changes it.
Practical next steps for an owner
Use Supported GPUs to distinguish the Blackwell status from older RTX generations. For performance planning, measure the applications you already run under a stable, supported software setup. Keep prompt processing, token generation and other workloads separate rather than attaching one overall “GPU Unlock gain” to the card.
If you encounter an advertised universal RTX 5090 unlock executable, the research summarized here is not evidence that it is legitimate. Review the claimed implementation and its provenance before running third-party code. This website does not distribute such a tool or recommend changing firmware and boot settings to test an unsupported path.
For an existing boot problem caused by an older configuration, use recovery guidance. Restoring a working configuration is separate from attempting a Blackwell unlock. The priority is normal operation, not forcing an unsupported device through another generation’s checks.
Sources & verification
Checked October 29, 2026. The main project provides the unsupported category. The independent Blackwell repository supplies the stock measurements, raw record and documented port blockers. Neither source makes this website an official project or supplies a public Blackwell unlock implementation.