should fix crashes on:
- NetBSD
- SELinux
- OpenBSD
- other W^X systems
- some person trying to be funny with W^X on their system even if they dont have to
perf impact should be minimal
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4090
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
makes it so the shader cache goes properly in `XDG_CACHE_HOME`.
SOME people have it set to point to `/tmp` AND as a ramdisk, if they can do that they probably would want their shader caches to be there as well and wouldnt mind the extra hit from invalidations on reboot.
afterall, its a cache, not some holy data that needs to be kept at all costs.
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4093
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
should now be more align with actual values/enums :)
trivial change
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4077
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Good fix or absolute trash?
For me it seems like an OK balance, better would be fully dynamic; but I believe 256 is a reasonable limit?
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3982
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
should make a few more homebrew boot :)
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3771
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
should fix some issues with some NAS setups
where people have their games on a NAS and they
try to access it but for some reason some file
just doesnt load, instead of aborting early we continue
for the rest of the files in the directory
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4100
Reviewed-by: Shinmegumi <shinmegumi@eden-emu.dev>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
The GL shader profile hardcoded max_user_clip_distances to 8. Query the
device limit like the Vulkan path already does (it reads
maxClipDistances), so we use what the host actually reports.
Clamp to Maxwell's NumClipDistances (8) since the guest never produces
more than that and the SPIR-V output array is sized for at most 8. So a
host reporting fewer than 8 is respected, and one reporting more can't
overrun anything.
Fixes#3910https://git.eden-emu.dev/eden-emu/eden/issues/3910
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4095
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@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>
So CreateInstance was enumerating instance extensions twice, and that could race if the driver returned a different list the second time. On some AMD iGPU drivers, we could enable an extension from the first list, then fail the second check with VK_ERROR_EXTENSION_NOT_PRESENT.
Fix this by enumerating once and passing that same snapshot into RequiredExtensions.
Fixes: https://github.com/eden-emulator/Issue-Reports/issues/414
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4072
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>
Liz' command. ETC2 format list added. Used mainly in homebrew, NZ:P for example.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4061
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 fixes a bug introduced in the Xenoblade Chronicles series where some small elements would occasionally flicker on the screen.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4066
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
samu will be happy
basically this handles the edge case where either:
a) eden is the first application ever ran (i.e no config dirs made yet)
b) user didnt have them
c) user is trying to run on a sandbox appimage or whatever bs
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4087
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Adds an NSIS Windows installer file. Includes:
- Installation to `user\AppData\Local\Eden` (user install; does not require administrator and makes the integrated updater work and same as e.g. yuzu, Citra, Azahar)
- Shortcuts for Start Menu and optionally to Desktop
- File association with `.nsp`, `.xci`, `.nro` and `.kip`
- Throughout uninstallation and registry cleanup
And finally, needs to be implemented into the GitHub CI workflow, will submit a PR there later uwu
Co-authored-by: RedBlackAka <140876408+RedBlackAka@users.noreply.github.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4008
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Testing which deps can't cross MSVCRT/UCRT barriers
- openssl
- Qt
FFmpeg and Sirit are fine--likely don't use the C99 APIs that MSVCRT is missing?
Closes#4022
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4035
the correct behaviour would be for the hle service NOT to crash
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3729
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Added a bunch of "Scanning ... for CXX dependencies" steps to the build.
We don't use modules and probably won't for a very long time, so we
don't need this.
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4063
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
GetIndexFromAruid returns AruidIndexMax as the “not found” value, but both
GetControllerFromNpadIdType overloads were using that value to index
controller_data without checking it first.
when a game routes through DisconnectNpad before its applet resource is
registered, we can end up indexing past the end of controller_data. That seems
to be what was crashing some games on launch, especially on macOS and Android,
where the out-of-bounds read is less likely to just slide by unnoticed.
So yeah, AruidIndexMax is a sentinel, not a real controller_data index, so we
should not treat it like one.
Fixes: https://github.com/eden-emulator/Issue-Reports/issues/438
Fixes: https://github.com/eden-emulator/Issue-Reports/issues/439
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4064
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
This fixes an Android game library scan crash when reading XCI title metadata with empty or incomplete NACP language entries.
Previously, NACP::GetLanguageEntry() could fall back to:
language_entries.at(static_cast<u8>(Language::AmericanEnglish))
When language_entries was empty, this threw std::out_of_range and aborted the Android scan thread.
The new fallback preserves the existing lookup order:
1. preferred language entry with non-empty application name
2. any entry with non-empty application name
3. first available entry
4. static empty LanguageEntry if no entries exist
Tested locally with a Mainline RelWithDebInfo APK on Odin3 Android 15 using a large external TF-card ROM directory. The previous build crashed during fresh ROM scan; the patched build completes scanning normally.
Related my issue:
https://github.com/eden-emulator/Issue-Reports/issues/500
Co-authored-by: bdm110 <bdm110@prontmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4062
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: crueter <crueter@eden-emu.dev>
Rudimentary tests showed that using PGO on macOS *does* have an
appreciable impact on performance. So we're probably going to introduce
it soon.
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4050
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Ubuntu 24.04 can't hurt us anymore.
Some other deps may have their versions raised, but there's not much of
an incentive so we'll keep it as is for now.
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4055
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
(gdb) set scheduler-locking on
(gdb) continue
As discussed in #3848, follow-up to implement vCont support according to spec.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3896
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: crueter <crueter@eden-emu.dev>
does a bit of code dedup
fixes pre-SSE4.1 having horrific CMHI/CMLO
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4025
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
most stdlibc++ already provide this functionality out of the box, very consistently and well implemented (usually)
my main irk is that the llvm itanium demangle is totally unescesary when there is a perfectly stable, tested and well documented equivalent functionality in the standard stdc++ provided in most UNIX oses
its mostly to reduce binary size by a very thin margin, but he stdc++ is more than capable of doing he same behaviour we use a dpeendency for
for mingw or such howeger,, demangling becomies trickier so we have to exclude windows entirely because well windows likes to do things differently dont they
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3894
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
This fix a bug in which eden crashes when renderdoc is attached to vulkan.
that kept me away from renderdoc for around a year now.
the bug:
in video_core\renderer_vulkan\vk_staging_buffer_pool.cpp
in GetStreamBufferSize(...)
if device.HasDebuggingToolAttached()
but heap is empty/unavailable <-- Case in my old nvidia kepler gpu
the original method returns size 0, right?
the change honors same original behavior, while covers my case properly, returning MAX_STREAM_BUFFER_SIZE.
addl some log tip and some minimal doc. fully safe. let it rip.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4052
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
lizzie