gpu unlock RTX 3050: GA107 is the card the table forgot

The gpu unlock README lists the name, not the ID

Start with the two documents that disagree.

The supported-GPU table puts RTX 3050 in the Ampere row, alongside the 3060 through 3090 Ti, and calls that row stable with a hundred-plus user reports behind it. [official README]

cards[] in recipes.c is the thing the module actually reads. It holds 87 device IDs: 51 Ampere, 17 Ada, 19 Turing. The 51 Ampere entries cover GA102, GA103, GA104 and GA106 boards, and the list stops there. There is no GA107 entry, and GA107 is the die behind the 3050 and the 3050 Ti mobile. [official README]

• Same repository, two different claims. The second one is the one the module obeys.

• README, Supported GPUs

  What it says

  RTX 3050 listed under Ampere, stable.

  For your board

  Suggests the whole model name is covered.

• cards[] in recipes.c

  What it says

  GA102/103/104/106 IDs only, no GA107.

  For your board

  A GA107 board is not a target at all.

• PR #231, PR #245

  What it says

  Patches adding GA107 and the 3050 8 GB, both open.

  For your board

  Work in progress, not shipped code.

Both statements can only hold at once if the 3050 name sits on more than one die, with some boards landing in the table and others outside it. That is an inference from the two sources rather than a die list the project publishes. It is also the only reading that keeps the README and the whitelist from contradicting each other.

Either way, the operational answer does not depend on the inference: the whitelist is keyed by device ID, and the only way to know which side of it you are on is to read the ID off the card.

Three moves to check gpu unlock support on your board

The device ID page walks through the same steps with the exact strings, and the compatibility table is where the answer lives. Neither takes longer than a minute, and both are worth doing before you build anything.

One warning that belongs here rather than on the failure pages: being in the table is not a promise that the unlock succeeds. Some GA106 boards fail with -22, an alignment error in the firmware security stage, reported from a Proxmox guest in issue #184. [issue #184] A listed card can still hit a payload that does not fit its board.

The community gpu unlock patch and its numbers

There is a working patch. That sentence needs three qualifiers, and each of them matters before you treat it as a gpu-unlock RTX 3050 answer.

The numbers are in line with what the unlock does to Ampere parts elsewhere, which is why they read as plausible rather than surprising. The qualifiers are the part that decides whether you should act on them.

• One report. A single user's run, on one board, with the same power-limit caveats as every other figure on this site.
• A patch, not a release. PR #231 and PR #245 add GA107 and the 3050 8 GB to the whitelist. Both are open, which means the code exists in a pull request and not in the cards[] the module reads. [official README]
• Tied to the recipe. A patch that adds an ID only works while the payload and the address map stay where the patch expects them.

Why patching gpu unlock is a different decision

Installing a package is reversible in an afternoon. Patching the whitelist is a small fork you maintain, and the gpu-unlock RTX 3050 decision is that fork rather than the install.

The mechanical reason is the one people miss. gpu_unlock.targets=all does not mean "unlock everything". It means every card the module has a recipe for. An entry that is not a supported card is logged and ignored. [official README] So a GA107 board is not a target, whatever the kernel command line says. Adding the ID is not a shortcut around that system; it is a change to the system.

Two consequences follow, and both are judgement rather than fact. First, a patched build should be treated as a build you own: keep the diff small, keep it somewhere you can find it, and expect to redo it.

Second, a machine that other people depend on is a bad place for a maintained fork — the failure mode is a kernel update that quietly drops back to a locked card, which reads like a hardware fault at the worst possible time.

When gpu unlock adds GA107 to the whitelist

Nobody has published a timetable, and the project's FAQ does not discuss GA107 at all. What you can do is check the source of truth directly, which takes about as long as reading a forum thread and is a great deal more reliable than any gpu unlock summary someone posts.

Open PR #231 and PR #245. If either shows as merged, the next step is to look for the device ID in cards[] rather than to trust a changelog summary. If both are still open, nothing has shipped, whatever a search result claims.

That is the whole method: merged patch, then ID in the table, then a boot log with gpu_unlock: unlocked in it. A page that skips any of those three steps is describing intent.

The 3050 Ti mobile adds another gpu unlock variable

The 3050 Ti mobile is the same die and a worse position. Whatever the whitelist decides about GA107, whether a gpu-unlock RTX 3050 report applies to the mobile part depends on power management the laptop adds on top: the discrete GPU can be switched off while idle, and a card that is powered down at boot is skipped. That is a separate failure mode from a missing whitelist entry, and it needs its own page, which is the laptop one.

If you are weighing whether the 3050 is worth the effort at all, the honest framing is that it sits at the low end of the tensor-throughput curve even when unlocked. A 3060 with a listed ID gets the same mechanism with none of the patch maintenance, and it is the comparison worth making before you spend an evening on a fork.

Your next gpu unlock step

Read your device ID first. If it is in the compatibility table, install normally and treat the -22 case above as the one thing to watch; if it is not, you are deciding whether to maintain a patch, and that decision is yours rather than the module's.

Either way, the install order is the same, and it is on the gpu-unlock install page. If you have already tried and have a log line, troubleshooting reads the codes one at a time.