v1.2 — the kernels that make 4x fluid

Drop version.dll in the game folder. Nothing else — no text files, no
swapped DLLs, no settings to change.

What changed

The Blackwell frame-generation kernels now ship on by default, and they are
what makes 3x/4x actually look like 3x/4x.

They were in previous releases, but behind an opt-in file almost nobody
created, and described in the source as "a speed change, not an image change".
That was never verified and it is wrong. Avatar: Frontiers of Pandora at 4x
judders during camera movement without them and is fluid with them, everything
else held identical — same build, same snippet, same settings. The kernel that
matters is the motion-vector estimate, which fits the symptom exactly: the
scene looks fine standing still and breaks up when the camera moves.

If you tried 3x/4x before and it felt no smoother than 2x, this is the release
to retry.

Coverage. The kernels are rebuilt per DLSS-G snippet build, and the header
now carries several at once, selected by fingerprint at load time. Fourteen
snippets spanning the whole multi-frame era (310.1 through 310.9) turn out to
use only three kernel layouts; all three ship, and all three were verified in
a real game — Avatar, Cyberpunk 2077 and GTA V Enhanced.

Older Streamline. Games on Streamline 2.7 to 2.10 — Avatar among them —
express two of the patches differently and were silently getting neither. Both
now have a form for that family, verified offline against every build to leave
2.11+ untouched.

The log tells you. CUBINS NOT APPLIED means 4x will judder, not that a
speed-up was missed. If you see it, the snippet on your machine is newer than
anything here; open an issue with mfg-unlock.log and it takes one command to
cover it.

Confirmed working

DOOM: The Dark Ages, GTA V Enhanced, Cyberpunk 2077, Avatar: Frontiers of
Pandora. RTX 40-series.

v1.1 — patch the Streamline plugin that actually loads

Adds a third confirmed game, and fixes the reason it did not work there.

Cyberpunk 2077 now works alongside DOOM The Dark Ages (Vulkan) and GTA V Enhanced (D3D12).

	DOOM	GTA V	Cyberpunk
API	Vulkan	D3D12	D3D12
Streamline	2.12.129	2.13.0	OTA 134273
pacer / metering	1 / 1	1 / 1	1 / 1

What was wrong

Cyberpunk looked wrong at 3x and 4x, and mfg-unlock.log said CPU pacer enabled, sites: 0. That was not a signature that had aged out — it was the wrong file.

Streamline prefers a newer copy of its own plugins from NVIDIA's OTA cache, named by id rather than by plugin:

A duplicate was found, but a newer plugin version was available
Found plugin: ...\NGX\models\sl_dlss_g_0\versions\134273\files\190_E658703.dll

That copy is 614 KB and runs. The sl.dlss_g.dll in the game's own folder is 461 KB and does not. Matching the base name patched the image that never executes, and reported zero sites on a game running the unpatched one — at the 15% stacked frames measured for the gate alone.

The proxy now matches the path, the way the NGX snippet always has. Both layouts are caught, and reaching an image twice is harmless: every patch looks for a pattern it has already rewritten, finds nothing, and reports zero.

Read mfg-unlock.log. A patch reporting sites: 0 matched nothing and did nothing — that line is the whole point of it existing.

Verified both ways

Cyberpunk reports pacer 1, metering 1, gates 3 against the cache copy. GTA V, which loads no cache copy, is byte-for-byte unchanged in behaviour: one module, pacer 1, metering 1, cubins 3, gates 2.

Still true

The flag files are opt-in and none of this applies without them:

type nul > mfg-unpin.txt
type nul > mfg-nometer.txt
type nul > mfg-cubins.txt

Anti-cheat warning and single-machine scope unchanged — see the README.

mfg-unlock v1.0

DLSS Multi Frame Generation at 3x and 4x on Ada, with the frame pacing that makes
the extra frames worth having.

Confirmed on an RTX 4070 Ti in two games, one Vulkan and one D3D12, with the same
binary: DOOM The Dark Ages (Streamline 2.12.129) and GTA V Enhanced
(Streamline 2.13.0). The snippet's own diagnostic overlay reports 4x, so the
unlock is confirmed by NVIDIA's code rather than by inference.

Read this first

Anti-cheat. This injects a DLL into the game process. GTA V ships BattlEye,
other titles ship EAC or their own. Using it in a game with anti-cheat active —
GTA Online especially — can get an account banned. Single-player only.

Tested on one machine. One RTX 4070 Ti, driver 616.56, two games, one person.
Other Ada cards should work — the architecture gate and every signature are the
same across the family — but that has not been verified.

Nothing is written to disk. Every patch is applied to the mapped image in
memory. Delete version.dll and the install is exactly as it was.

Install

1. Copy version.dll next to the game's executable. The game must import
   version.dll; DOOM The Dark Ages and GTA V Enhanced both do.
2. Create empty files in that folder for what you want:
   • mfg-unpin.txt — the pacing fix. This is the one that stops 4x looking stuttery.
   • mfg-nometer.txt — keeps pacing on the CPU pacer
   • mfg-cubins.txt — three frame-generation kernels rebuilt for Ada
   • mfg-indicator.txt — NVIDIA's own on-screen overlay, for confirming the multiplier
3. Turn frame generation on in the game and pick 3x or 4x.

Check mfg-unlock.log next to the dll. Anything reporting sites: 0 matched
nothing and did nothing.

Start with mfg-unpin.txt alone and add the rest one at a time.

Why the unlock alone is not enough

With only the architecture gate removed, 15% of generated frames arrive stacked
on another, and entering a game already set to 4x looks wrong until you toggle
the multiplier.

	base fps	on time	stacked
gate only	48.7	72.5%	15.4%
+ pacer	41.3	88.8%	0.4%
+ pacer + metering off	40.6	94.3%	0.1%

The cause is one transition: a pacing flag flips about three quarters of a second
after frame generation starts, and the flip costs a queue flush and a command
context switch mid-gameplay. That is why changing the multiplier and changing it
back appears to fix it. The patch removes the transition.

Rebuilt kernels

The snippet ships PTX for compute_120 and compute_89 per framework
kernel, and they are not the same source — Ada's does its boolean work through a
couple of hundred 16-bit predicates Blackwell's does without. All 31 assemble for
sm_89 unchanged, so none of it is Blackwell-only. Three fit the original's slot
and are swapped in memory: inpaint −28%, inpaint decision −23%, mvec estimate −7%.
Same algorithm, so this is speed and not image.

Those are built from the snippet on your own machine — nothing NVIDIA-derived is
distributed here. See tools/rebuild_cubins.py.

FINDINGS.md has the full teardown, including the dead ends.