eglantine-cirakg/src/core/core_timing.cpp, branch nx2

nx2: run the guest counter at 31.25 MHz for Switch 2 titles

2026-10-30T06:31:58+00:00

The Switch 2 counter runs at 31.25 MHz and its SDK converts ticks with that constant: Mario Kart World's sdk builds 31,250,000 in nn::os::GetSystemTickFrequency, TickManager::ConvertToTimeSpan and TickManager::ConvertToTick (19.2 MHz appears nowhere). Eglantine counted at the Switch 1 rate for every title, so every tick-based time in a Switch 2 game was off by 1.63x: elapsed times read short, and a deadline of one 60 Hz frame converted to ticks waited ~27 ms. The wall clock now has a guest counter frequency, set at boot: 31.25 MHz for Switch 2 programs, 19.2 MHz otherwise, EDEN_NX2_CNTFRQ= to force one. CNTPCT reads, CNTFRQ_EL0, svcGetSystemTick, thread tick counts and the time services' tick conversions follow it, and the CNTPCT spin detection keeps its ~1.7 us threshold. Mario Kart World, title screen and attract demo, 180 s, same build: frame times unchanged (17-19 ms once warm), process CPU time 848 s instead of 930 s.

core_timing: request the timer thread's stop before waking it

2026-10-30T04:54:36+00:00

CoreTiming::Reset set pause_event and event, and only then requested the stop. The woken timer thread could take the wake-up, still see no stop request, and go back to waiting on pause_event for good; the join that follows then hung the frontend while booting a game ("Not Responding", main thread in CoreTiming::Reset -> std::thread::join). Request the stop first, so the thread sees it whenever it wakes.

[core, gpu, threads] Multithreading refactor (#4254)

2026-08-08T02:39:47+00:00

This insufferable work tries to cover some holes on previous threading implementation from yuzu's team, starting with Windows and Linux reordering of priorities (NICE), reworks previous Android's threading and cpu affinity with adpf, adjust emulated clocks/gpu for better "accuracy" with their work, bumps android minSDK for all flavors, legacy will now work with AP 29 to cover A10 - A12, standard will reach A13 as base and finally the optimized build will come with API 35, mostly targeted on devices with A15 support and newer, NDK and AGP wasn't upgraded yet. The performance cost efficiency have been improved based on device power configuration; preventing overheating if certain devices tended to fall into NICE0 (not allocated threads priority, all task ran with higher priority, 11 tasks running within the limited 2 - 7 threads available on the most common configuration 1x3x4 or 1x4x3). Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4254

[core/core_timing] better MWAITX and WAITPKG delays (#3984)

2026-05-30T19:59:10+00:00

This implements MWAITX and WAITPKG extensions (umonitor, mwait) for CPUs that support them. Reduces wait times and bypasses the timing stuff from the OS that is slow (windows notably). generally it should answer within 0.2 to 0.5 microsecs (since most requests wait for that long). Also does a general rework of static ctors and stuff Signed-off-by: lizzie Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3984 Reviewed-by: MaranBr Reviewed-by: crueter

[common] remove ptr indirection on WallClock (#3864)

2026-05-15T20:06:38+00:00

also devirtualizes manually since compiler doesn't do it with LTO Signed-off-by: lizzie Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3864 Reviewed-by: crueter

[windows] Return x86 microsleep for Windows (#3563)

2026-02-17T05:15:45+00:00

Microsleep removal may have regressed AOC in msvc Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3563 Reviewed-by: CamilleLaVey Reviewed-by: Lizzie Co-authored-by: John Co-committed-by: John

[windows] return x86 microsleep for mingw only (#3544)

2026-02-15T02:41:25+00:00

Signed-off-by: lizzie Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3544 Reviewed-by: Maufeat Reviewed-by: DraVee Co-authored-by: lizzie Co-committed-by: lizzie

[frontend] Slow and Turbo modes (#3525)

2026-02-12T00:31:55+00:00

Closes #3344 Adds slow and turbo modes with configurable speeds that can then be toggled by the user. Behavior is: - Standard/slow limit, toggle turbo = turbo - Turbo limit, toggle turbo = standard - Standard/turbo limit, toggle slow = slow - Slow limit, toggle slow = standard Enabling the turbo/slow mode enables the frame limiter unconditionally. This has some conflicts with VSync. For example when I set my refresh rate to 60hz and enable vsync, turbo mode does nothing. Not sure how to go about fixing this, @MaranBr probably knows better the proper solution. Signed-off-by: crueter Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3525 Reviewed-by: DraVee Reviewed-by: CamilleLaVey

[core, windows] remove microSleep() and simply wait on events like on linux (#3498)

2026-02-09T00:14:32+00:00

we shall see if the original code was put there for a reason or if the microsleeps actually are horrid Signed-off-by: lizzie Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3498 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