lizzie
218c6705d9
This PR primarily focuses on upbringing constexpr maps for handlers. Each time an HLE object of a service is construed, it registers it's own handlers, over and over. Regardless of whetever it needs them at the moment or not. Additionally we don't require to keep track of different function pointers amongst each object. This can be done by overriding the given function instead, as opposed to having a separate hash map for every given object. In other words: Remove handlers (and handlers_tipc) map for every instance then read from a static defined per-class. - [x] Migrate all HLE functions to new `frozen::map` constexpr time finder - [ ] Measure if this approach actually makes better codegen Optional: - [x] Properly gate all functions (that have versions commented next to them) - [x] Maybe store `HandlerFnP<>` and `const char*` separately, version gating can go in a different map as well Information such as name can be used on debug builds, but doesn't particularly help on release as one can consult an external reference (or have an annotated IPC map) Signed-off-by: lizzie <lizzie@eden-emu.dev> - [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. ------------------- Co-authored-by: Maufeat <sahyno1996@gmail.com> Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4480 Reviewed-by: Maufeat <sahyno1996@gmail.com> Reviewed-by: MaranBr <maranbr@eden-emu.dev>
3.0 KiB
Design Overview
Modern game consoles require heavy power to emulate. This is why the emulator uses an approach known as HLE (High-Level-Emulation), in a nutshell: Instead of accurately emulating every subsystem that forms part of a component, emulate the resulting visible output of said interface instead.
For example, take a disk write, instead of emulating a proper SD card we instead use the C++ standard library for I/O. Additionally we use the abstractions provided by the fs service to "lie" to programs about certain SD card properties. Notably this includes making up sizes for the fake SD card, giving "realistic" values or expected outputs for a given card, and so on. And instead of writing to an actual SD card, the emulator simply writes to a file.
This also means grand part of the emulator consists of just re-implementing firmware but using HLE primitives; for example audio doesn't go to an emulated audio device, but rather gets processed on the fly by a dedicated service and then passed to SDL3/cubeb/etc.
As such, many of the systems implemented are not 100% accurate to the original software, but they're "good enough" to pass as being so. While we do strive to maintain high compatibility (especially with homebrew), there are realistic limitations to these approaches.
No formal fuzzing or formal verification has been done on the emulator as a whole, this means there may be hundreds of bugs hiding in each subsystem. As such, output may also not correctly match due to those aforementioned issues.
src/android/
Entire Android frontend, written mostly in Kotlin and generally having asinine hacks (thanks Android) due to the particularly horrific (and particular way) to do things.
src/audio_core/
Handles everything related to audio, this is where most of the filtering and processing occurs (CPU intensive task!).
src/common/
The common folder contains just your basic polyfills for whatever missing functionality. We heavily encourage new PRs to make use of one of the dependencies, or the standard C++ library. Minimizing the amount of things we reinvent the wheel for is always a good thing.
src/core/
The core folder is the main heart of the emulator, while we don't officially support having other frontends out of the box (RetroArch, for example); any prospective developer can reuse this library (compiled as one by CMake) to stitch up their own RetroArch core, for example.
src/dynarmic/
See Dynarmic.
src/hid_core/
Input, joysticks, controllers and everything related to input devices.
src/shader_recompiler/
Dedicated shader recompiler to translate Maxwell assembly code to either SPIR-V, GLSL or GLASM.
src/video_core/
Most of the things here have their own dedicated section. In short this is basically the entire Tegra NVIDIA Maxwell GPU emulation. Additionally it includes some extra effects to emulate MSAA, D24 copies or as polyfill.
Available backends are: Null, Vulkan, and OpenGL.
See NVIDIA GPU.