eglantine-cirakg/src/video_core/macro.h, branch nx2

video_core: compile Turing MME macro code to x86-64

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

Title 1 calls macros ~1.3 million times a second; most were replayed from the macro memo, whose lookups missed the CPU caches inside the GPU thread (~8%), and the rest interpreted. macro_turing_jit.h compiles all of the uploaded macro memory with Xbyak: each instruction a block falling through to the next, branches and loops through a jump table, with the interpreter's semantics (lanes reading operands before either writes, predication as two variants, the END delay slot, loops, carry). Loop checks only where a loop can end, END checks only after an END, the instruction limit counted on indirect jumps. Emits and register reads call back into C++. It is recompiled when the macro code changes and used for 3D and compute macros on x86-64; EDEN_NX2_MME_JIT=0 goes back to the memo and the interpreter. Checked against the interpreter on 200,000 recorded calls (registers, data RAM, every method write, FIFO use): identical. In the game: macro calls 148 ns instead of 174 (two profiled runs each), no failures, 0 crashes in 3 runs. NX2_GPU_THREAD_SPLIT.md describes the next step, splitting the GPU thread.

nx2: macro memo hashes its keys as they are, rewrites re-stored calls in place

2026-10-29T04:37:06+00:00

The flat map re-hashed the already mixed u64 keys with MSVC's byte-wise FNV-1a (~1.4% of the GPU thread), and calls stored again after a data RAM guard failed appended new records, so the arena filled with stale copies and was cleared every few seconds. EDEN_NX2_MME_MEMO_STATS logs the counters: in title 1, 97.3% of calls replay, 2.1% fail a guard.

nx2: replay repeated native macro calls instead of interpreting them

2026-10-29T04:27:35+00:00

Title 1 makes ~1,000,000 native macro calls a second in 3D scenes, 7 instructions each on average, and 96% repeat an earlier call exactly. A call whose effects depend only on its start, its parameters and the data RAM words it read (no MME_READ, no memory reads, no re-read of its own data RAM writes, no code upload while it ran) is remembered with those reads as guards; a later call with the same start and parameters whose guards still hold replays its data RAM and method writes. Uploading macro code clears the memo. EDEN_NX2_MME_MEMO=0 interprets every call. Checked offline against the previous interpreter on 200,000 recorded 3D-scene calls (method writes, registers and data RAM all identical, 94% replayed, 1.9x faster); in the game the macro zone fell from ~0.26 to ~0.20 us per call.

Native MME: decode each instruction once; reuse the parameter FIFO

2026-10-29T00:43:00+00:00

The Turing macro interpreter re-extracted every field of each 96-bit instruction on every execution and copied the register file per instruction; title 1's GPU thread spent about half its busy time there. Instructions are now decoded once per PC (re-decoded when their words change) and both lanes' operands are read up front instead of copying the registers. The parameter FIFO is a member instead of a vector allocated per macro call. Rendering checked unchanged on the attract loop; the GPU thread went from ~68% to ~45-50% busy.

Switch 2: Turing macros, native compute, Ampere shader lowering, native tiling

2026-10-28T02:26:16+00:00

From changes.patch: the TU104/GA10x MME interpreter (shared macro context for the process's channels, also on the compute class), native compute with QMD 3.0 dependency scheduling, the Ampere-to-Maxwell shader lowering, native vertex stream sizes, and the console's GOB swizzle for textures, DMA copies and the host unswizzle shaders. Switch 2 channels turn all of it on at init. The lowering is widened for title 4 (all 32 of its programs lower): general TEX (any dimension/LOD/mask, operand split 1+1/2+1/2+2/4+n, any but consistent descriptor buffer), cube/array, SULD channel masks, 128-bit STG, indexed IPA, VOTE, SHFL with any immediate or predicate output, R2P/P2R byte select, uniform ULOP3/ULEA/UBREV/UFLO.SH/UISETP signed/UMOV URZ, IMNMX cbuf, IADD3 and FFMA uniform operands, FMUL /4 /8 x8, and BSSY/BSYNC/BREAK/WARPSYNC as no-ops. The capture stops at unmapped memory. EDEN_NX2_SHADER_DUMP dumps every native program; tools in C:\dev\nx2work test the lowering offline.

[common] Switch to boost::unordered_flat containers (#4326)

2026-08-31T00:58:09+00:00

Replaces all instances of ankerl's unordered map/set with boost's `unordered_flat_*` classes. This uses std::hash since boost::hash is actually a lot slower. Also adds an abstraction layer in `Common` so future changes are quicker and easier. Other implementation details: - ankerl provided hash specializations for tuple and pair, so those were ported here - std::erase_if doesn't work on boost, so just used the ADL'd erase_if This should be about equal or superior performance as unordered_dense for everything except iteration. Signed-off-by: crueter - [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. ------------------- Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4326 Reviewed-by: Lizzie and Samuel Reviewed-by: MaranBr

[video_core, hle] remove redundant parent references in system structs (#3908)

2026-06-23T04:31:25+00:00

reworked a bit to remove references of parent objects and instead pass as arguments to methods to prevent useless reloads Signed-off-by: lizzie Co-authored-by: maufeat Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3908 Reviewed-by: Maufeat Reviewed-by: crueter

[video_core/engines] Macro HLE inline (#3653)

2026-03-06T14:04:38+00:00

Should slightly boost perf on android, Desktop is mainly unaffected (for now) Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3653 Reviewed-by: CamilleLaVey Reviewed-by: DraVee Co-authored-by: lizzie Co-committed-by: lizzie

[*] change all std::unordered_map and std::unordered_set into ankerl::unordered_dense::map/set variants (#3442)

2026-02-10T02:34:07+00:00

mainly doing this to reduce memory footprint; we all know how nice ankerl::unordered_dense is in theory 4x faster - in practice these maps arent that "hot" anyways so not likely to have much perf gained i just want to reduce mem fragmentation to ease my porting process, plus it helps other platforms as well (ahem weak Mediatek devices) :) Signed-off-by: lizzie Co-authored-by: Caio Oliveira Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3442 Reviewed-by: DraVee Reviewed-by: CamilleLaVey Co-authored-by: lizzie Co-committed-by: lizzie

[common, core] remove uneeded memory indirection overhead at startup (#3306)

2026-01-16T22:39:16+00:00

for core stuff: just remove unique ptrs that dont need any pointer stability at all (afterall its an allocation within an allocation so yeah) for fibers: Main reasoning behind this is because virtualBuffer<> is stupidly fucking expensive and it also clutters my fstat view ALSO mmap is a syscall, syscalls are bad for performance or whatever ALSO std::vector<> is better suited for handling this kind of "fixed size thing where its like big but not THAT big" (512 KiB isn't going to kill your memory usage for each fiber...) for core.cpp stuff - inlines stuff into std::optional<> as opposed to std::unique_ptr<> (because yknow, we are making the Impl from an unique_ptr, allocating within an allocation is unnecessary) - reorganizes the structures a bit so padding doesnt screw us up (it's not perfect but eh saves a measly 44 bytes) - removes unused/dead code - uses std::vector<> instead of std::deque<> no perf impact expected, maybe some initialisation boost but very minimal impact nonethless lto gets rid of most calls anyways - the heavy issue is with shared_ptr and the cache coherency from the atomics... but i clumped them together because well, they kinda do not suffer from cache coherency - hopefully not a mistake this balloons the size of Impl to about 1.67 MB - which is fine because we throw it in the stack anyways REST OF INTERFACES: most of them ballooned in size as well, but overhead is ok since its an allocation within an alloc, no stack is used (when it comes to storing these i mean) Signed-off-by: lizzie lizzie@eden-emu.dev Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3306 Reviewed-by: CamilleLaVey Reviewed-by: MaranBr Co-authored-by: lizzie Co-committed-by: lizzie