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
a bit of refactoring so there's less code duplication...
probably a good idea to make it a lambda anyways
maybe this is why QLauncher didn't have proper DLCs and updates?
either way "GetPseudoDeviceId" is now implemented (still stubbed) with a proper hash instead of just 0
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4159
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
loader is barely called whereas audio for example is called super often
thus demote loaderr
jit is only ever used by Super Mario 3D stars, and no other
games require this to be a separate jit thread
additionally even of 3D stars this is called often chary
so no; we dont need a dedicated thread for it either way
this pr should help low power devices/devices with less cores/threads
to schedule the existing emulator threads more efficiently
also moving to guest means the CPU threads get more loaded with
stuffings, which is a good thing as most of the time theyre
sleeping and/or waiting for a mutex
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4148
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Contains the minimal set of functionalities to allow tico installer succeed, and tico work normally EXCEPT for game launching (which me or someone else will investigate later)
First three commits are from PR 4012.
The other six, kinda dizzy to explain each one. All were implemented based on tico source, switchbrew and libnx.
Hopefully the commit messages will do.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4086
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
#3908 changed process_creation.*, CreateProcess/CreateApplicationProcess, to return std::optional<Process> instead of std::unique_ptr<Process>, so the AM sites now transfer a Process by value via make_unique<Service::Process>(*std::move(opt)).
The consequence: Process owns a refcounted KProcess* but its user-declared dtor suppressed the implicit move ctor, so that "move" silently shallow-copied and the temporary's dtor Close()/RemoveProcess()'d the shared handle -> use-after-free.
It's seems to be user end based, so whether it crashes may depend on machine, compiler, allocator reuse, refcount slack, and the AM event-observer thread race, idk. It reliably crashed my MSVC build at launching games (cstack: ProcessHolder -> MultiWait -> KSynchronizationObject::Wait -> null) multiple times.
Fix: give Process a move ctor that steals the handle (nulling the source so the moved-from dtor is a no-op) and delete copy/move-assign, making the optional<->unique_ptr transfer safe.
Bonus: explicited delete for the 3 kinds of assignment: copy ctor (the one used in eden), copy assign and move assign (currently unused) to force compile error if they ever come to use.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4137
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
This add winding application function. Test this by opening qlaunch -> top left Profile -> edit profile picture -> go back (do not save if you are on fw21+, it corrupts the image)
And reverts in #3908 added `optional<Process>` to `unique_ptr<Process>`
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4134
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
two main issues:
shader_environment.cpp
Support Mesa nv50_ir-compiled homebrew fragment shaders
Mesa nv50_ir (used by NZP-Switch via libdrm_nouveau) emits Maxwell SASS that differs from NVN in two ways our shader pipeline didn't account for, causing "infinite" loops during shader scanning.
How? TryFindSize() previously detected end-of-shader only via NVN's "BRA $-1" self-branch trailer (SELF_BRANCH_A/B). Mesa-compiled shaders end with an unconditional @PT EXIT and emit no trailer, so scanning ran past the shader and looped to MAXIMUM_SIZE.
Fix: Added a secondary match against @PT EXIT T (opcode 0xE30, predicate PT, flow T) as a fallback terminator. The mask is estrictive enough to reject predicated EXITs, conditional-flow EXITs, and sched control words, so well-formed NVN shaders see no ehavior change (their single @PT EXIT immediately precedes BRA $-1, and both detections return the same size).
load_store_attribute.cpp + attribute.h
IPA's is_perspective check only applied the ×position_w correction for IR::IsGeneric() attributes, and used a per-component SPH lookup. Two failure modes followed:
1. Mesa fragment shaders read varyings via legacy attribute slots
(ColorFrontDiffuse, FixedFncTexture, FogCoordinate) which are
remapped to generic varyings later by ConvertLegacyToGeneric. At
IPA-translation time they're still legacy, so IsGeneric() was
false and the inject was skipped — but the resulting GLSL/SPIR-V
varying was Smooth (perspective-correct), and the SASS still
issued its manual perspective dance via MUFU.RCP(ATTR_W)+FMUL,
compounding an extra ×clip_w factor. NZP fog (eye_z distance
varying) ended up as eye_z⁴×density² instead of eye_z²×density²,
saturating fog to white everywhere.
2. Even for legacy attrs that should inject, Mesa stores them in two formats selected by the IPA's interpolation_mode field:
Pass/Multiply/Constant → attr/w (perspective); inject ×position_w
Sc (ScreenLinear) → raw attr; do NOT inject
Unconditionally injecting for Sc dims vertex colors by 1/clip_w because there's no SASS multiplier to round-trip it back.
Fix: extend the IPA correction path to also fire on IsLegacyAttribute(), gated on interpolation_mode != Sc. While here, the generic-path check is widened from per-component to vector-level (first non-Unused PixelImap, with all-Unused fallthrough treated as Perspective) so it matches the GLSL interpolation qualifier picked by CollectInterpolationInfo — this fixes the same all-zeroed-imap case Mesa exposes for explicit generics. IsLegacyAttribute moved from translate_program.cpp's anonymous namespace into attribute.h next to IsGeneric so IPA can reach it.
Tested on NaziZombies:Portable (Switch homebrew): fog now matches real
hardware, vertex-colored geometry (hand, gun, decals) renders correctly.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4012
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Homebrew (.NRO) program args support
Adds a 'program_args' setting and delivers it to NRO homebrews via libnx's homebrew ABI. NROs previously had no way to receive CLI flags (e.g. NZ:P's -noglsl).
Setting: program_args, Category::System, startup-only.
Surfaced in Qt + Android Debug sections.
NRO loader: builds a 4-entry 'ConfigEntry' table + argv at the data segment tail; prepends 'homebrew ' so user args land at argv[1]; scans for 'svc #7' to use as LR. Drops the stale NSO-style argdata append.
KProcess: stores loader-provided guest addresses; 'Run' switches to the homebrew entry (x0=config_ptr, x1=-1, lr=svc7) and patches the real MainThreadHandle into the ConfigEntry slot. Legacy NSO path unchanged.
Tested on NZP — args reach 'argv' correctly.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4013
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
OpenSaveDataFileSystem was missing a few SaveDataSpaceId mappings, so it would hit ASSERT(false). This broke games that open cache storage, with TOTK being the obvious one, because save enumeration could assert before the game even finished loading.
Fixed this by mapping Temporary to user nand, and ProperSystem/SafeMode to system nand. These only get used for the free-space check here, so they just need to point somewhere sane.
Fixes: https://github.com/eden-emulator/Issue-Reports/issues/368
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4069
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
This fixed issues in Mario Kart 8 multiplayer where the native controller applet would pop up, then once A was pressed and it exited, it would freeze the game but music would continue playing.
The issue was that UpdateRequestedFocusState() updates the focus state but never sets m_has_focus_state_changed for applications. Since ShouldSignalSystemEvent() checks that flag for applications, they never receive FocusStateChanged messages when LLE library applets exit. The game keeps running (hence the music) but is stuck waiting for a focus notification that never arrives. HLE applets aren't affected because their dummy process has is_process_running=false, so the game is never considered obscured in the first place.
Credits: [davidcollini](https://github.com/davidcollini)
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4027
Reviewed-by: Lizzie <lizzie@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>
Amaterasu from Discord asked about why nvnWindowGetNumActiveTextures returns 0 - after researching the console output it was asking for `DefaultDataSpace` (enum val 12) after some tests with the mod and debugging the console, this is my one-liner solution.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3956
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
traditionally, when doing jthread:
```
jthread() calls function parameter operator()() with args
function operator()() calls the code within
code within is, say { ThreadMain(); }
3 calls because why not
```
now this just makes it be 2 calls, mainly benefits non-LTO builds
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3970
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
hbloader is required to launch a bunch of shit (particularly hbmenu)
however due to some restrictive metadata validation, it doesn't get recognized as an NSP file
programs like hbmenu require hbloader (since it feeds them data like ConfigEntries and whatnot), launching hbmenu as-is standalone will result in a launchInit() error
adds an option to launch hbmenu via command line
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3981
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Reviewed-by: crueter <crueter@eden-emu.dev>
so basically each construction of HLEContext and whatever would result in a heap allocation (atleast 1)
so what if instead of that we did a memset() at ctor time and we avoided heap allocations altogether?
reminder that std::vector<> CAN do small object optimisation but it's not guaranteed
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3605
Reviewed-by: crueter <crueter@eden-emu.dev>
lizzie
crueter
CamilleLaVey
Maufeat
xbzk
BoiledElectricity
MaranBr