eglantine-cirakg/src/video_core, branch nx2

video_core: accept an empty Streamline device-extension list

2026-11-03T18:23:47+00:00

Streamline may report that DLSS needs no extra device extensions. The check required a non-empty list, so that result counted as "extensions unavailable": Streamline was stopped and FSR 3.1 used. Only require that every listed extension is supported. Found by CodeRabbit review. Assisted-by: Claude Opus 5.5 (implementation) Signed-off-by: Duck912 <350528965+Duck912@users.noreply.github.com>

video_core, yuzu: write NVIDIA DLSS file paths to logs as UTF-8

2026-11-03T18:06:59+00:00

The Streamline start-up and DLSS download code formatted paths with std::filesystem::path::string(), which on MSVC converts to the active code page and throws when a character has no mapping there, for example a user name in another script under %APPDATA%. The start-up log runs inside the renderer's constructor, which only catches vk::Exception, so such a user would crash at game start with the setting on. Use Common::FS::PathToUTF8String for every path in these logs and messages. Found by CodeRabbit review. Assisted-by: Claude Opus 5.5 (implementation) Signed-off-by: Duck912 <350528965+Duck912@users.noreply.github.com>

video_core: clear the DLSS output when Streamline writes nothing to it

2026-11-03T18:06:59+00:00

The upscaler records its work on the worker thread and reports success once it is queued. When Streamline then rejects the DLSS options, gives no frame token or fails the evaluation, nothing is written to the output image, but the caller still draws it into the game's image that frame: undefined contents after a resize, the previous frame otherwise. FSR 3.1 takes over from the next frame. Clear the output on those paths, with barriers around the clear, so that frame is black instead. Found by CodeRabbit review. Assisted-by: Claude Opus 5.5 (implementation) Signed-off-by: Duck912 <350528965+Duck912@users.noreply.github.com>

video_core: NVIDIA DLSS through NVIDIA Streamline in place of a game's DLSS

2026-11-03T17:33:16+00:00

Adds a Graphics setting, "Use NVIDIA DLSS in place of a game's DLSS" (nvidia_dlss, off by default). When it is on, in Windows builds configured with EGLANTINE_STREAMLINE_SDK, the evaluation Eglantine already replaces with FSR 3.1 goes to NVIDIA DLSS on GeForce RTX cards, with the same inputs (colour, depth, motion vectors, jitter). When DLSS can't run, FSR 3.1 runs as before. Only Streamline's MIT-licensed headers are compiled in; nothing of NVIDIA's is linked or shipped. At run time Eglantine looks for sl.interposer.dll in the user folder's "streamline" folder (or EDEN_STREAMLINE_DIR, or "streamline" next to the executable), checks its Streamline signature and starts Streamline with manual hooking. Streamline's plugins come from that folder or the NVIDIA app's downloads. DLSS itself is nvngx_dlss.dll in the same folder, else the newest DLSS 310 or later that the NVIDIA app has downloaded, checked for NVIDIA's Authenticode signature and copied as streamline/nvidia-app/nvngx_dlss.dll. Like other tools that call DLSS outside a game, it uses its own fixed project id with the custom engine type. - Preset K for all modes (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 doesn't. - HDR input with auto exposure; the mode follows the render/output ratio. - Buffer device address stays enabled when DLSS needs it, for DLSS only. - The upscaler waits for the device instead of submitting when it is destroyed: by then the game's channels are released, and a submit read the state tracker's stale flags (a crash when stopping a game). With the setting off, or in builds without the SDK path (the setting is hidden there), nothing changes. Testing: Windows 11, RTX 5080, Fire Emblem: Fortune's Weave docked at 1x (720p -> 1440p) and 2x (1440p -> 2880p), CLI runs and GUI play, stopping and restarting games with DLSS on. Not tested on other GPUs or games. Assisted-by: Claude Opus 5.5 (implementation, debugging) Signed-off-by: Duck912 <350528965+Duck912@users.noreply.github.com>

video_core: read the framebuffer before recording the upscaled-output blit

2026-11-03T17:33:16+00:00

BlitColor(VkImageView, VkImage, ...), which draws FSR 3.1's output into the game's DLSS output, captured the Framebuffer pointer and read its render pass, handle and size on the worker thread. The pointer points into the texture cache's framebuffer slots, which can be reallocated before the worker records the command, so the render pass could begin with a stale or null render pass and framebuffer. FSR 3.1 records quickly enough that this rarely shows; with a slower first evaluation (NVIDIA DLSS creating its feature) it crashed in vkCmdBeginRenderPass at the first evaluation in every run. Read the three values on the calling thread and capture those instead. Nothing else changes. Assisted-by: Claude Opus 5.5 (debugging, implementation) Signed-off-by: Duck912 <350528965+Duck912@users.noreply.github.com>

video_core: cut per-draw work on the GPU back thread in crowded scenes (#374)

2026-11-03T07:47:54+00:00

* video_core: demote the texture cache's per-draw debug logs to trace The invalid sampler and image view index messages fire for unused binding slots on every draw. Filtered LOG_DEBUG messages still cost a call and argument packing: in a Fire Emblem: Fortune's Weave city scene (about 2,100 draws per frame) they were 3.1% of the GPUBack thread's samples. LOG_TRACE compiles them out of release builds. Assisted-by: Claude Opus 5.5 (profiling, porting and drafting) Signed-off-by: Duck912 <350528965+Duck912@users.noreply.github.com> * texture_cache: read a descriptor with one page lookup DescriptorTable::Read runs for every texture and sampler of every draw, and it read each 32-byte TIC/TSC entry through the generic ReadBlockUnsafe page walk. In a Fire Emblem: Fortune's Weave city scene (about 2,100 draws per frame) that was 5.0% of the GPUBack thread's samples. An entry within one page is contiguous in host memory, so it is now a single page lookup and memcpy. Entries that cross a page and pages without host memory still take the block read, so unmapped and unbacked entries still read as zero. The same change in another Eden-based build cut these reads from 6.4% to 0.4% of its GPU thread. Assisted-by: Claude Opus 5.5 (profiling, porting and drafting) Signed-off-by: Duck912 <350528965+Duck912@users.noreply.github.com> --------- Signed-off-by: Duck912 <350528965+Duck912@users.noreply.github.com>

nx2: fewer render pass splits on tiled GPUs, log failed GPU waits (Pokopia) (#361)

2026-11-03T06:29:23+00:00

* buffer_cache: don't end the render pass after mapped buffer uploads Every upload set any_buffer_uploaded, and the next draw or dispatch then recorded a transfer-to-shader barrier outside the render pass. On Vulkan the uploads are mapped: each copy either records its own barriers (CopyBuffer with barrier set) or goes to the upload command buffer, which ends with a barrier before the frame's commands run. The extra barrier only ended the render pass. On tiled GPUs every such split writes the attachments out and reads them back. Pokopia's first gameplay scene had ~50 of these splits a frame. Without them, an M3 MacBook Air (MoltenVK, 1x docked) goes from ~35 to ~29.5 ms of GPU time a frame and from 28.5 to 32 fps. OpenGL uploads immediately and keeps the barrier. Assisted-by: Claude Opus 5.5 (profiling, implementation and commit message) * vulkan: log a failed GPU wait before it ends the process When the device is lost, vkWaitSemaphores in MasterSemaphore::Wait returns VK_ERROR_DEVICE_LOST and the exception goes uncaught on the fence thread or the GPU thread, so the process aborts without a line in the log: ReportLoss is only reached from submit and present. A Pokopia crash on macOS left the log ending a second before the abort, with no hint that the GPU was lost. Log the wait's result before rethrowing. On macOS, MoltenVK prints the Metal reason (a GPU hang or page fault) to stderr only. Assisted-by: Claude Opus 5.5 (diagnosis, implementation and commit message)

video_core: fix the -Wshadow error in the FSR 3.1 upscaler

2026-11-03T01:10:48+00:00

Fsr3Upscaler::Pass::Dispatch took a scheduler parameter that shadows Fsr3Upscaler::scheduler, which fails the Windows MinGW PGO build under -Werror=shadow.

Merge pull request #346 from Duck912/fe-fsr31

2026-11-02T23:59:00+00:00

FSR 3.1 implementation for DLSS games

Merge remote-tracking branch 'origin/nx2' into fe-fsr31

2026-11-02T23:56:59+00:00

# Conflicts: # src/video_core/renderer_vulkan/blit_image.cpp # src/video_core/renderer_vulkan/blit_image.h