[robertveloso]

Stacked on #243. The first two commits are #243's (macro DMA reads on the split front without draining the back), rebased onto current nx2. This PR's own changes are the last three commits.

Changes

With the GPU thread split, every Switch 2 semaphore acquire drains the back before reading the semaphore word: ProcessSemaphoreTriggerMethod on the g_nx2_ampere path, and CanResumeAcquire for a parked channel. Most acquires are already met.

In Ocarina of Time on my machine, the front's profile showed about 3,000–5,800 acquire drains a second, taking 170–450 ms of the front's time each second. At that rate the front and back mostly take turns instead of overlapping. The worst case was Hyrule Field, at about 54 ms per frame.

#243's drain-free read of report memory moves into a function, ReadReportWordsQueued, and acquires use it first:

• How it reads the word: it reads guest memory and puts the queued writes the front knows on top (fence releases, inline uploads), after the queued compute and copy writers ran.
• Met: the acquire continues without a drain. It notes a sync point (NoteSync), because a drain would have run the work queued before the acquire. A GPU-written command list fetched after it still waits for that work (WaitForSync).
• Not met, or not readable this way: takes the drained path, as before. Not readable means not report memory, a GPU-written page, or a report or fence write still pending.
• Verify mode: EDEN_NX2_PERF_VERIFY=1 drains anyway and logs a met acquire that the drained read disagrees with.

The last commit only adds measurement:

• The profile counts the outcome of each drain-free read.
• The writer wait those reads make gets its own wait site, acquire writers.

Known gap: a queued draw that writes the semaphore word through a storage buffer isn't seen. That page is only marked GPU-written once the back runs the draw. #243's macro DMA reads have the same limit.

Testing

Machine: Ubuntu 26.04, i5-10400, RTX 3060 (NVIDIA 580.178). Game: Ocarina of Time.

• I played it on a local branch: current nx2 plus video_core: macro DMA reads on the split front without draining the back #243, Ocarina of Time: fix stutter from pipeline rebuilds and slow compute builds #408, buffer_cache: opt-in EDEN_NX2_PREFLUSH=1 for Switch 2 titles (OoT Kokiri ~26 -> ~40 fps, some flicker) #259, shader_warm: follow-ups to #579 (warm-up on the loading screen, link mode in the marker, save the driver cache after a warm-up) #741, buffer_cache: upload each byte of native uniform banks once a frame #802 and my other perf PRs from today.
• Before, in Hyrule Field: 54 ms per frame, 13 frames over 100 ms per 600. After, with this and the other perf PRs in the same build: about 38 ms per frame, 0 frames over 100 ms. I didn't record which scene the after run was in, and the other perf PRs were in the same build, so this is not a measurement of this PR alone.
• On this branch, I compiled puller.cpp, maxwell_3d.cpp and gpu_split.cpp with -fsyntax-only. I did not build or play this exact branch.
• Not done yet: an EDEN_NX2_PERF_VERIFY=1 run, and the new counters, which aren't in a played session yet. Draft until both are done.

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn