Eglantine smileytatsu/dev-rebased build 6 (9e8da0e)

Automatic build of smileytatsu/dev-rebased at 9e8da0e.

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

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

What's in this build

Three changes on top of nx2 (68a945d): one fixes shader stutter in Switch 2 titles, one trims CPU work on every draw call, and one avoids a crash on GPUs without mesh shader support.

1. Switch 2 titles: cached shaders stay built (vk_pipeline_cache)

The problem. Eglantine only built the pipelines the last two sessions used when a game booted, and it destroyed any pipeline left unused for about 5 minutes of play (9000 frames). When the game needed one of those again, the shader was translated and compiled again on the GPU thread in the middle of the game. That is the stutter and the skipped draws you could see.

The change. For Switch 2 programs only:

• Every pipeline in the disk cache is built at boot.
• Pipelines are no longer evicted during play.

Switch 1 games take the same code path as before.

What you should notice

• Fewer shaders built mid-game and fewer skipped draws. In my test of one Switch 2 title (RTX 5060 Ti, Ryzen 7 5700X, warm driver cache):
  • Runtime pipeline builds: 756 in build 131's first ~6 minutes, 51 in this build's ~4.6 minute run.
  • Time spent on the GPU thread building them: 2.2 s, down to 0.11 s.
  • Different runs and different caches, so read these as a trend, not a benchmark.
• The first load takes a little longer because more is built up front. About 2.7 s for ~4,600 pipelines on that machine. A cold driver cache (after a driver update) takes longer.
• Brand-new shaders the game has never used before are still built the first time they appear.

Memory. Peak system RAM while emulating was the same as build 131 on that title (about 26 GB total used, 25.9 and 26.0 GB against 26.0 GB). There is no cap on how many pipelines stay built, so a cache that keeps growing across many builds keeps all of them. On a PC with 16 GB of RAM or less, watch memory use.

EDEN_NX2_PRELOAD_ALL_PIPELINES=1 still builds everything at boot for any game, as before.

2. Texture cache: IDs kept next to the descriptors (texture_cache)

The problem. For every draw and every texture or sampler bound, the texture cache looked the ID up in a hash map.

The change. The ID is now stored next to its descriptor, so a lookup is an array read. It uses the same validity rule as before, and it removes a map lookup that was not checked for a missing entry. It also returns early from a debug trace when tracing is off.

What you should notice

• A small drop in CPU time per draw on the GPU thread. I estimate 2 to 4% of that thread's time but did not measure it against a baseline.
• About 2 MB more RAM per descriptor table.
• This affects every game, not just Switch 2.

3. No task/mesh pipelines without VK_EXT_mesh_shader (vk_pipeline_cache)

The rasterizer already skipped task/mesh draws on devices without the extension, but only after the pipeline had been translated and handed to the driver. On such devices (RADV on Vega) the pipeline build workers crashed. No pipeline is returned now, so the draw is skipped as before. I have not tested this on that hardware.

Testing

Mario Kart World (Switch 2), Vulkan backend, on these devices:

Device	OS	Result
Ryzen 7 5700X, 32 GB RAM, GeForce RTX 5060 Ti 16 GB (driver 610.88)	Windows 11 25H2	29-minute runs against build-131, repeated start and stop of the game. Numbers above.
Core i5-9400F, 32 GB RAM, Radeon RX 6600 XT 8 GB (AMD driver 2.0.353)	Windows 11 26H2	One run hit an out-of-VRAM crash after about 6 minutes (VK_ERROR_OUT_OF_DEVICE_MEMORY). Build-135, without these changes, ran 3 laps without a crash. Treated as a one-off.
Ryzen 5 5600GT with Radeon Vega graphics (Renoir)	Linux (Bazzite), Mesa RADV 26.2.4, 4 GiB of video memory	The device where the task/mesh pipeline crash (change 3) was reported.

The measurements and crash reports above were taken on build 3 (the same three changes on nx2 6221409). This build is rebased on nx2 68a945d and was not re-measured.

Not tested: Switch 1 games, Intel GPUs, macOS.