GPU Unlock for Windows

Linux support is not Windows support

The main GPU Unlock project is a Linux kernel module. Its installer, initramfs integration and kernel command-line options are not Windows installation instructions. The Windows implementation discussed here belongs to impacifist/Windows-GPU-UNLOCK, an independent experimental UEFI project. It performs a pre-driver transaction and hands control to Windows through a route selected for a particular machine.

The distinction affects compatibility as much as installation. A GPU listed as supported on Linux is not automatically admitted by the Windows code. A successful card in another motherboard is not verification of yours. Our checker therefore reports Windows selections as not verified and directs you here for the conditions, rather than turning a model-name match into an installation recommendation.

Recorded hardware combinations

The compatibility guide records these exact combinations. “Record” means an upstream physical result on the stated configuration and build. It does not mean this website tested the hardware, or that the latest integration has repeated that physical run.

The B650M result is the maintainer’s original record. The other entries are contributor reports. Card identity, subsystem IDs, VBIOS/PROM state, console topology and route-specific guards add conditions beyond the abbreviated table. Verify the complete profile before building. The two RTX 3060 entries use different chips and display topologies; they are not interchangeable.

An RTX 3080 display-routing research directory exists, but the project does not list a dedicated profile for it. That research is not a supported generic RTX 3080 installer. Other models, multiple discrete GPUs and laptop or hybrid arrangements are not established by these records.

Choose the recorded route

Internal headless and headless USB are different paths. The internal records cover the B650M/3090 FE and B660M/3070 Ti or Colorful 3090 Ti profiles. The X870, B660-PLUS and H610M records use the separate USB path. They are not wired into the ordinary internal configuration scripts. A route compiling successfully for a profile does not create a hardware record for that route.

“Headless” does not simply mean a PC without a monitor. In this project, the wrapper manages the GPU’s firmware display interfaces and ownership before handing control to the unlock child. Display recovery and input behavior depend on that exact topology. The older manual AMD-display route has different requirements and should not be mixed with headless instructions.

Putting USB ahead of Windows in firmware boot priority alone does not implement the project’s direct handoff. A reset between the unlock and Windows can also change the hardware state. Follow the route documented for the exact configuration; do not combine fragments from several guides.

Prepare before changing boot settings

Begin with a complete backup and a recovery method you can use while the screen is blank. Identify your normal Windows Boot Manager entry and preserve existing Windows EFI and recovery partitions. Keep any recovery information needed for your current security configuration before evaluating an experimental boot flow.

The documented default internal example requires x64 UEFI, Secure Boot disabled, a fully decrypted Windows C: volume with BitLocker protection off, and a connected keyboard. Those are significant prerequisites, not changes performed automatically by this website or the project’s tools. Assess their security and recovery consequences before deciding whether to proceed.

That example also requires a separate GPT FAT32 EFI System Partition of at least 1 GiB. An ordinary FAT32 data partition is not equivalent. The tools do not create, resize, delete or format partitions. Partition GUIDs are machine-specific; never copy an example GUID or a private EFI binary built for another PC.

Local build requirements include the documented Python version, pinned dependencies, clang/lld-link 20.1.8 and locally obtained firmware assets. Additional host integration checks need Windows build tooling and private fixtures. A downloaded executable advertised as a universal unlock does not bypass those prerequisites or establish compatibility.

A controlled first attempt

1. Match the complete machine profile and read its source guide, including recovery, before building anything.
2. Obtain the required inputs locally and configure only your own partitions, tool paths and profile. Inspect what the selected action stages or registers.
3. Prepare a separate test entry or the documented USB route while keeping normal Windows startup available.
4. Perform the supervised test through the recorded boot-selection method. Observe both the unlock transaction and the return of the Windows display.
5. Verify device health and a relevant matched workload before considering any persistent automatic startup.

For the documented internal flow, configuration and building do not register a boot entry. Staging files is also different from registration. Enabling automatic startup is a later, explicit action after a successful supervised test; it changes boot order and the documented path disables Windows Fast Startup. This overview does not provide a universal PowerShell sequence because the necessary profile and partition values cannot be inferred from a GPU model.

Understand the failure path first

The original ASUS internal example uses the firmware’s F8 menu to select a test entry, and uses Windows Boot Manager for recovery after a full power-off. Other firmware can use another selection method. Locate the applicable recovery entry in advance rather than assuming F8 applies to every motherboard.

The source distinguishes two Esc windows. Early wrapper Esc skips release and proceeds to Windows. The later child window occurs after display release and cancels into a stop; it does not restore the display or continue to Windows. Treating those actions as equivalent can leave a user without the expected recovery path.

If Windows or the display does not return, stop the experiment and follow the exact route’s power-off and Windows-first recovery procedure. Do not remove ownership checks, alter a PROM hash or substitute another profile to force a refusal into a write attempt. A refused state can be a protective outcome, not a prompt to disable the guard.

What successful evidence establishes

The original B650M headless record reports FP16/FP32 cuBLAS throughput of 124.97 TFLOPS and BF16/FP32 of 128.93 TFLOPS, using CUDA/cuBLAS 12.6 at a 4096 × 4096 shape. It has no contemporary controlled locked baseline for that headless boot, so those numbers do not establish an unlock percentage.

Other profiles have their own protocols and limits. A same-machine before/after pair is more informative than comparing a Windows number with a Linux table from another card. Read Benchmarks for the difference between instruction rate, dense matrix throughput and a whole application.

The recorded source-only pre-release is v0.3.1, while the inspected main tree includes later profiles and hardening. Host/build validation of those changes is not a new physical boot, recovery or stability result. Sleep, hibernation, repeated automatic cold boots, games and ComfyUI benefits are not established by a short GEMM or display-recovery record.

Related guides

Use Supported GPUs for the Linux model snapshot, Linux installation for the main module’s separate workflow, and Troubleshooting to organize evidence and recovery decisions. None of these pages turns the Windows profile table into automatic hardware detection.

Sources & verification

This page summarizes the independent Windows project’s compatibility and route documentation, checked October 29, 2026. The maintainer and contributors own the reports; GPU Unlock online is not affiliated with them. Windows compatibility and route documentation on GitHub.