NVIDIA's Streamline and the business of integrating other vendors' upscalers

One integration in front of several vendors' upscalers

SL is an open sourced cross IHV solution that simplifies integration of the latest NVIDIA and other independent hardware vendors' super resolution technologies into applications and games. The claim in the README is that the framework lets developers implement one single integration and enable multiple super resolution technologies and other graphics effects supported by the hardware vendor.

That is the whole problem it addresses. Without a layer like this, an application that wants to offer DLSS, and also the upscaler from another vendor, has two SDKs, two sets of hooks into the frame pipeline, two configuration surfaces and two sets of edge cases around frame generation and latency. With a framework in the middle, the application talks to one interface and the framework talks to each vendor's plugin.

The repository is the SDK for integrating SL into an application, not the framework itself, and the high level overview lives on the NVIDIA Developer SL page.

The audience is therefore application and game developers who need to support more than one vendor's upscaling technology, and who would rather not maintain a direct integration against each one. It is not aimed at a single vendor title that ships on one kind of GPU.

The change that shaped the current codebase is stated at the top of the README. As of SL 2.0.0 it is possible to recompile all of SL from source, with the exception of the DLSS-G plugin, which is provided as prebuilt DLLs only.

Most developers will never build this

The README is unusually direct about who should build the framework and who should not. Prebuilt DLLs, signed, are provided for all plugins that have source, and all the pieces needed to develop, debug and ship an application that integrates SL and its features are in the pre-existing bin/, include/ and lib/ directories. Compiling from source is described as purely optional and likely of interest to a subset of application developers.

That is the practical route, and it is worth spelling out what it means. A studio integrating SL takes the SDK, links the DLLs, calls the interface, and ships. The plugin sources in this repository are there for the subset of developers who need to modify a plugin, debug a vendor integration, or ship a custom build, and for the people who contribute fixes upstream.

The second point in the same paragraph is a warning about what you may touch. NVIDIA does not recommend making changes to the headers in include, because those headers can affect the API itself and can make developer built components incompatible with NVIDIA supplied components. The headers are the contract between the framework and the plugins, and the plugins ship separately as binaries, so a modified header can break the pairing with a prebuilt DLL you did not rebuild.

For an adopter, the practical rule is simple. Link the SDK, do not edit include/, and if you must change a plugin, rebuild that plugin and keep the headers as shipped.

The binaries are not in the repository any more

There is a change in how the artefacts are distributed that will trip up anyone who clones the repository expecting to build. As of SL 2.7.32, binary artefacts, meaning the DLSS feature DLLs and the SL DLLs, are not in the GitHub repository. To obtain them you have to download the appropriate release zip from the GitHub releases page.

The reason is not stated in the README, and it is a reasonable inference that the artefacts are large, signed binaries that change with every release, and that keeping them out of the source tree keeps the repository clonable. The practical effect for a build pipeline is that there is now a second input to fetch, and the versions have to be kept in step, because a SL DLL from one release paired with a plugin from another is exactly the incompatibility the header warning describes.

The same applies to the DLSS-G plugin, which cannot be built from source at all. The README says it plainly, that sl.dlss_g.dll cannot be built from source and thus the prebuilt copy must be used.

So the full set of artefacts for an integration comes from two places, the source tree for the SDK, the headers and the sources, and the release zip for the signed binaries. Anyone setting up continuous integration around this needs to treat the release zip as a versioned input rather than a build output.

A build driven by premake and packman

If you do build from source, the build system is described in enough detail to be reproducible, and it is a Windows first flow.

Everything is controlled through a single platform independent build script called premake5.lua at the root of the tree, using the premake project creation toolchain. Any new project or change to an existing project must be listed in that file, and for most projects all source and header files in a project directory are added automatically. The explicit instruction is to never edit the MSVC project files or the makefiles on other platforms directly.

The configuration step is setup.bat, which must be run from a command prompt or a PowerShell window. It does two things. It uses the NVIDIA tool packman to pull all build dependencies to the local machine and cache them in a shared directory, creating links from external in the tree to that cache. And it runs premake to generate the project build files in _project\vs2019 for Windows.

The build then happens either in the IDE, by opening _project\vs2019\streamline.sln, or from the command line:

setup.bat
./build.bat
./package.bat

The script takes a configuration, debug, develop or production, with debug as the default, and an optional architecture, amd64, arm64 or arm64ec, with amd64 as the default. If you change an existing project's settings or contents, you have to run setup.bat again for the changes to take effect, and reload the solution in the IDE.

One property of this build is worth calling out, because it is unusual and useful. The minimal configuration is enough, any version of Windows 10 will do, and the specific Windows version, NVIDIA driver and Vulkan are runtime dependencies rather than compile or link time dependencies. The README calls that a beautiful thing and asks for it to be kept. It means the build runs on a stock virtual machine with zero configuration, which is exactly what a CI system needs.

Signing is the part you must not skip

The most important sentence in the building section is a security instruction, and it is set in an important callout. Only use production builds when releasing your software. Also, use either the original NVIDIA signed SL DLLs or implement your own signing system, and check for that signature in SL, otherwise SL plugins could be replaced with potentially malicious modules.

That is a specific threat model. SL loads plugins as modules, so a plugin DLL sitting in the application directory is executed with the application's privileges. An unsigned or improperly verified plugin is a code execution hole in a shipped game, and the framework is explicit that it will happily load a module it has not checked.

The rule has three parts and each is load bearing. Build the production configuration, because debug builds are not what you ship. Use the signed binaries NVIDIA provides, or bring your own signing scheme. And verify the signature at load time, because a signing system nobody checks is a signing system that does not exist.

For a studio this is a checklist item, not a preference, and it is the part of the project most likely to be quietly skipped under a release deadline. The release artefacts are distributed as signed binaries, and the DLSS-G plugin is prebuilt only because it cannot be built from source at all.

Debugging through ImGui, JSON configs and registry overrides

The debugging story has two documented paths, both in the docs/ directory. One is SL ImGui, a realtime data inspection tool, and the other is the use of JSON configuration files for plugin configuration, where the plugin configs are edited directly rather than through the application.

Logging has been configurable since SL 2.7.x, and the options are the ones you actually need when a title misbehaves on a player's machine: log level, the log file output path and name, and whether to log to a separate console window. The overrides can be set two ways, through the Windows registry or through environment variables, and environment variables take precedence, so if both are in effect the environment variable wins.

That precedence rule is the practical detail. It means a support engineer can be handed a machine with an environment variable set to raise the log level without touching the registry, and that a registry override baked into an image by a build pipeline can be overridden per machine.

Packaging is a separate step from building. Running package.bat with a configuration, with production as the default, produces the packaged SDK in the generated _sdk folder, which is the artefact a team would vendor into its own tree rather than the loose DLLs from the build directory.

For the local build outputs, the README says the built unsigned DLLs are found in _artifacts\sl.*\<Config>\, and that they can be copied into bin\x64 or packaged for use in the application itself, with the reminder that sl.dlss_g.dll must be the prebuilt copy.

A composite licence file and a steady release line

The licensing picture is more complicated than a single identifier, and the repository shows why. There is a license.txt at the root, a 3rd-party-licenses.md, a file named NVIDIA Nsight Graphics SDK License (Apache 2.0).txt, and a PDF, NVIDIA Nsight Perf SDK License (28Sept2022).pdf. The repository's own metadata records the licence as a custom one that GitHub cannot classify, which is what an automated classifier does when it meets a document with several licences and vendor specific appendices rather than a single well known licence text.

The practical advice is to read the root license.txt and the third party file rather than to rely on the badge, and to note that a project which vendors NVIDIA's own components will pull in terms that are not the open source ones. A CLA.md file is also present, which tells you that contributions are covered by a contributor licence agreement, a different mechanism from the project licence itself and one worth knowing about if you intend to contribute.

On maintenance, the record is steady rather than fast. The recent releases are SL SDK 2.14.1 on 2026-09-08, 2.12.0 on 2026-06-23 and 2.11.1 on 2026-04-21, so a couple of releases a quarter with patch releases in between. The repository is not archived and the project carries a changelog.txt at the root for the history.

The repository layout is the usual shape for a C framework of this kind, with source/ for the framework code, plugins/ for the per vendor implementations, include/ for the public headers, external/ for third party code, shaders/ for the NIS plugin's shader sources, tools/, scripts/ and docs/, plus a CMakeLists.txt alongside the premake-based build, and project.xml as the project description file.

Editorial conclusion

Adopt SL if your application needs to expose super resolution from more than one hardware vendor through a single code path, and if you can live with an abstraction layer between your game and the vendor SDKs. Do not adopt it if you only ship on one vendor's hardware, since the direct SDK would be less machinery. Verify three things first: that the features you need exist as plugins in the version you take, that the signed prebuilt binaries are the ones you ship, since the documentation warns that unsigned plugins could be replaced with malicious modules, and that your build environment can satisfy the Windows and driver requirements if you do compile from source. The newest release is v2.14.1 from 2026-09-08.

Frequently asked questions

Official sources

1. Issues
2. NVIDIA-RTX/Streamline on GitHub
3. README
4. Releases