gpu unlock on a laptop: the unlock that dies when the dGPU sleeps

What gpu unlock loses when the dGPU sleeps

The unlock is a register write. Nothing is flashed and the card keeps no change of its own, which is what makes the technique reversible — remove the kernel parameter and the next cold boot is stock again. The same property is the weakness. A register holds its value only while the card holds power.

On a desktop that is a non-issue, because the card is powered from the moment the machine turns on. The gpu-unlock laptop case is therefore a power-state problem, not a register problem.

A laptop is the opposite kind of machine. It switches the discrete GPU off whenever the workload does not need it, and the README says so without softening it: "Laptops only stay unlocked if the dedicated GPU is never fully powered off. Many laptops power it down when idle, which silently resets the unlock." [official README]

Note the adverb. Silently. Nothing fails, nothing appears in the log as an error, and the card keeps working at half rate. If your measurement the next morning looks like a stock card, that is the expected outcome rather than a bad install.

Three ways gpu unlock survives a power change

The project handles one of these cases explicitly, and the difference between them is the reason two laptops with the same GPU behave differently. Which of the three a machine falls into decides whether a gpu-unlock laptop result holds past the first afternoon.

• What happens to the speed registers in each case, as described by the project.

• Idle, GPU switched off

  What happens to the card

  The device is powered down to save battery, then brought back when something needs it.

  Unlock afterwards

  Gone. No resume event fires, so nothing replays the write.

• Suspend to RAM

  What happens to the card

  The cards are powered off, selectors included.

  Unlock afterwards

  Restored. The module re-unlocks every card it unlocked at boot, just before nvidia resumes it.

• Suspend to idle

  What happens to the card

  The card keeps power through the sleep.

  Unlock afterwards

  Still set. The module reads the card rather than writing it again.

The suspend behaviour is documented and deliberate. The module's suspend notifier runs just ahead of the one nvidia resumes its cards from, so the unlock is back in place before the driver looks at the device, at a cost of about a second of resume time. [official README] Hibernation is not covered at all.

The idle case has no equivalent. There is no sleep and no resume to hang a replay on. PR #251 is the work in progress that tries to keep the unlock across the D3cold power state. It is not merged, so today the answer is still no. [official README] A machine that suspends cleanly can still lose the unlock between two idle windows.

The boot where gpu unlock never runs

There is a second, quieter failure that looks like the first and is not. At boot the module unlocks the cards it can reach; one that is already bound to a driver or powered down is skipped, and the log says which. [official README]

On a laptop that boots with the discrete GPU off — the normal configuration on machines that run everything on integrated graphics — the unlock never happens in the first place. No amount of idle tuning fixes that, because there was nothing to lose. The tell is the boot log: no unlock line at all, rather than one followed by a later failure.

Turning the dGPU on for the session is the precondition of any gpu-unlock laptop attempt, and it is worth confirming before you change anything else.

What the gpu unlock modprobe setting changes

The README gives one gpu-unlock laptop setting for the idle case, and describes its results with unusual honesty.

Read that literally. It is a configuration change that stops the driver from powering the GPU down when idle, and on some machines that is enough to keep the card powered and the unlock intact.

On others the firmware finds another way to cut the rail, or the change is honoured and the battery cost is the new problem. There is no list of machines where it works, and I would not trust one: the project does not publish it, and a list built from forum posts ages badly.

The verification is direct rather than cosmetic. Leave the machine idle long enough for the GPU to have powered down in the past, then look at whether the card is still visible and still reporting the unlocked rate. If it survived the idle window, the setting did something on your model. If it did not, the setting is not the answer for this machine.

Which laptops are worth trying with gpu unlock

No model list follows, on purpose. The criteria are short enough to apply yourself, and they are worth more than a table that would be a promise in disguise.

The display topology is the one variable I cannot answer from the material. Nothing in the gpu unlock README or project docs describes a MUX switch or Optimus arrangement as safe or unsafe, so anyone telling you a particular hybrid setup is fine is going past what is published. What is published is the power behaviour above, and it decides more cases than the topology does.

gpu unlock in a laptop virtual machine

Passthrough adds a second layer to a machine that already has one. There are reports of a Proxmox guest failing with -22, an alignment error in the firmware security stage, in issue #184, and of instability on XCP-ng in issue #236. Neither is a laptop-specific report, and both are the kind of thing that gets much harder to diagnose once a hypervisor sits between you and the card.

The order that makes sense is bare metal first, hypervisor second. An unlock that cannot survive an idle window on the host is not going to be improved by passing the device through, and you will have doubled the number of places a failure can come from.

Why gpu unlock carries more risk on a laptop

The failure modes are the same ones a desktop meets, and they land harder here.

The -110 timeout is the one to know about. It shows up on boots that were not cold, and the card can stay unusable until the machine loses power — that is the report in issue #23, and it is why every page on this site says cold boot rather than reboot. [issue #23]

On a desktop that means one card in a slot. On a laptop it means the machine you are typing on, and a discrete GPU you cannot move to another system to test.

Thunderbolt enclosures add their own timing problem: issue #38 reports a timeout against a 1000 µs budget on an external 3090. An eGPU is the least laptop-like way to use a laptop GPU, and it still inherits the host's power management.

Is gpu unlock worth doing on a laptop

Only if the answer to the second check above is yes.

That is a judgement, and it rests on the arithmetic rather than on caution. On a machine that keeps the dGPU powered, a laptop unlock is the same technique as a desktop one with a battery attached, and the gains are the same kind: prefill, fine-tuning, image generation.

On a machine that powers the card down, you get a fast first hour and a stock card by lunch, and no setting in the README promises otherwise.

Between those two outcomes, the honest move is to measure the idle behaviour before installing anything. A day of watching whether the card survives an idle window is a cheap experiment compared with debugging a half-rate card you cannot explain.

Your next gpu unlock step

Confirm the device ID through the compatibility table before anything else, and treat the boot log as the source of truth for whether the module ever ran. If the card survives idle, the install order is on the gpu-unlock install page, with the same caveats as a desktop.

If you already have a log line that looks wrong, troubleshooting has the codes, and the -110 page is the one that matters most on a laptop.