| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fallback that measures the TSC rate when the CPU reports none was
meant for AMD, which has no leaf 0x15 at all. It also caught Intel CPUs
that have the leaf but report a crystal frequency of 0 (Coffee Lake,
e.g. the i5-9400F) and moved them from the OS clock to the measured
RDTSC clock. With the same fallback in another Eden-based build, an
i5-9400F crashed about 3.5 s after launch; limiting the fallback to
CPUs without the leaf fixed it for that tester.
Those Intel CPUs now keep the OS clock, as before the fallback. AMD
CPUs still get the measured RDTSC clock (a Ryzen 7 9800X3D reports
max leaf 0xd, so nothing changes there).
Assisted-by: Claude Opus 5.5 (debugging, porting and drafting)
Signed-off-by: Duck912 <350528965+Duck912@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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=<Hz> 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
off the hot path
- AMD CPUs have no CPUID leaf 0x15, so the TSC frequency stayed 0 and
every guest CNTPCT read went through QueryPerformanceCounter (~10% of
the game's main core in title 1). Measure it like Intel CPUs without
a crystal frequency.
- A rejected native shader was rethrown (two C++ throws) every time it
was bound; return false instead (~1-2% of the GPU thread).
- The semaphore watch, pushbuffer entry hashing, first-write trace and
per-macro debug logs ran on every command word or macro call; they
now cost a flag check unless their environment variable is set
(~4% of the GPU thread). Also starts the macro engine's profile zone.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Split the RDTSC ticks-per-nanosecond ratio into integer and Q0.64 fractional components. This avoids overflowing GetFixedPoint64Factor for TSC frequencies above 1 GHz while preserving the multiply-only conversion path.
Use the invariant clock only above 1 GHz because the reverse nanoseconds-per-tick factor cannot represent an exact ratio of one.
- [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/4422
Reviewed-by: lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- add `#pragma once` to remainder files
- "correcter" defines (ANDROID), see https://groups.google.com/g/android-ndk/c/cf9_f1SLXls
- extra miscelly fixups
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4039
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: crueter <crueter@eden-emu.dev>
|
|
|
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 <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3984
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: crueter <crueter@eden-emu.dev>
|
