CheezyEmu TEST build test-8a88c39 (8a88c39)

Automatic build of test-8a88c39 at 8a88c39.

Warning

This is a test build for testers, not a release. It may have bugs the released build does not. The in-app updater does not offer it, and a test build does not update itself: download the next build by hand.

Important

Read README.txt (next to cheezyemu.exe after you unzip, or on GitHub): how to turn switches on and off, install and move shader packs, and use AMD FSR upscaling and AMD frame generation. Changes and credits: CHEEZYEMU.md.

💬 Join the CheezyEmu Discord for help, bug reports and new builds: https://discord.gg/vEK4ug6JD

What's new

• Upstream Lichii's newest GPU work is merged (zortos293/Lichii nx2 up to #1056, without its
  shader cache v2, which would not carry over saved AMD pipelines and means a 30+ minute first
  boot). The two GPU threads take turns less: macros that read memory run on the second thread,
  command lists wait only for the work the console would wait for, and read-backs no longer hold
  the GPU thread. Ocarina of Time, Hyrule Field, i5-12600K + RX 6750 XT, no upscaler: about 45 to
  49-50 FPS, and the slowest frames drop from 42-51 ms to 24-29 ms (far fewer hitches).

• White flashes and huge glowing triangles after playing a while (Ocarina of Time): a second
  cause is closed. A compute shader's writes were tracked only as far as an analysis proved it
  writes; one shader writes further, the game read stale particle data back and drew giant bright
  triangles from it, which the bloom turns into a flash. Every compute shader is now checked
  against what it really wrote, and tracked in full if it wrote further (port of Frizti/Fritchii
  v5.6's write extent check, made stricter here: these shaders write far only now and then, so a
  shader needs four clean checks before it is trusted and is checked again every 30 seconds; the
  three shaders caught so far in Kakariko Village are tracked in full from the first frame, and
  any shader your PC catches is remembered for later sessions in shader/extent_distrust.txt).
  No fps cost measured. The log says "Compute write extent too small" when it catches one.
  EDEN_NX2_EXTENT_CHECK=0 turns the check off. If you still see a flash, please send the log.

• White flashes ("flashbang") in Ocarina of Time: the game sizes its glare from occlusion
  query reports, and a report could reach it before the graphics card had finished the work it
  measures. Upstream's fix for that (#337) had been taken out of the line this fork is built on,
  for speed; it is back, with the upstream work above paying for it. Not yet confirmed over a long
  play session: please report a flash with the log.

• Frame generation: Link no longer tears while he moves. Generated frames doubled and broke
  his limbs, sword and middle (ghost hands, torn boots) because only part of him was given
  motion of his own; the rest got the scenery's. Three causes, found by saving the generated
  frames and the motion they were made from: parts bound to a single bone per vertex (sword,
  scabbard, hat) were not recognised; his largest mesh keeps its pose in another slot than the
  rest; and two of his 282 bones and, in busy scenes, any character past the 64th were left out.
  Still open: his bare forearms and thighs in a fast sideways run.

• Fewer freezes on new ground. A shader the game needs for the first time was built with the
  whole frame held whenever its draw went to a target the game never clears, which is most of
  them: 8 to 51 ms each, and now and then over a second. Draws into targets used every frame are
  now left out for the few frames the shader takes instead (as was already done for cleared
  targets). Same fresh route in Hyrule Field: worst frame 97 ms instead of 1.1 to 1.7 s, no
  frame over 100 ms instead of three. Tiny targets (brightness measurement) always wait.
  EDEN_NX2_TRANSIENT_TARGETS=0 brings the old rule back.

• AMD GPU hangs and resets on Linux, and the handheld black screen after the opening
  cutscene: the mesh shader fallback is now used by itself on every AMD GPU under Linux's RADV
  driver, and on integrated Radeons under AMD's Windows driver. Native mesh shader draws reset
  RX 6000, 7000 and 9000 cards on RADV and time out the Radeon 780M (zortos293/Lichii#871, as in
  Fritchii v5.6; a player's Xbox Ally X fix first showed it here). Desktop Radeons on Windows keep
  the native path, which runs there. The first boot with the fallback builds its own shaders.
  EDEN_NX2_FORCE_MESH_FALLBACK=0 turns it off, =1 forces it on any GPU.

• About 1 GB less RAM in Ocarina: memory the game cleared to zero is given back to the system
  sooner (zortos293/Lichii#961 with Fritchii v5.6's faster page check).

• Ocarina runs faster: zortos293/Lichii#1161 by Lucas Borges is in (the game's GPU command
  stream waits less for itself, images are reused, reports are cheaper). On the test PC
  (i5-12600K, RX 6750 XT, no upscaler) Hyrule Field went from about 51 to 59 fps standing and
  from 43 to about 50 fps running around.

• Linux, AMD (RADV): GPU reset with "Illegal opcode in command stream" when the first
  tessellated terrain was drawn. The primitive topology set at draw time did not match the
  tessellation pipeline's patch list; Windows drivers let it pass. Not yet confirmed fixed on the
  reporter's machine.

• From the sister fork: Ocarina's periodic texture stalls on 10+ GB cards (#1129), the Castle
  Town guard house freeze (#976), the Song of Time crackle (#1073).

• .nx game archives load (upstream #923, #1078, #1127); right-click a game in the list and
  pick "Convert to NX..." to make one.

• A texture made where the memory collector had dropped an older one could start without its
  data (upstream #818's last fix): candidate for shadows and textures going wrong after a while.

• CheezyEmu has its own data folder: %APPDATA%\cheezyemu on Windows, and cheezyemu
  under ~/.config, ~/.local/share and ~/.cache on Linux. Eden, Lichii and Fritchii all share
  the eden folder, so their settings overwrote each other. The first start offers to import the
  old folder: "Keep Old Data" copies it (saves, settings, keys, mods and saved shaders), "Clear Old
  Data" moves it, "Link Old Directory" keeps sharing it. Saved shaders are kept unless you tick
  "Clear Shader Cache". (GitHub issue #1)

• Frame generation works again on AMD's newer drivers (docked and handheld). When AMD's
  FSR 4 frame generation started without all the functions CheezyEmu needs, build 10 gave up and
  frame generation stayed off; now it carries on, or falls back to the FSR 3.1 version.

• FSR presets work docked too. Docked (4K output) the sizes double: Native AA 3840x2160,
  Quality 2560x1440, Balanced 2250x1266, Performance 1920x1080, Ultra Performance 1280x720. In
  build 10 a docked preset turned FSR and frame generation off.

• Frame generation's Auto setting picks FSR 3.1 on cards that can't run FSR 4's (everything
  but the RX 9000 series). AMD's runtime offered FSR 4 frame generation to other cards too, where
  it never made a frame, so players had to pick FSR 3.1 by hand.

• No more blinding white lighting in Link's house and Kokiri Forest with "Switch 2 draws with
  unbuilt pipelines" on Skip or Bounded: those modes dropped the game's brightness measurement
  while its shader built, and the exposure stayed stuck until a reset. Draws like that always
  wait now.

• No more red flickering (an upstream change build 10 had taken out is back).

• Fewer freezes and black screens after cutscenes: two fixes from Lichii build 130 (GPU
  wait handling and its 32-region limit).

• "Closing software..." no longer freezes CheezyEmu. When a game gets stuck closing,
  CheezyEmu used to kill the stuck part, which could freeze the whole window until Task Manager
  ended it. Now it restarts itself instead (or just exits when you're quitting) and says so.

• FSR 4 black screen: when FSR 4 draws black (older AMD drivers), CheezyEmu notices sooner
  and switches to FSR 3.1. Updating the AMD driver fixes the cause.

• Crash reports: a crash now writes a crash dump to crash_dumps in the data folder and a
  line in the log saying where it happened. In Ocarina the log also says why FSR or frame
  generation didn't turn on.

• AMD FSR in the status bar and the performance overlay: an FSR button shows the version
  running (FSR 4.1.2, FSR 3.1.6) or why it isn't (OOT ONLY, RES 1X, WAITING, WINDOWS ONLY), like
  the frame generation one. The overlay shows both, so they're visible in fullscreen.

• Tools > Switch 2 Switches: checkboxes for the nx2_switches.txt switches players use most
  (semaphore mirror, GPU thread split, keep ASTC, build every shader at boot...).

• FSR presets fixed and docked output: Quality, Balanced and Ultra Performance start FSR and
  frame generation now (only Performance and Native did). Docked, "Ocarina of Time docked output"
  picks 4K or 1440p (lighter), and presets render a fraction of that output, as in PC games.

• FSR camera jitter (test): Tools > Switch 2 Switches > "FSR camera jitter". FSR rebuilds fine
  detail from a camera nudged by less than a pixel every frame; without it low presets look
  blocky. Off by default while it is tested: turn it off again if the picture shakes.

• Graphics that broke after a few minutes: a shader thrown out after 9,000 unused frames could
  be rebuilt wrong when it was needed again (from Lichii, not merged there yet).

• Performance: cheaper per-draw work on the GPU thread and fewer pointless texture uploads
  (Lichii #858, #910, #921, #1079).

• New icon (vector, sharp at any size).

• More fixes from Lichii build 130.

Tip

Ocarina of Time above 60 fps: press Ctrl+U (the Toggle Framerate Limit hotkey) to unlock the frame rate, or set Frame rate limit (Switch 2) under the game's Properties > Graphics (e.g. 120; applies when the game starts) to cap it there. The FPS Unlock (built-in) add-on, on by default, keeps animations and physics at normal speed at any frame rate; leave it enabled.

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 cheezyemu.exe, or cheezyemu-cli.exe from a terminal.

Build Type	Standard	PGO (Recommended)	Notes
amd64 / x86_64	zip	PGO zip	Both built with clang-cl and ThinLTO; the PGO zip adds a profile trained on Ocarina of Time

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 cheezyemu.app. cheezyemu-cli is inside the app, in Contents/MacOS

The PGO builds are the same programs compiled with profile-guided optimization. Linux uses clang with Eglantine's profile; Windows uses clang-cl and ThinLTO with a profile trained in CheezyEmu on Ocarina of Time, so other games gain less. Prefer them when your CPU supports it.