[mkooner]

Executive summary: six opt-in changes that take work off the split's two GPU threads, plus the profiling that found and measured them. Each is behind its own nx2_switches.txt switch, off by default: with no switch set, nothing changes. Measured with The Legend of Zelda: Ocarina of Time (0400486024DEC000) on a Ryzen 5 5500 + RX 6900 XT (SteamOS, RADV), from EDEN_NX2_GPU_PROFILE=2 zone times in heavy gameplay:

What	Before	With the switches
Front thread waiting on MME DMA reads (EDEN_NX2_BACK_MACROS)	218 ms/s	0 ms/s
Back thread texture upload time (EDEN_NX2_TEXTURE_FILL)	31–52 ms/s	5–32 ms/s
GPU submissions (EDEN_NX2_SKIP_EMPTY_SUBMITS)	~6,300/s	~3,400/s
Back thread query report time (EDEN_NX2_QUERY_BATCH)	32–36 ms/s	21–23 ms/s
Back thread time per draw (all together)	~11.0 µs	~10.7 µs

Additional work still required to increase frametimes on GPU thread for this to matter. The freed back-thread time became idle time: in Ocarina each frame is a chain of front → back → GPU → front round trips (GPU-written command lists, semaphores the GPU releases), and the chain's waits, not either thread's CPU time, set the frame rate there. The new profiling lines show the RX 6900 XT 43–61% busy and the Vulkan worker ~45%. The changes are offered as opt-in building blocks: on games or CPUs where the back thread is the limit, the lighter back should count directly.

Independent of #22 (Linux / RADV): it applies to oot-gather-fix on its own, and on top of #22 without conflicts.

Changes

Switch	Commit	What it does
EDEN_NX2_BACK_MACROS=1	2f82fd2d57	Port of zortos293#805 a442c38fe6, adapted to Fritchii's write tracker and front state. Macros that read memory (Ocarina's render enable macro at 0x142, ~31,000 calls/s) run on the back, so the front no longer waits for the back before each MME DMA read. A static pass (TuringMacroInterpreter::AnalyzeEffects) decides which macros qualify; a macro that writes outside its predicted registers goes back to the front for good (logged). Fritchii-specific: the DrainSite list keeps Fritchii's sites, FrontVerify takes the shadow entries from the sink-aware expected_shadow, and load_mme.instruction_ptr is never back-writable (the front's macro uploads read it). Upstream's default was on; here it is off.
EDEN_NX2_TEXTURE_FILL=1	ce7a1ea41b	Texture uploads fill their staging memory on a TexFill thread (the unswizzle, or the guest-byte copy an ASTC compute decode reads). The back records the copies or the decode in order (UnswizzleImageCopies gives the same copy list without reading or writing), and SubmitExecution's submit waits for the fills on the Vulkan worker, never on the back. Only for images whose guest bytes are one host run; converted, linear, sparse and trimmed-level images keep the old path.
EDEN_NX2_SKIP_EMPTY_SUBMITS=1	40355a3f2a	SignalFence calls FlushCommands right after InnerFence::Queue submitted, and its early-out almost never held (FlushWork sets pending_native_work before every draw), so each fence that waits on GPU work submitted twice, the second time empty, and the back re-sent all state after it. The scheduler now notes whether anything was recorded since the last submission.
EDEN_NX2_DIRTY_FAST=1	40355a3f2a	GPUDirtyMemoryManager::Gather returns without its two locks when nothing was collected (every fence gathers each guest core's manager, ~16,000 fences/s). Exact: Collect only adds to back_buffer while current holds a valid page and leaves one there.
EDEN_NX2_QUERY_BATCH=1	630d001d52, 414a877fe8	Query report completions and counter resets (~65,000/s each) are records in one sync operation per batch instead of a std::function, a shared Nx2AsyncReport, a lock and a work epoch bump each. Any other sync operation or fence from the back closes the batch first, so the order of all queued work is unchanged; reports are issued and settled as before, and a dropped batch settles what it didn't run. The report body moved unchanged into RunReport. The OpenGL query cache has no batch (414a877fe8).
EDEN_NX2_FAST_DRAW_BEGIN=1	630d001d52	An instance loop's draw.begin (~485,000/s) does what CallMethodFast does for it (shadow RAM, dirty registers, DrawBegin) without CallMethod's layers, only where CallMethod would reach CallMethodFast and the method sink is empty.

Always on in 630d001d52: fence operation lists are vectors with a reserve of 64 (as in zortos293#858): libstdc++'s deque cost each fence two allocations.

Profiling (with EDEN_NX2_GPU_PROFILE):

• aca5d1f2b1: the 10 longest single calls per zone, and frame-time p50/p95/p99 in the host pacer report. Also docs/fritchii-linux/gpu-thread-audit.md, a source map of both GPU threads.
• 74d1a39db5: the v5 RX 6900 XT profile and the measured ranking, added to the audit.
• 3d9d83bc5f, every 10 s: the Vulkan worker's busy and vkQueueSubmit time, and on Linux the amdgpu gpu_busy_percent.
• 3d9d83bc5f, every 5 s: how long channel suspensions take, split into the time until the GPU write and from the write to the resume. Timed only while the profile is on.

Defaults: c830a0239b lists every new switch in dist/nx2_switches.txt, commented out.

Testing

• Builds: Linux, clang 23 + lld (ThinLTO, PGO), Vulkan and OpenGL renderers. Also GCC 16 with the unit tests, built together with Pr/linux amd #22: 889 of 895 test cases pass. This PR adds 4 (turing_macro_effects, with the video_core: decouple the split GPU threads — Ocarina of Time holds 60 fps on AMD, plus fixes for three older races zortos293/Lichii#805 port), and they pass. The 6 failures also fail on upstream oot-gather-fix without either PR (see Pr/linux amd #22).
• Played: Ocarina of Time on SteamOS with an RX 6900 XT, with every switch above on together, over several sessions:
  • no visual errors, freezes or crashes;
  • video_core: decouple the split GPU threads — Ocarina of Time holds 60 fps on AMD, plus fixes for three older races zortos293/Lichii#805's escape check never fired (no wrote outside lines).
  • The numbers in the summary come from EDEN_NX2_GPU_PROFILE=2 runs, before and after, in the same areas.
• Not checked: Windows, and games other than Ocarina of Time.

🤖 Generated with Claude Code

[DragonJok]

[VBug] Distant terrain/contour rendering artifacts (purple zigzag lines) on AMD RX 7800 XT (Fritchii v5.3)


I am experiencing severe graphical artifacts when running the emulator. Specifically, distant terrain contours and the horizon line are rendered with bright purple/magenta zigzag lines and glowing distortions (visible in the attached screenshots). The issue is most noticeable in open areas and when looking towards the horizon.

System Specs:

OS: Windows 11 Pro (x64)

CPU: AMD Ryzen 5 7500F

GPU: AMD Radeon RX 7800 XT

Emulator/Port Version: Fritchii v5.3 (Clang 22.1.8)

Game: The Legend of Zelda: Ocarina of Time