DLSSG for SM86: enabling DLSS frame generation on RTX 20 and 30 series GPUs

What DLSSG for SM86 actually fixes

NVIDIA gates DLSS frame generation to specific GPU generations. The README describes this project as a way to enable DLSS-G on RTX 30 series (SM86) and RTX 20 series (SM75), on Windows x64 with D3D12. The audience is narrow and specific: people who own an Ampere or Turing card, play a D3D12 game that exposes a frame generation toggle in its graphics menu, and want that toggle to do something. The project does not add a new upscaler and does not touch DLSS Super Resolution. It targets the frame generation stage only, and it ships as two files, version.dll and dlssg_sm86.ini, that go into the game's render EXE directory. That packaging choice is the whole design: no installer, no service, no CUDA Toolkit, no Python. The README states plainly that neither CUDA Toolkit nor Python is required.

Proxy DLL instead of a native NGX host

Version 0.3.0 reversed a decision. The release notes say the project moved from native mode back to proxy mode, because building its own NGX host caused compatibility problems in some games that were hard to fix. The proxy approach embeds an unmodified vendor runtime library inside the proxy DLL, so the game's calls into NGX are unchanged and compatibility is better. That is the mechanism: the game loads version.dll from its own directory, the proxy forwards the expected exports, and the embedded runtime does the frame generation work. The README says the 310.9 runtime adds a 6X path, raising MaxGeneratedFrames from 3 to 5. Whether you actually get 6X depends on the game, not on this project. Games that ship a newer Streamline frame generation plugin and offer a 6X or Dynamic MFG menu entry can run 6X. Games that ship an older 4X plugin lay out their internal present queue for 4X at initialization, and the README states that forcing more frames there causes out-of-bounds access and either broken or crashed frame generation. So the ceiling is set by the game's own plugin.

Installing the proxy DLL and getting a first frame generation run

The README gives a five-step install. Fully exit the game first. Then find the directory holding the game's render EXE, which the README illustrates with the Black Myth: Wukong path. Copy both files in, backing up any existing version.dll. If the game does not load version.dll, switch to one of the other proxy names shipped in the release's alternatives\ directory, such as winmm.dll, dxgi.dll or dbghelp.dll, choosing whichever DLL the game actually loads. Then launch the game and enable DLSS frame generation in the graphics settings, picking 2X, 3X or 4X, or up to 6X on the 310.9 build when the game supports it.

...\b1\Binaries\Win64\

That is the example render EXE directory from the README. After copying, the folder should contain version.dll and dlssg_sm86.ini alongside the game executable. To upgrade, exit the game and overwrite version.dll with the newer build; the README says dlssg_sm86.ini generally needs no change. To uninstall, restore the backed-up version.dll or delete it, and remove dlssg_sm86.ini.

The factory INI exposes only two switches. Optimized set to 1 selects the optimized kernel set and the README says the output is bit-identical to the vendor path; 0 uses the unoptimized vendor values. MaxGeneratedFrames ships as 3, which corresponds to 4X, and changing it to 5 corresponds to 6X on the 310.9 build only. The README notes that the number of frames actually generated is requested by the game and clamped to the runtime's limit.

[FrameGeneration]
Optimized=1
MaxGeneratedFrames=3

Diagnostics land in the game directory under dlssg_sm86\logs\, as loader_<PID>.jsonl and backend_<PID>.jsonl. Logging defaults to Level=1, errors only, and the README says to raise it to 2 or 3 when troubleshooting. If frame generation does not engage, the first thing to check is whether backend_*.jsonl contains an install entry with route active=true. A missing entry usually means a driver or runtime mismatch; the project logs the reason and falls back to the vendor path.

VRAM cost, kernel speedups, and what the benchmark table does not say

Frame generation costs local VRAM, and the README quantifies it. The increment depends only on output resolution, not on the multiplier: 2X and 6X use the same amount. At 16:9 the figures are roughly 230 MiB at 720p, 350 MiB at 1080p, 540 MiB at 1440p and 810 MiB at 4K. Ultrawide costs more because the pixel count is higher, reaching about 1050 MiB at 5120x2160. These numbers exclude the game itself and the input textures it composites.

The performance table is measured on an RTX 3080 Ti, driver 591.86, SM86, dated 2026-09-13, and the README is explicit that it measures the GPU cost of frame generation, not an in-game FPS gain. The unit is GPU milliseconds for a whole frame group, including shared preprocessing, and the numbers are medians of medians across four rounds of 256 groups each. The optimized kernel set reduces that cost by roughly 31 percent at 720p 2X, about 23 to 24 percent at 4K 4X, and about 19 percent at 4K 6X. The gain shrinks as resolution and multiplier rise, which the README attributes to the workload becoming less startup and latency bound. The README also notes that the optimized kernel set has not changed since that measurement, and that only lifecycle and tooling changes landed afterward, which is why the numbers still apply.

The README supplies a formula for turning this into an FPS estimate. Measure frame rate with frame generation off, convert to a base frame time, add the frame group cost from the table, and multiply by the multiplier. Its worked example uses 50 FPS off and the 4K 4X row, giving about 156 FPS with the vendor kernel and about 164 FPS with the optimized one. The README labels this a rough estimate and lists the reasons it can diverge: GPU contention, synchronization, CPU cost, frame caps and refresh rate. Treat the table as a way to compare kernel configurations, not as a promise about your frame counter.

Where it breaks: 4X-only games, low base frame rates, and Vulkan

The clearest limitation is the 6X ceiling on games with older plugins. If a game ships a 4X frame generation plugin, the README says this project cannot raise it to 6X, because the plugin allocates its internal present queue for 4X at initialization. Setting MaxGeneratedFrames=5 in that situation does not help and can break frame generation entirely. The next-version notes say the project is re-evaluating forced 6X on 4X-only games and calls that approach fragile and dependent on closed-source game-side plugins.

Image quality is the second boundary. The README states that frame generation's perceived quality depends on the base frame rate, that low base frame rates can produce artifacts and edge effects, and that higher multipliers make this worse. It says some games need reduced quality settings even at 4X to raise the base frame rate enough. The README frames this as inherent to frame generation when there is not enough frame time headroom, not as a defect of this project.

Vulkan is a third boundary. The current requirements list Windows 10/11 x64 and D3D12, and the next-version plan says Vulkan support is being re-evaluated. Until that changes, a Vulkan title is the wrong target. Two smaller caveats matter as well. The README says RTX 20 series usability was verified on a 2080 Ti but that image quality and performance were not measured for that path. And the offline benchmark was run on a 3080 Ti with development validation on a 3070, so the numbers describe those cards, not the whole Ampere range.

How it differs from the official DLSS path and from driver-level frame generation mods

The obvious alternative is the official one: NVIDIA's own DLSS frame generation, enabled through the game's menu on supported hardware. The difference is eligibility, not capability. The official path does not offer frame generation on RTX 20 or 30 series cards, which is the entire reason this project exists. Going official means either a newer GPU or accepting no frame generation at all. If you already have a supported card, this project gives you nothing the driver does not already give you, and you take on a self-signed DLL in your game folder for no benefit.

The second alternative is a driver-level or injection-based frame generation layer that hooks the swapchain rather than the NGX entry points. Those operate outside the game's own frame generation plugin and do not depend on the game shipping one. This project takes the opposite route. It relies on the game's existing DLSS-G plugin and the game's own menu toggle, embedding an unmodified vendor runtime so the game's NGX calls are unchanged. The practical consequence is that games without a frame generation plugin are out of scope here, while a swapchain-level tool might still work on them. The trade is compatibility with the game's own presentation path versus reach across titles that never implemented frame generation.

Licence, signing, and the upgrade cost you are signing up for

The project source is GPLv3. The README is careful to separate that from the bundled binaries: the embedded nvngx_dlssg.dll builds, the extracted and recompiled kernel resources, and assets/kernels/sm75/ are NVIDIA and upstream third-party material and are not relicensed by the GPL. THIRD_PARTY_NOTICES.txt carries the details, and the README credits Coldwood1026 for the RTX 20 series SM75 adaptation that supplies the kernel family for the experimental SM75 route. If you plan to redistribute anything, that split is the part to read carefully. This is not legal advice, and the README does not claim to resolve the question.

The proxy DLLs, including version.dll, winmm.dll and the alternatives\ entries, are code-signed. The README states that the self-signed certificate verifies signer identity and file integrity but does not carry Windows default trust, so SmartScreen may still warn about an unknown publisher on first run. It distinguishes that reputation-based prompt from antivirus detection. The certificate is CN=DLSSG for SM86 (self-signed) with SHA-1 fingerprint 85BA66762F851E49148D706915D09026281418E6, and the README suggests checking it through file properties or signtool verify /pa.

Upgrade cost is low by design. Overwrite version.dll with the newer build and leave the INI alone in most cases. The real recurring cost is per-game: verifying that the game loads version.dll, checking whether its frame generation plugin is new enough for 6X, and confirming after each driver update that backend_<PID>.jsonl still reports an active route. The README notes the cubin path needs roughly an R580 or newer driver and that older drivers fall back to PTX with a one-time JIT on the first frame, so a driver downgrade changes startup behavior rather than breaking the install.

Editorial conclusion

Adopt it if you have an RTX 20 or 30 series card, a D3D12 game, and you are willing to drop a signed proxy DLL into the render EXE folder and keep a backup of the original version.dll. Do not adopt it for Vulkan titles, for a game whose frame generation plugin is older than 4X and where you expect 6X, or if you need a vendor-supported path with a warranty. Verify three things first: that the target game loads version.dll (otherwise pick a proxy name from alternatives\), that backend_<PID>.jsonl shows install with route active=true, and that the bundled 310.9 or 310.1 runtime matches the driver you have installed.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. sdli1995/dlssg_for_sm86 on GitHub