github Djihads80/Eglantine build-187
Eglantine nx2 build 187 (14d4c4e)

latest releases: build-189, build-188
pre-release2 hours ago

What's new in this build

Build 187 of nx2 (14d4c4e) is build 181 plus five changes, and the headline is real this time: NVIDIA DLSS works in the Windows MSVC download. The Graphics tab has a new Use NVIDIA DLSS in place of a game's DLSS setting, which hands a game's DLSS evaluation to NVIDIA's upscaler on a GeForce RTX card instead of running Eglantine's FSR 3.1 replacement.

Also in: the -pgo downloads are trained on Eglantine's own profile instead of Eden's (the fix for "the PGO build is slower than the normal one" on Switch 2 titles), the AMD black-texture regression from the sparse-tile change is reverted, the AppImage carries its build number, and the README and PR template were cleaned up.

In short

  • NVIDIA DLSS — eglantine-windows-x86_64.zip (MSVC) only. Off by default. When on, a game's DLSS evaluation goes to NVIDIA DLSS with the same inputs (colour, depth, motion vectors, jitter); when DLSS cannot run, FSR 3.1 still takes over from the next frame.
  • Where it is not: the Windows -pgo zip is a MinGW build and does not have it (it has never been built with MinGW), and neither do the Linux or macOS downloads. In this build you cannot have both PGO and DLSS on Windows — the DLSS zip is the standard MSVC one.
  • First run: nothing of NVIDIA's is bundled. Open Graphics, tick the setting, and the panel under it reports whether the Streamline loader and DLSS were found. Download from NVIDIA fetches only the needed files out of NVIDIA's Streamline 2.14.16 release (about 1 MB for the loader, 32 MB with DLSS, out of a 276 MB zip) after showing the licence texts, checking each file's CRC and signature before saving it to the user folder's streamline folder.
  • PGO builds fixed: both -pgo builds now use this repository's eglantine.profdata instead of Eden's Switch 1 eden.profdata. On an RTX 4070 laptop, Mario Kart World's attract demo ran 17–24 fps in the old Windows PGO zip against ~47 in the standard build of the same commit; on the new profile the PGO build matches the standard one (30 vs 32 fps in the same pass).
  • AMD black textures: the sparse-tile change that backed a tiled image whole when InitSparseTiles failed is reverted. On AMD's aliased-tiles mode it created the image before the game's data was there, and Switch 2 fills sparse textures with remaps rather than writes, so nothing refreshed it — textures came out black.
  • Smaller: the AppImage now embeds build-<run>-<sha7> as its version metadata, the README has a star-history graph, and the pull request template asks for more of what maintenance needs.
  • Not here: the two fixes that only the experimental line has — Nintendo Switch Sports past 2162-0001 and random Miis with the gender and race asked for. They are in build 183, not in nx2 yet. Build 183 has the same DLSS code but not the CI change below, so its Windows zip has no DLSS either.
  • Still no Android APKs: the publishing was reverted in build 175.

NVIDIA DLSS in place of a game's DLSS (Windows, MSVC zip only)

A game that asks for DLSS gets its temporal upscale replaced by FSR 3.1 today. With Use NVIDIA DLSS in place of a game's DLSS (nvidia_dlss, off by default) ticked on a GeForce RTX card, that evaluation goes to NVIDIA DLSS through NVIDIA Streamline instead, with the game's own colour, depth, motion vectors and jitter.

Nothing of NVIDIA's is linked into Eglantine or shipped with it — only Streamline's MIT-licensed headers are compiled in, and they are downloaded at configure time through CPM from NVIDIA-RTX/Streamline v2.14.16 (hash-checked in cpmfile.json). At run time Eglantine looks for sl.interposer.dll in a streamline folder in the user folder, in EDEN_STREAMLINE_DIR, or in a streamline folder next to the executable, checks its Streamline signature, and starts Streamline with manual hooking. DLSS itself is nvngx_dlss.dll in the same folder, or the newest DLSS 310+ the NVIDIA app has downloaded — Authenticode-checked and copied in as streamline/nvidia-app/nvngx_dlss.dll.

  • Download panel: under the checkbox, the Streamline loader and DLSS are reported with their versions, next to Open Folder and a link to NVIDIA's releases. Download from NVIDIA pulls the missing files out of NVIDIA's Streamline 2.14.16 zip with HTTP range requests — about 1 MB for the loader and 32 MB with DLSS, of the 276 MB archive — after the Streamline and DLSS licence texts, and checks each file's CRC and signature before saving.
  • Preset K is used for every mode (EDEN_NX2_DLSS_PRESET overrides it): the default Performance model (M) and L draw thin dark horizontal lines in some frames at 2x resolution scale, K does not.
  • HDR input is handled with auto exposure, and the mode follows the render/output ratio.
  • Fallback: when Streamline rejects the options, gives no frame token or fails the evaluation, the output is cleared and FSR 3.1 takes over from the next frame — a black frame instead of the previous one or undefined memory.
  • Tested on one machine: Windows 11, RTX 5080, Fire Emblem: Fortune's Weave docked at 1x (720p → 1440p) and 2x (1440p → 2880p), CLI and GUI, stopping and restarting games with it on. Other GPUs and other games are untested.

The -pgo builds are trained on Eglantine's profile now

The PGO downloads used Eden's eden.profdata, which comes from Switch 1 games, and on Switch 2 titles it measured worse than no PGO at all: Mario Kart World's attract demo ran 17–24 fps in the build 96 Windows PGO zip against about 47 in the standard build of the same commit (the "regression since build 73" in #168). Both -pgo builds now download this repository's eglantine.profdata instead, and on the same RTX 4070 laptop the Windows PGO build matches the standard build (30 vs 32 fps in the same pass).

If you were avoiding the PGO builds because of that, they are worth another look — but remember the Windows -pgo zip is the MinGW build, so it is the one without DLSS.

AMD: the sparse-tile change that turned textures black is reverted

When InitSparseTiles failed — an unusual block shape, no memory for the zeroed block or the mip tail, a failed bind — the image was recreated as an ordinary backed image and created before the game's data was in it. On AMD's aliased-tiles mode that showed as black textures: the tile mappings that fill a sparse texture on Switch 2 are remaps, not writes, so nothing refreshed the image after its first, empty, upload. The earlier behaviour is back: an UnwrittenSparse image that the texture cache replaces with a backed, uploaded image once the game writes it.

Smaller changes

  • The AppImage is built with LDAI_VERSION=build-<run number>-<sha7>, embedded in its metadata, so the desktop entry inside it names the release it came from. The download file names are unchanged.
  • The README gained a star-history graph, and .github/PULL_REQUEST_TEMPLATE.md was rewritten for easier maintenance.

Coming from build 181?

You gain all of the above. Nothing from 181 is missing: the Wayland platform plugins in the Linux AppImages, the crash/game/visual/UI issue forms, the fixed tests target and the CI path filter are all still here.

Coming from build 177 or earlier?

Everything in build 181's notes is new to you as well — the Wayland-capable AppImages are the one most people will notice, since a Wayland-only desktop could not start the AppImage before.

How it works, for the technically curious

  • git diff build-181..build-187 is 28 files, +2,031/−73: 24 files of #434, cpmfile.json and src/video_core/CMakeLists.txt from #460, vk_texture_cache.cpp from the #458 revert, release-binaries.yml for the AppImage version, and README.md / .github/PULL_REQUEST_TEMPLATE.md.
  • src/video_core/CMakeLists.txt now has cmake_dependent_option(ENABLE_NVIDIA_DLSS ... ON "MSVC AND ARCHITECTURE_x86_64" OFF). With it on and no EGLANTINE_STREAMLINE_SDK, AddJsonPackage(NAME streamline DOWNLOAD_ONLY) fetches the headers; the SDK path still overrides the download. Only then is EGLANTINE_STREAMLINE defined, and configure_graphics.cpp skips the nvidia_dlss setting without it.
  • The revert restores Image::Image to calling MakeImage directly instead of the MakeHostImage helper that dropped the UnwrittenSparse flag.
  • b4c1815b0f replaces the eden.profdata download with the repository's own profile for both PGO jobs; the release footer's wording changed from Eden's profile to Eglantine's with it.

Automatic build of nx2 at 14d4c4e.

Linux

Linux packages come as an AppImage (self-contained, needs glibc 2.39 or newer: Ubuntu 24.04, Fedora 40, Debian 13, Arch) and a tar.gz (uses your system libraries, so Qt 6 and the usual libraries must be installed).

Build Type Standard PGO (Recommended) Notes
amd64 AppImage · tar.gz AppImage · tar.gz Make the AppImage executable (chmod +x) and run it
ARM (aarch64) AppImage · tar.gz AppImage · tar.gz

Windows

Windows packages are in-place zip files: extract and run eglantine.exe, or eden-cli.exe from a terminal.

Build Type Standard PGO (Recommended) Notes
amd64 / x86_64 (MSVC) MSVC zip Use if you run into graphical issues on other builds
amd64 / x86_64 (MinGW) PGO zip Built with MinGW clang; bundles its own DLLs, no Visual C++ redistributable needed

macOS

Build Type Standard PGO (Recommended) Notes
arm64 (Apple Silicon) zip macOS 15 or newer. Not notarized: right-click and choose Open the first time, or run xattr -dr com.apple.quarantine eglantine.app. eden-cli is inside the app, in Contents/MacOS

The PGO builds are the same programs compiled with profile-guided optimization (clang plus Eglantine's profile); prefer them when your CPU supports it.

Don't miss a new Eglantine release

NewReleases is sending notifications on new releases.