eglantine-cirakg/src/video_core/gpu.cpp, branch nx2

Merge pull request #334 from snowstormxd/codex/upstream-mkw-test

2026-11-02T22:36:01+00:00

MKW performance improvements

nx2: rearm clean read areas when the GPU writes them again

2026-11-02T20:51:11+00:00

Port the coherency changes from alarok/Eglantine 77fc365f2 without its diagnostic framework or shutdown changes. Only GPU-dirty CPU reads become permanently preflushable, clean areas can be trapped on the next write, non-core readers avoid indexing core arrays, and collected CPU writes precede readback. Assisted-by: Codex (source review, selective integration and verification) (cherry picked from commit b64e211957180aa218ec6d9a3bcb020332279c3f)

nx2: map GPU memory before later command lists are read

2026-11-02T19:53:47+00:00

837133792d queues the GMMU maps on the GPU thread (GPU::RunInOrder) so the service thread never waits for the texture cache. With the GPU split (Low GPU accuracy) the GPU thread defers queued functions to its back, but its front reads the command lists: it read the lists submitted after a map through GPU addresses that weren't mapped yet. Pokopia stopped after its first frame. Add GPU::MapInOrder for the GMMU maps and the sparse tile remaps. It runs in order like RunInOrder, and with the split it runs on the front after draining the back, before the front reads further command lists. The service thread still never takes the texture cache lock, and the back is idle while the map changes the caches. Unmaps and the other queued work still run on the back. Assisted-by: Claude Opus 5.5 (bisect, fix, testing and commit message)

nx2: don't stall presents on a current-frame wait the GPU can't finish

2026-11-02T19:53:47+00:00

0f14696044 made PresentClientBuffer also wait for the current frame's fence whenever the previous frame's wasn't reached. Mario Kart World's GPU waits on semaphores its CPU releases only after the present returns, so in that state the current fence can't be reached until the present returns, and each such present stalled up to the 4 s deadline. Wait for the current frame by default, but give up after a few ms once a GPU channel was seen suspended on a semaphore acquire and wait for the previous frame instead. EDEN_NX2_FRAMES_AHEAD=1 always waits for the previous frame (with 0f14696044's current-frame wait when the GPU is behind), =0 always for the current one. The scheduler gains a lock-free flag so the present thread can see suspended channels. Assisted-by: Claude Sonnet 5.5 (implementation and commit message)

buffer_cache: no buffer downloads at every fence for Switch 2 titles

2026-10-30T00:49:47+00:00

Eden copied every GPU-written buffer range back to guest memory at the next fence. Title 1 signals a fence per compute dispatch, so that was 250-330 MB/s in 13,000-20,000 ranges a second, with the fencing thread holding the buffer cache while it wrote them. Measured: the native MME's DMA reads never touched those pages (they read query words written on the CPU side), and with reactive flushing the guest CPU read GPU-written memory at most 64 times in 200 s. Without them, for Switch 2 titles (native tiling): fences ~1.1 us instead of ~5, draw setup 6.1 us instead of 6.4-6.7, macro calls 160 ns instead of 167-170, GPU-thread lock spinning 1.8% (was 5.5%). Regions stay marked GPU written and are still flushed on demand. EDEN_NX2_BUFFER_DOWNLOADS=0/1 forces either way. Reactive flushing reads of GPU-written memory are now counted in the log.

Fix the P6 scratch save in R2UR/MATCH/HFMA2.RELU; GPU memory dump tool

2026-10-28T19:19:44+00:00

The colour cast on title 1 (magenta/cyan, then red/green, changing per course) came from the sky/atmosphere volume shader (a pixel shader drawing a 32^3 RGBA16F table slice by slice), which starts with an unguarded R2UR. R2UR, MATCH and HFMA2.RELU use P6 as scratch and saved/restored it with the uniform-guard mask, 1 << (6 - 7) for an unguarded instruction: undefined, in practice bit 31, which shifted into the opcode bits and turned the save into another instruction. They now always save and restore P6. Debugging aids used to find it: - EDEN_NX2_DUMP=::,...: flush GPU memory ranges at a present (on the GPU thread) and save them next to the frame captures; nx2work/vol3d.py untiles Switch 2 3D textures from such dumps. - GPU::RunOnGpuThread. - Logs of Switch 2 3D images and descriptors.

nx2: unmap GPU memory in submission order

2026-10-28T11:47:45+00:00

NormalUnmapGpuMemory4K and destroying GPU memory are jobs the console's graphics server completes behind the work already submitted. Run the GMMU unmaps on the GPU thread after the command lists queued before them (GPU::RunInOrder) and signal the job's event only then, instead of unmapping and signalling at once while Eden's GPU thread may still be behind. Also EDEN_NX2_FRAMES_AHEAD (experimental): wait for the previous frame's fence at present instead of this one's.

[video_core, settings] readback for nce invalidations (#4490) optimization and nuke toggles (#4502) (#4531)

2026-10-26T16:24:28+00:00

- [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions). - [x] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md). - [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability. ------------------- Follow up for #4490: Originally i was racing locks between dirty and clean invalidations, but +94% were clean so it was causing useless locks. Solutioin was to share locks between both. P.S.: THIS IS INTENDED TO FIX RANDOM CRASHES IN UE, OBJECTIVELY REPRODUCIBLE IN ENDER MAGNOLIA IN ANDROID. Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4531 Reviewed-by: CamilleLaVey Reviewed-by: Shinmegumi

[settings] add PR4490 & PR4492 toggles (#4502)

2026-10-05T20:37:30+00:00

- [X] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions). - [X] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md) - [X] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability. ------------------- TEMPORARY! Pushed under Camille's instruction. Will be dropped as soon as they get optimized. Aimed to avoid reported perf impact from PRs 4490 and 4492 on 30-sep-2026 nightly, Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4502 Reviewed-by: MaranBr Reviewed-by: CamilleLaVey

[video_core] buffer cache readback for nce invalidations (#4490)

2026-09-30T20:13:37+00:00

- [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions). - [x] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md) - [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability. ------------------- This is a follow up of 4473, a fix for the next Ender Magnolia known crash, the shackled beast's vaper crash, but specific for NCE. Imma try to be short: NCE invalidation was dooming whole guest pages when it shouldn't. If the GPU buffer cache owns some bytes on a page, invalidating first discards their ownership, and the retrying CPU can then observe stale data. On Android, this was corrupting some indirect draw packets and causing huge invalid index count reach staging memory allocation. Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4490 Reviewed-by: CamilleLaVey Reviewed-by: lizzie