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>
The approach on this PR moves around refactoring/ updating residual work; main issue was the whole logic behind msaa upload/download images with the constant image copy per pass required; which was gated via shaderStorageImageMultisample, which is not available on all the platforms supported including Android, making them to rely into a more heavier approach to convert msaa image copy into a non msaa image copy, not only losing precision in the conversion, but also creating bugs around the resolve of the image itself, if the supported path had to copy 2 times the same image to be actually presentable, when the fallback was enabled 3 copies were performed, not only decreasing the performance but also increasing race conditions due to the certain capabilities processed in this chain (storage_views). In order to resolve them more naturally, the constant copies were removed from the now "common" path along establishing a proper color resolve for Android and actually making them more direct.
Yet this opened a new pack of outdated handling on our current backend; since we now pass msaa images more directly (whenever a game request a msaa type of image/ which seems to be not common + each fragment resolves images on how it's actually required, adding missing depth/stencil), how we often load and store them becomes a critical issue, since our current configuration renderpass/framebuffer forces to always load and load clear whenever a new attachment it's passing through the renderpass, making this really heavier on memory bandwidth limited devices as SteamDeck and others that doesn't rely on the inmediate rendering mode (Tilers vs iGPU); to prevent over allocating data, I had to re-structure part of the current renderpass and framebuffer to actually reuse part of the data/ attachments called, with flags as DON'T_CARE, simplifying partially on how we actually call attachments including their barriers and conditions (occlusion, etc), the DON'T_CARE it's specifically useful to not only prevent calling new loads (which is a flush and heavier on tiler devices) and not only reusing the actual data store, which works on the future time, this saves memory bandwidth and gives space to actually avoid the constant pressure on SYSMEM/GMEM shader resolver path.
This maintenance also improved the current removal features logic on QCOM drivers, closing gaps between implementations on descriptors (VK_EXT_indexing_descriptor), adjusting the whole WMEL to avoid being so stricter if certain capabilities are missing to actually use this feature, leading to test and play more on how QCOM drivers are actually behaving; meanwhile the main objective is to open path for a robust and bigger implementation in the future, the changes made here also contains small bug fixes on SPIR-V logic, adding missing cases to resolve shaders (FP64 -> FP16), adding more robustness on how narrow features are actually being used and how to wired them whenever they're not available, meanwhile there are still some issues in regards on how Tegra vs Adreno can preserve unorms at FP32 and FP16, leaving better understanding on base for what VK_EXT_shader_float_controls is actually doing most of the times (flushes NaN's and Denorms equally).
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4212
if we are REALLY going thru for removing the entire game compat list
subsystem, we ought to remove the setting itself
I kept this PR separate because we MAY want to introduce emuready
compatibility, so keeping the setting will keep compatibility with
older setting files from users...
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4202
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
we have no use for it
it's dead code
most of the time users just complain about how the list isn't updated
ok so what if we update it? great now its more noise added to the git, awesome
even if we constantly update it, we introduce new breakage that makes keeping
track of things extremely difficult
either we integrate with emuready (would violate self containment principles)
or we integrate with emuready in a similar fashion to eden news outlet
(where we cache the list with some TTL of like 60 mins or whatever)
that would be better respecting of "self containment" but would probably
require having a quick way to update the list additively, probably filtered to the user's
device instead of a global thing, and i dont think emuready has that granularity
nor we have the "connect this to that" for the api stuffs
another (which is what i propose here) is throw everything out of the window
until someone can come up with something better
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4201
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
This simplifies the GPU accuracy setting by removing the intermediate Balanced mode and setting High as the default on desktop platforms.
It introduces a dedicated setting for GPU fence behavior, allowing the synchronization policy to be configured independently of GPU accuracy.
The Vulkan buffer cache now tracks GPU recording timeline ticks and waits only when necessary, reducing unnecessary synchronization while maintaining correctness for hard-to-trace graphical bugs.
GPU buffer readback has also been refined to synchronize only the affected upload regions when needed, and default DMA behavior has been updated to align with the new GPU accuracy model.
### TL;DR
The fix for particles freezing and unfreezing in mid-air in `Super Mario Odyssey` has been improved, resulting in less of a performance hit.
This game requires the new `Enable GPU Buffer Readback` option to be enabled to fix this issue.
The vertex explosions that occurred in `Super Mario Bros. Wonder`, especially in World 4, have been completely eliminated. You can now enjoy a smooth experience without graphical glitches exploding across the screen.
This game requires the new `GPU Fence Behavior` option to be set to `Strict` to fully fix this issue.
The flickering issue inside certain Shrines in `The Legend of Zelda: Tears of the Kingdom` has also been fixed.
For now, this game requires the new `GPU Fence Behavior` option to be set to `Accurate` to fully fix this issue.
These options are intended to fix graphical bugs in games that require better synchronization behavior between CPU and GPU, so other games may be affected as well.
Co-authored-by: xbzk <xbzk@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4182
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
This is the first step into the conversion on full GPU video decoding for Android; currently due to the VIC structure, I couldn't set it on surface mode to prevent the latency when sending video decoded (which is processed by GPU now), because currently we convert YUV420 into the Nvidia's format each frame constantly on CPU, aside the requirements from other extensions to work + VIC rewrite, which is a work currently not planned to happen on this PR; the actual configuration for video decoding is ByteBuffer, using GPU to decode NVDEC data (all codecs supported, h264, vp8 and vp9) and send it to CPU for display purposes, which is more faster than relying purely on CPU for any drawing task, saving devices resources/ heating, the downside on this will be the slight latency when a new frame is displayed, which is gonna be a black frame for less than a second, nothing major to harm the experience rather than actually trying our best to take advantage on hardware accelerated.
Aside this, I also added a bunch of minor Vulkan fixes to grant drivers less thinkering when receiving spir-v instructions, meaning this has new bans for extensions on QCOM (following reported issues on other projects working around Adreno driver behavior), this more than providing performance aims to enhance the stability on the driver, performance it's gonna likely to be hit based on the UBO's (StorageBufferAccess) operations and SSBO (uniformStorageBufferAccess), there was an already existing path for the emulation which forces to wide them into 32bit packed operations. I also included some smaller changes/ bugs + VUID's fixes from earlier changes on my work.
Special Thanks:
-> Mr. Smoly Gidolard (@gidoly)
Sources:
1.- https://github.com/microsoft/DirectXShaderCompiler/issues/2842
2.- https://github.com/mlc-ai/web-llm/issues/836
3.- https://github.com/ggml-org/llama.cpp/issues/5186
4.- https://github.com/encounter/aurora/pull/202
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4191
Based on the register of the ASTC implementation from Ameerj (yuzu), currently our conversion from ASTC on Desktop tends to duplicates the unpacking of ASTC converted textures, leading to bad performance; since there are some graphical effects that actually access on the band of 32bits (RGAF32) than the common 16bits (RGAF16) from our ASTC path decoding method, which commonly uses ARGB8 (degradation -> LDR) transformation to reduce the memory cost per conversion; meanwhile it could actually provide initially better performance; the engine tended to get stalled when this writted stage effect got skipped; mostly because CPU tends to look for an unimplemented texture/ format query (from which doesn't exist on our MaxwellToVK); unlike what's commonly believed HDR was a format to write enviroment effects even before their appearance on video output (since Switch doesn't have HDR, only SDR on certain engines).
The test result on this PR showed games like Astral Chain and other heavy reliant on ASTC decoding improved their performance and stability by around 15%; meanwhile could it be tied to a hardware gain, it's clearly a gain for direct access on what's required on most games. This PR also contains few Vulkan bug fix I encountered along this implementation.
Special Thanks:
-> Mr. Smoly Gidolard (@gidoly)
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4190
Following the philosophy on the previous Vulkan maintenance PR's, this one is reviewing the video_core to resolve VUID's related to the missing handling/ safechecks (UBO's case on missing StorageBufferAccess 8/16 bits on QCOM drivers, resulting on bad compute pipeline compiled), wiring topology representative to EDS2 configuration (following #4117), refactored the sampled image access via new memeber function for type "typeless" which adds a handling on the integer mistmatch (uint to sint, float to uint) + fixing bugs on current texture sampling (int) including the depth/stencil path resolve, maintenance to previous changes on query cache (resolving bugs from #3853), reduced the amount of binding BindVertexBufferEXT2 when a new tick/ frame is presented (with this being a reason for performance reduction on games where vertex polutes the stage, like BOTW/TOTK where grass is draw with vertex); implemented color border swizzle and color write enable for future improvements on EDS3, added initial implementation on Synchronization2 starting a path to ensure an access to VK 1.3 features safely and other smaller fixes along the road.
Special Thanks:
-> Mr. Smolio Gidolard (@gidoly)
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4189
this was only ever used for announce room json on one single instance
this object is pretty much a danger to society and shouldnt exist, especially since its:
a) a singleton
b) spawns objects out of thin air
c) doesn't respect RAII and can outlive its parent objects (big no no)
generally we shouldnt endorse objects like these in the future, but alas, it existed, now it has to begone
additionally there is a similar object in KWorkerTaskManager but it's not as egregious as this one.
check that this didnt break the usual announce room json logic
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4096
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
SURELY, microslop already fixed its megaslop?
basically read the comment (now gone); MSVC is evil, but it cant still be this evil right... right?!?!?! it's been 2 years surely not!
mainly because this helps deep scan (in theory); android should see slight improvments for big game libraries
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3670
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
small oopsie; we dont need 6 copies of the same 22KB table
(removes 5*22 = 110 KB worth of redundant stuff)
this also enforces static on the types defined in the header so they arent memoized into a non-inlined value (aka. compiler just grabs value instead of well, yknow, assuming its a constant area)
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4180
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
This minor change in src\video_core\renderer_vulkan\pipeline_helper.h allows renderdoc capture on mhr sunbreak.
Maybe it sanitizes some crashes on old vulkan GPUs.
Device log (nvidia kepler gpu vulkan 1.1.117):
[ 17.605262] Render.Vulkan <Info> video_core\vulkan_common\vulkan_device.cpp:1041:GetSuitability: Device doesn't support feature nullDescriptor
VUID-VkWriteDescriptorSet-descriptorType-02997
For sampled/combined/storage image descriptors, Khronos says imageView must be valid or VK_NULL_HANDLE
(https://docs.vulkan.org/refpages/latest/refpages/source/VkPhysicalDeviceRobustness2FeaturesKHR.html)
but then it says: if nullDescriptor is not enabled, imageView must not be VK_NULL_HANDLE.
(https://docs.vulkan.org/spec/latest/chapters/descriptorsets.html)
nullDescriptor is exactly the feature that allows descriptors to be written with null handles.
The fix relies on conditionally replacing the null sampled view with Eden’s dummy null-image-view object (ImageView constructor checks HasNullDescriptor which checks features.robustness2.nullDescriptor. cheap checks, and only for null handles, so no notable cost).
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4056
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
FIXES A REGRESSION FROM 4012.
TryFindSize's Mesa fallback matched the unconditional @PT EXIT (0xE30000000007000F) that nv50_ir emits at program end.
That exact word is also emitted by NVN mid-program for unconditional early-outs, so on retail titles (e.g. Super Mario 3D World) the scan truncated at the first early EXIT and dropped the rest of the shader, making textures vanish.
Mesa's terminal EXIT and NVN's mid-program EXIT are bit-identical, so no mask can separate them. Gate the heuristic on !is_proprietary_driver:
NVN binaries (bindless cbuf slot 2) keep self-branch-only sizing, while nouveau/Mesa homebrew (single terminal EXIT, no self-branch trailer) still uses the EXIT terminator. nv50_ir emits exactly one EXIT (early returns lower to BRA-to-exit, discard to DISCARD), so a single terminal match is correct for that path.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4151
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
#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>
EDS3 states were dynamic just because the driver supports them. But in EDS0-EDS2, we does not actually emit the EDS3 dynamic commands for them. So the pipeline builder skipped baking some fixed graphics state into the Vulkan pipeline, but the runtime also did not set that state dynamically. That leaves wrong Vulkan state during rendering causing rendering glitches in XC2.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4117
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
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>
Added an option to control the GPU buffer readback, as it causes issues if the hardware cannot keep up with the additional workload.
Some games require this to render certain effects properly.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4126
Inline index draws arrive as a batch but were processed one word at a time, so each index ran through the full per-method path and got appended a byte at a time.
Handle the whole batch in one pass instead, updating state once and appending all the indices together. Replay shadow control still goes word by word since it has to reload each one.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4083
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
5af7771f83-Bugfix: Made gpu_log_level global-only (was per-game switchable). Fixed Android non-determinism where a per-game profile silently overrode the global to Off and trapped GPULogger::Initialize() in a dead state, making shader dumps fail invisibly. Android per-game UI now hides the whole GPU logging block; Qt UI is untouched (global-only anyway).
bf4aabe8ab-Refactor/Cleanup: Removed gpu_logging_enabled master toggle as redundant with gpu_log_level == Off. Introduced GPU::Logging::IsActive() helper, replaced 14 call sites across vk_*.cpp. Refactored LogShaderCompilation() to be text-only and extracted SPIR-V dumping into a standalone GPU::Logging::DumpSpirvShader() free function. No singleton dependency, gated only by gpu_log_shader_dumps. Now gpu_log_level and gpu_log_shader_dumps are fully orthogonal. Cleaned up Android (BooleanSetting, SettingsItem, presenter, 7 locale string files).
865a1c5027-Refactor: Renamed dump_shaders → dump_guest_shaders to disambiguate from gpu_log_shader_dumps. Updated Qt label to "Dump Guest (Maxwell) Shaders" and rewrote the tooltip to mention .ash, the DumpDir/shaders/ location, and nvdisasm.
7cab456fdf-Feature: Added Qt UI control for GPU log level in the Logging session. Added gpu_log_shader_dumps checkbox to the Graphics column right below dump_guest_shaders.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4018
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
GetMacroAddress only reads a couple of indices per macro, but ProcessMacro was
then building a full std::vector GPUVAddr> with one push_back per parameter word
every submission. macro_segments already holds base, count per chunk, so
GetMacroAddress can just walk it instead, drops the per-word loop, a
.clear(), and a vector member.
Also makes it so it returns on the first match in the macro dispatch instead of running every
std::get_if check.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4067
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Adds a basic carousel view, or essentially a horizontal list a la Android/Qt Quick.
Lacks a lot of niceties like autoscroll, smooth shifts, etc. Will work on those later
Also fixed a bug introduced recently that capped game icon size to 8 at the low end, breaking the None option
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4112
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Shinmegumi <shinmegumi@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Prevent the CPU from getting too far ahead of the GPU by limiting pending flushes.
This fixes graphical issues in games that rely on better CPU and GPU synchronization in the Scheduler, such as the flickering bug inside shrines in The Legend of Zelda: Tears of the Kingdom.
This is enabled when the GPU is in Accurate mode.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4085
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: Shinmegumi <shinmegumi@eden-emu.dev>
- Remove unnecessary icon update code (the UI reloads this stuff anyways); test on Windows please
- Cleaned up a bunch of duplicated/unused code within the game list
- Fix the game list constantly reloading on macOS
* When you reconstruct the entire directory list on the watcher the directoryChanged signal fires on macOS--seems like a behavioral change that occurred somewhere in the 6.8 release cycle--and it would enter an infinite loop very quickly
* To fix this, only the differences between the current and old watch list are accounted for on both ends.
* Since this bug is now fixed, macOS uses Qt 6.11.1 now. Should theoretically improve our situation.
- Fix the external content watcher crashing; the worker would attempt to read files that didn't exist without any bounds since its cache was still pointing to that file.
This supersedes and replaces #4099.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4106
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
So the game list watcher could rebuild the content providers
(CreateFactories) while the populate worker was still scanning them, and
the worker would walk a torn-down RegisteredCache and segfault in
OpenFileOrDirectoryConcat. Fixed by stopping and joining the worker
before rebuilding.
On macOS the watcher also re-armed itself every populate. Re-adding the
same paths makes QFileSystemWatcher re-emit directoryChanged (the
FSEvent comes in async, so the blockSignals guard misses it), so it just
kept refreshing and the list flashed forever. Now it only re-arms when
the watched dirs actually changed.
Also null-guarded OpenFileOrDirectoryConcat so a torn-down cache cant
null-deref there.
Related: https://github.com/eden-emulator/Issue-Reports/issues/336
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4099
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
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>
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>
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>
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>
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>
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>
Something weird is happening with the CI that causes frequent build errors. For reasons I am not entirely certain of, Ninja fails to properly spawn a POSIX shell instance during the Make phase.
More investigation is in order, but for now fix it with the grand power of shelling out to CMake script
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4047
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Closes#3480
moves the game list model/worker/private stuff to qt_common for later
use in QML
- `qt_common/game_list/model.{cpp,h}` is the model
- `yuzu/game/game_{grid,tree}.*` are the views
- `yuzu/game/game_list.cpp` is the presenter
This was done very lazily in a manner that "works" while largely
maintaining existing structure as much as possible. Most of it is
copy-paste, with some bonus reworks/cleanups thrown in.
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4042
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
e.g. Serfrost's Defogger will now be named "Serfrosts Defogger" by
default, instead of "serfrosts_base_defogger_v2-4"
Note that for atmosphere mods it still uses the zip folder name, since otherwise their default name will just be the game's Title ID.
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4043
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
If YUZU_USE_BUNDLED_OPENSSL is off and OpenSSL is *not* installed to the
system, pulls in OpenSSL and Jimmy Park's CMake wrapper, then configures + builds from source.
Some patches were made on top of OpenSSL and openssl-cmake:
- USE_CCACHE is respected from UseCcache.cmake
- CXX/CFLAGS are passed from CMake to the configure script, which sends
those to the compiler
- Uses a bundled cert.h akin to the bundled OpenSSL build
Closes#3614
~~Before merge: remove verbose stuff~~ actually useful so nvm
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4032
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
fixes an yxzx era bug where eden assumed NVN-style packed SSBO descriptors (u64 gpu_addr followed by size) only happen in cbuf_index == 0.
Mega Man Star Force Collection proves that assumption is false. It has an unbiased/global-memory SSBO descriptor in cbuf_index == 3, offsets 0x100/0x300, but the descriptor still appears to be { address, size }.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4041
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: crueter <crueter@eden-emu.dev>
This PR aims to fix some regressions found in the latest release 0.2.0, which were a bunch of constant crashes/ random on certain Android devices with issues with the PiP configuration, addressing some problems founds for AMD after the maintenance of 2nd Global Vulkan Maintenance.
-> Fixes Final Fantasy Tactics on AMD (no longer requires of generic bits to work "all commands bit")
-> Fixes some performance regressions on android due to the Tomodachi fix applied globally as common behavior (#3898, #3900)
-> Fixes blittering of screen found on ARM Windows devices and QCOM stock drivers (Android and ARM Windows) related to Mario Kart 8 Deluxe strange blittering in races, caused by a strange race condition with the ResetQueryPool and mostly the workaround for presync
-> Fixes issues on Luigi's Mansion 3 issue where the pause screen became black on AMD due to the early reset of queries.
-> Fixes crashes on Mario Party Jamboree for AMD/ Nvidia.
-> Keeps previous fixes related to crashes on AMD with other games such as Astral Chain, Fire Emblem Three Houses and Xenoblade 3 based on the lack of access to vertex fragment replaced with generic flags.
-> Fixes TOTK RADV skybox lighting.
--------
Credits:
@melod-y
@Gidoly
@MaranBr
@AlexWolff
@Lizzie
And all the people who contributed into the reporting issues/ helping with the bisect.
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3953
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: crueter <crueter@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>
when shutting down the emulator will silence any remaining audio from the output buffer
however this is for some reason stored in an array instead of being a simple memset
additionally, said array can be small enough (`frame_size_bytes > silence.size()`) to cause a funky noise to play at the end
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3969
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>
before vs. after
Mario Brothership kept remaking vectors of sizes 256 AND 4095 (TIC) and 1215 AND 524287 (TSC) every single frame, which resulted in a noticeable overhead
the main cause was because of using `resize(n, c)` instead of `resize(n)` (also to aggressively resize for more room beforehand), the copy overload of resize does a copy of... well.. the value over the entire vector, additionally __append() keeps getting called because the capacity goes bonkers and all over the place


Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3874
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Matches the build ID and compiler now.
Note that this could still use some work on the Windows side of things.
Ideally, it would just replace the executables in place; however, I
think using the setup files will be better.
Most of my concerns w.r.t this issue is that users will want to install
multiple in the same place; however, I think it's fair to just not
support the older versions at all for now. If users really want to do
that, they can use the portable versions and cry about it.
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4019
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
u8 may have been 0xff, (aka. 255), but bitset was only 255 elements, so doing bitset[255] is technically OOB
additionally the max size estimate for index formats was not correct, there can be up to 256 elements with a u8 format index, not just 255
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4006
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
in short:
unrelated to the toggle, we found a missing piece that improved antiflicker and shader issues in some games, and we integrated it to balanced/accurate.
now testers confirmed side effects in some other games, so we reverted the integration.
the toggle itself is innocent. and the missing piece was kept for the toggle.
now, when the toggle is off, things are as they were before it.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4010
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@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>
tldr: we (me and maran) found the missing piece to make delay_fence and should_flush coop and cover all remaining flicker issues tested so far.
the lil change is in src/video_core/fence_manager.h
the rest is toggle stuff.
END
(credits rolls up)
post credits scene for the toggle drama:
i've been forced to use custom builds for around 1 year now, coz gpu mode above fast was pulling performance down yet not covering flicker entirely in most games tested. and we know that it's a mess to rely on gpu mode as it brings along a bunch of undesired stuff.
i need this toggle. and i've seem far less relevant before, so hey, gimme this one so i can call it mine :3
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4004
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
This PR reloads Android configuration when starting a game, so Eden uses the latest config.ini state for the emulation session.
On some Android launchers, Eden can already be running in the background before a game is launched. In that case, config.ini has already been read, so configuration changes made outside of Eden's settings flow while the process is alive are not picked up by the next emulation session.
This improves launch/config behavior for external launcher workflows.
Co-authored-by: FL-gs <efge.crea@gmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3965
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
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>
Removes Eden's own feature detection for SSE, SSE2, FMA4 and AVX_VNNI, in order to clean up code and make the function slightly lighter. They are all unused and I have specific reasons for their removal:
- SSE/SSE2 are always true for x64
- FMA4 is a deprecated AMD exclusive extension, replaced by the regular FMA and was logged here as "FMA" for no reason
- AVX_VNNI simply does not seem applicable for Eden (but can still be checked for through Xbyak's feature detection if necessary)
Co-authored-by: RedBlackAka <140876408+RedBlackAka@users.noreply.github.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3979
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
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>
Since the launch of the steam controller I think it's only best to push towards updating to SDL3 allowing for a wider range of controller support
I went ahead and started on getting it working. Everything here should be functional, I've personally tested it all on Arch Linux. Still untested on windows, so looking for feedback on that
Any feedback and help would be appreciated!
Main changes:
- Bump everything to SDL3
- Handle SDL3 audio and input
- Add steam controller support, including HD Rumble
- Improved battery reporting via the status icon by using real % rather than state alone
Co-authored-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3952
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
- [ ] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions).
- [ ] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md)
- [ ] 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.
AI and LLM use is *strictly* prohibited within our codebase and surrounding community, including issues and comments. This includes using AI or LLMs to write docs/commit messages, debug issues, brainstorm ideas, research concepts, or search the codebase.
AI and LLM use is *strictly* prohibited within our codebase and surrounding community, including issues and comments. This includes using AI or LLMs to write docs/commit messages, debug issues, brainstorm ideas, research concepts, or search the codebase.
- Join our [Discord](https://discord.gg/HstXbPch7X) community
- Submit [bug reports or feature requests](https://github.com/eden-emulator/Issue-Reports/issues), or on [Codeberg](https://codeberg.org/eden-emu/eden/issues)
- Contribute to our [translation efforts](./dist/languages/README.md)
## Code Contributions
Eden is free, open-source, copyleft software, licensed under the terms of the [GPLv3](https://www.gnu.org/licenses/gpl-3.0.en.html). You would do well to familiarize yourself with the GPL, [its FAQ](https://www.gnu.org/licenses/gpl-faq.html), and [free software as a concept](https://www.gnu.org/philosophy/free-sw.html) before contributing. If these terms are not acceptable to you, then you shouldn't contribute.
### Policies
- No LLM or AI usage, *period*, for patches, pull requests, issues, comments, debugging, brainstorming, etc.
- For details on why, see the [detailed AI policy](docs/AI.md).
- New code must follow the same general style as the surrounding codebase. Exceptions may be granted in certain cases.
- Maintainers reserve the right to change your patches and pull requests at will. We will try to avoid this.
- You should respect all decisions made by the [code owners](docs/CODEOWNERS) in your particular subsystem. If you feel they are overstepping or are incorrect, don't be afraid to stand your ground!
- While we do *not* adhere to the terms of a formal code of conduct, you will generally be expected to respect other developers, contributors, and community members.
- You **must** have basic knowledge of [Git](https://git-scm.com/learn). Knowing how to manage your branches and follow proper fork policies is a necessity.
### Where do I start?
Anywhere you like! If you are facing an issue and want to fix it, go ahead. For new features, you are heavily encouraged to open a feature request on GitHub, Codeberg, or Forgejo first, discussing the motivations, potential implementation, and user flow of your desired feature. Our UI/UX designers will work with you to refine your feature before you actually choose to implement it.
You may also search for open issues on [GitHub](https://github.com/eden-emulator/Issue-Reports/issues), [Codeberg](https://codeberg.org/eden-emu/eden/issues), or [Forgejo](https://git.eden-emu.dev/eden-emu/eden/issues). For larger features/refactors, you should first express your interest in the issue to ensure another developer isn't already working on it.
### Great! Can I contribute already?
There are five primary ways to contribute.
- Submit pull requests directly to our source tree
- You must first request an account on our Forgejo. See [Signup](#how-do-i-sign-up)
- Submit pull requests to our [GitHub mirror](https://github.com/eden-emulator/Issue-Reports)
- Note that this is subject to being removed by DMCA, so don't rely on this.
- Submit pull requests to our [Codeberg mirror](https://codeberg.org/eden-emu/eden)
- Codeberg is not subject to draconian DMCA laws, but they have been hostile to emulators such as Torzu in the past. Thus, you shouldn't rely on this either.
- Submit patches to [`patch@eden-emu.dev`](mailto:patch@eden-emu.dev)
- These **must** be in `git format-patch` format. You should familiarize yourself with the [art of patching](https://www.gitkraken.com/learn/git/git-patch) beforehand.
- Alongside the contents of your email, please attach the patch/diff file itself for easy access and use.
- Email our developers at [`developers@eden-emu.dev`](mailto:developers@eden-emu.dev) with any of your relevant findings or code changes.
To test your changes, ensure to read the [build documentation](./docs/Build.md) for your specific platform(s) to ensure everything compiles and works properly. You should also make sure that your branch is up-to-date with the upstream `master` branch before opening a pull request.
### How do I sign up?
<details>
<summary>To sign up and begin contributing... (click to open)</summary>
Email [crueter@crueter.xyz](mailto:crueter@crueter.xyz) with the following format:
```txt
Subject: [Eden Git] Registration Request
Username: <Your Desired Username>
Email: <Your Desired Email>
I wish to sign up because... <your reason here>
```
Received mail that does not follow this format will be ignored.
Once your request is processed, you will receive a confirmation email with your temporary password and some information on Git access and policies. If you do not receive a response within 48 hours, feel free to send another email.
> [!WARNING]
> Some email providers may place the response email in your spam/junk folder; notable offenders include Gmail and Outlook. *Always* ensure to check your Spam or Junk folder.
</details>
## Non-code Contributions
Alongside the other contribution methods listed up top, you can also choose to contribute through documentation, organization, or community guides. These can be done either through the code contribution methods described above, or created externally and shared via our Discord community.
If you have an external tool/page that you believe would be handy to integrate/link into Eden, please additionally email our developers at [`developers@eden-emu.dev`](mailto:developers@eden-emu.dev). **Do not submit vibe-coded or AI generated tools or applications**.
Most of the development happens on our Git server. It is also where [our central repository](https://git.eden-emu.dev/eden-emu/eden) is hosted. For development discussions, please join us on [Discord](https://discord.gg/HstXbPch7X) or [Stoat](https://stt.gg/qKgFEAbH).
You can also follow us on [X (Twitter)](https://nitter.poast.org/edenemuofficial) for updates and announcements.
If you would like to contribute, we are open to new developers and pull requests. Please ensure that your work is of a high standard and properly documented. You can also contact any of the developers on Discord or Stoat to learn more about the current state of the emulator.
See the [sign-up instructions](docs/SIGNUP.md) for information on registration.
Alternatively, if you wish to add translations, go to the [Eden project on Transifex](https://app.transifex.com/edenemu/eden-emulator) and review [the translations README](./dist/languages).
To contribute to Eden; be it financially, code, bug reports, or otherwise, see our [Contributing guidelines](./CONTRIBUTING.md).
## Documentation
@@ -73,23 +66,10 @@ For information on provided development tooling, see the [Tools directory](./too
## Download
You can download the latest releases from [here](https://git.eden-emu.dev/eden-emu/eden/releases).
You can download the latest releases from [our release page](https://git.eden-emu.dev/eden-emu/eden/releases).
Save us some bandwidth! We have [mirrors available](./docs/user/ThirdParty.md#mirrors) as well.
## Support
If you enjoy the project and would like to support us financially, please check out our developers' [donation pages](https://eden-emu.dev/donations)!
Any donations received will go towards things such as:
* Switch consoles to explore and reverse-engineer the hardware
* Switch games for testing, reverse-engineering, and implementing new features
* Web hosting and infrastructure setup
* Additional hardware (e.g. GPUs as needed to improve rendering support, other peripherals to add support for, etc.)
* CI Infrastructure
If you would prefer to support us in a different way, please join our [Discord](https://discord.gg/HstXbPch7X) and talk to Camille or any of our other developers.
## License
Eden is licensed under the GPLv3 (or any later version). Refer to the [LICENSE.txt](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/LICENSE.txt) file.
style="display:inline;mix-blend-mode:normal;fill:url(#linearGradient35);fill-opacity:1;fill-rule:nonzero;stroke:#320081;stroke-width:4.067;stroke-dasharray:none;stroke-opacity:1;paint-order:stroke fill markers"
style="display:inline;mix-blend-mode:multiply;fill:url(#linearGradient6);fill-opacity:1;fill-rule:nonzero;stroke:url(#linearGradient2);stroke-width:3.9666;stroke-dasharray:none;stroke-opacity:0.566238;paint-order:stroke fill markers"
inkscape:label="Circle"
d="M 256,2.2792898 A 254.0155,253.71401 0 0 0 150.68475,25.115202 c 19.54414,1.070775 38.74692,5.250294 51.56848,11.647658 14.14361,7.056691 28.63804,19.185961 39.4212,29.347551 h 40.60981 c 1.03847,-0.68139 2.10297,-1.36938 3.1938,-2.05957 5.45602,-15.78533 14.79164,-43.183497 19.49612,-57.0097682 A 254.0155,253.71401 0 0 0 256,2.2792898 Z m 61.57106,7.567234 -18.26098,46.1544672 c 7.79702,-4.13918 16.35655,-7.87447 25.20671,-10.87081 23.1229,-7.828433 43.96931,-10.170904 54.94058,-10.868226 A 254.0155,253.71401 0 0 0 317.57106,9.8465238 Z m 65.39277,26.4001532 c -9.68256,4.806644 -33.05532,16.642034 -55.68217,29.863734 H 424.4677 A 254.0155,253.71401 0 0 0 382.96383,36.246677 Z M 113.90698,45.690231 A 254.0155,253.71401 0 0 0 87.532302,66.110411 H 194.2739 c -1.47402,-0.80231 -2.35141,-1.25949 -2.35141,-1.25949 l 10.4496,-11.83348 -38.40568,7.01234 c 0,1e-5 -12.21537,-4.60266 -40.17313,-12.27223 -3.45336,-0.94731 -6.75329,-1.61824 -9.8863,-2.06732 z m -36.803618,30.18635 a 254.0155,253.71401 0 0 0 -34.88372,43.090929 h 59.976738 c 18.11461,-12.04145 40.14252,-22.882149 62.31266,-24.534159 52.93006,-3.9444 70.16538,1.86342 70.16538,1.86342 0,0 -4.612,-4.8206 -14.51938,-13.36656 -2.72366,-2.34942 -6.0844,-4.77373 -9.52455,-7.05363 z m 174.472868,0 c 4.57322,4.7186 7.29716,7.83565 7.29716,7.83565 0,0 3.53501,-3.18484 9.62532,-7.83565 z m 60.27649,0 c -21.56573,15.45339 -25.4703,27.979669 -25.4703,27.979669 0,0 54.83326,-19.215729 100.70543,-0.31228 11.63986,4.79661 21.58481,10.13159 29.94832,15.42354 h 52.74419 A 254.0155,253.71401 0 0 0 434.89664,75.876581 Z M 36.250648,128.73367 A 254.0155,253.71401 0 0 0 16.372095,171.82459 H 147.45478 c 1.45695,-2.5815 3.06539,-5.08648 4.83979,-7.48982 14.23694,-19.28301 27.92088,-30.0088 36.86047,-35.6011 h -30.25323 c -5.87346,0.93472 -12.04945,1.99094 -18.28166,3.16937 -30.12936,5.69727 -81.157618,22.78945 -81.157618,22.78945 0,0 11.47125,-12.39249 29.11369,-25.95882 z m 265.630492,0 c 33.48676,11.2434 52.42799,26.78443 62.7752,43.09092 h 130.97157 a 254.0155,253.71401 0 0 0 -19.87856,-43.09092 h -44.81136 c 14.85233,11.5863 21.59948,20.9854 21.59948,20.9854 0,0 -33.5226,-12.37087 -66.0646,-20.9854 z m -45.96641,16.27007 c -1.00419,0.0106 -10.12705,0.72026 -44.98966,20.64729 -3.12132,1.78406 -6.25434,3.86182 -9.37468,6.17356 h 41.81911 c 7.17181,-17.34774 12.64083,-26.82085 12.64083,-26.82085 0,0 -0.0287,-7.1e-4 -0.0957,0 z m 14.18088,0.0465 c 0,0 -3.31228,9.32762 -7.30492,26.77438 h 51.78554 C 287.6577,146.14158 270.09561,145.0502 270.09561,145.0502 Z M 13.152456,181.59075 A 254.0155,253.71401 0 0 0 3.927651,224.68167 H 134.1447 c 0.56161,-12.72411 2.67825,-28.50188 8.61499,-43.09092 z m 176.661504,0 c -14.27121,13.10564 -27.60733,29.58761 -37.56073,43.09092 h 73.3721 c 4.47018,-16.79061 9.35068,-31.26371 13.86562,-43.09092 z m 70.85787,0 c -2.41384,11.76417 -4.9032,26.20707 -6.94831,43.09092 H 360.4832 c -8.32133,-10.88917 -20.66988,-26.17008 -36.35141,-43.09092 z m 109.17313,0 c 6.63611,15.24089 6.92441,30.5373 5.57882,43.09092 h 132.64857 a 254.0155,253.71401 0 0 0 -9.22481,-43.09092 z M 2.90181,234.44783 A 254.0155,253.71401 0 0 0 1.984498,255.9933 254.0155,253.71401 0 0 0 2.90181,277.53876 h 211.89923 c 2.25762,-15.52555 5.14325,-29.93448 8.3385,-43.09093 h -77.8863 c -6.46396,9.27617 -10.33076,15.56549 -10.33076,15.56549 0,0 -0.82623,-6.14945 -0.9354,-15.56549 z m 249.72093,0 c -1.3692,13.09684 -2.4456,27.49209 -3.02068,43.09093 h 259.49613 a 254.0155,253.71401 0 0 0 0.91731,-21.54546 254.0155,253.71401 0 0 0 -0.91731,-21.54547 H 374.02584 c -0.445,2.5469 -0.90878,4.89768 -1.32817,7.01751 0,0 -1.69726,-2.53821 -4.94056,-7.01751 z M 3.927651,287.30493 a 254.0155,253.71401 0 0 0 9.224805,43.09091 H 214.04393 c -1.29238,-15.40742 -1.57503,-30.04388 -0.41861,-43.09091 z m 245.385009,0 c -0.30355,13.54349 -0.22032,27.92598 0.36951,43.09091 h 249.16537 a 254.0155,253.71401 0 0 0 9.22481,-43.09091 z M 16.369511,340.16201 a 254.0155,253.71401 0 0 0 19.878554,43.09091 H 221.4677 c -2.69781,-14.4523 -4.96108,-29.01285 -6.4832,-43.09091 z m 233.842379,0 c 1.15864,15.47765 3.81286,29.83979 7.51679,43.09091 h 218.02325 a 254.0155,253.71401 0 0 0 19.87856,-43.09091 z M 42.217052,393.01909 a 254.0155,253.71401 0 0 0 34.88372,43.09093 H 233.09561 c -3.40902,-13.67281 -6.76794,-28.2531 -9.73902,-43.09093 z m 218.490958,0 c 5.34985,16.15926 12.22007,30.51982 19.68733,43.09093 h 154.50389 a 254.0155,253.71401 0 0 0 34.88371,-43.09093 z M 87.529722,445.87618 a 254.0155,253.71401 0 0 0 166.229968,63.8208 c -3.67805,-12.0825 -10.85464,-35.49828 -18.18088,-63.8208 z m 199.010328,0 c 17.5887,26.43772 36.99259,43.60598 47.33592,51.61309 a 254.0155,253.71401 0 0 0 90.59431,-51.61309 z"/>
<path
id="path27"
style="display:inline;mix-blend-mode:multiply;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;paint-order:stroke fill markers"
style="display:inline;mix-blend-mode:multiply;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient27);stroke-width:3;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;paint-order:stroke fill markers"
This directory stores translation patches (TS files) for yuzu Qt frontend. This directory is linked with the [Eden project on transifex](https://app.transifex.com/edenemu/eden-emulator), so you can update the translation by executing `tx pull -t -a`. If you want to contribute to the translation, please go the transifex link and submit your translation there. This directory on the main repo will be synchronized with transifex periodically. Do not directly open PRs on github to modify the translation.
# Translating
This directory stores translation patches (TS files) for yuzu Qt frontend. This directory is linked with the [Eden project on transifex](https://app.transifex.com/edenemu/eden-emulator), so you can update the translation by executing `tx pull -t -a` in the root of this repository. If you want to contribute to the translation, please go the transifex link and submit your translation there.
When creating/improving translations, please keep in mind:
- You are responsible for providing accurate translations that do NOT contain illicit content or messages,
- Many of our developers do not speak the languages you may be translating, so will only be able to help with confusions about the source language,
- And bad-faith translations or attempts to insert illicit content may result in an immediate removal of access.
New language requests will not be honored for the time being.
4. Put `"C:/Program Files/Microsoft Visual Studio/18/Community/VC/Tools/Llvm/x64/bin/clang-cl.exe"` as your C/C++ compiler path.
5. Open `Visual studio > Open project` or Solution > Change to search for the CMake project file (`CMakeList.txt`) file on the cloned directory, and then build.
-`CPMUTIL_FORCE_SYSTEM` (default `OFF`): Require all CPM dependencies to use system packages.
- You may optionally override this for each package: [Package-Specific Overrides](#addendum-package-specific-overrides)
-`CPMUTIL_FORCE_BUNDLED` (default `ON` on MSVC and Android, `OFF` elsewhere): Require all CPM dependencies to use bundled packages.
- You may optionally override this for each package: [Package-Specific Overrides](#addendum-package-specific-overrides)
-`CPMUTIL_PATCH_DIR` (default `${PROJECT_SOURCE_DIR}/.patch`): Path to patches used in packages. Stored as `<PATCH DIR>/json-package-name/0001-patch-name.patch`, etc.
-`CPM_SOURCE_CACHE` (default `${PROJECT_SOURCE_DIR}/.cache/cpm`): Where downloaded dependencies get stored.
## About
CPMUtil works by defining dependencies in a JSON file, `cpmfile.json`, and calling `AddJsonPackage`. These dependencies generally must define, at minimum:
- The repository and Git host
- A release artifact, commit, or tag archive to download
- A SHA512 sum for the downloaded artifact
And may optionally define other properties like:
- The minimum version for system packages
- The package name used for system packages (this defaults to the json key if undefined)
- In-tree source patches
- Options passed to CMake
- Options passed to find_package
For instance:
```json
{
"fmt":{
"repo":"fmtlib/fmt",
"version":"12.1.0",
"hash":"f0da8...23f2",
"min_version":"8",
"options":[
"FMT_TEST ON"
],
"patches":[
"0001-disable-reference-copy.patch"
]
}
}
```
Calling `AddJsonPackage(fmt)`:
- Searches for a system package named `fmt` of version 8 or higher (`find_package(fmt 8)`)
- If found, uses the system package and caches it for future use
- If not found:
- Downloads fmt 12.1.0 from the GitHub Archive into `.cache/cpm/fmt/12.1.0`
- Verifies the hash
- Applies the `0001-disable-reference-copy.patch` patch to the source tree
- Sets `FMT_TEST` to `ON`
- Adds the downloaded directory to CMake
- Now, future `find_package(fmt)` calls will use the downloaded package
There are two types of packages CPMUtil can define: standard and prebuilt CI packages. Some properties are common to both types, however.
## Common Properties
These JSON properties are used by standard and CI packages alike.
-`package`: The package name used by `find_package` to check for the existence of a system package.
- If unset, defaults to the JSON key
-`repo`: The Git repository the package is stored in, if applicable.
-`version`: The version of the package. This is required.
- Generally, this should be a 10-wide Git commit hash or Git tag.
- Tags must be fully qualified and include prefixes and suffixes, e.g. `boost-1.88.0`
-`git_host`: The Git host the package is stored in, if applicable. Defaults to `github.com`.
## Standard Packages
Normal packages, like the prior `fmt` example, *must* also define:
-`hash`: The SHA512 hash of the downloaded artifact. CPMUtil generally computes this for you--if not, use `tools/cpmutil.sh package hash <JSON key>`
-`min_version`: The minimum required version of the package, if a system package is desired.
And may optionally define:
-`url`: Download from a raw URL.
-`artifact`: A GitHub/Forgejo/Gitea release artifact. Requires `repo` to be set and valid.
-`numeric_version`: Replaces `%NUMERIC_VERSION%` in artifact and version definitions; see [Artifact Naming Errata](#artifact-naming-errata).
See [Versioning](#versioning) for version/artifact information.
The following are optional to define:
-`source_subdir`: A subdirectory containing the `CMakeLists.txt` to configure a project. Useful for projects like `zstd`.
-`bundled`: Force the usage of a bundled package. Useful for packages where the system package is broken or nonexistent; e.g. external fragment shaders or data archives.
- Note that this will conflict with `CPMUTIL_FORCE_SYSTEM`; for this reason, when using non-library archives, it may be best to allow the user to download and extract the archive manually and specify a local directory to it.
-`find_args`: Additional arguments passed to `find_package`, e.g. `MODULE`
-`patches`: Array of in-tree patches to apply to the downloaded source code. See [#Patches](TODO).
-`options`: Array of CMake options to apply before configuring the package, e.g. `"FMT_TEST ON"`.
### Versioning
When fetching from a Git repository, there are generally three methods of versioning:
- Commit hashes
- Git tags
- Release artifacts
When `repo` is set, `version` field can be set to any commitish value, including commit hashes or Git tags. In the case of artifacts, `version` must be a Git tag, and `artifact` must be set to a release artifact attached to that tag. Many repositories intentionally version the filenames of their release artifacts; for this purpose, CPMUtil allows you to implant the version number into the artifact name. To do so, add `%VERSION%` to the artifact name; CPMUtil will then automatically replace `%VERSION%` with the `version` field. This means that when changing versions, you only need to update the version, not the artifact!
Take Boost as an example. The artifact for Boost 1.90.0 is `boost-1.90.0-cmake.tar.xz`, and the tag is `boost-1.90.0`. Thus, we can set the artifact to `%VERSION%-cmake.tar.xz`:
```json
"boost":{
"repo":"boostorg/boost",
"version":"boost-1.90.0",
"artifact":"%VERSION%-cmake.tar.xz"
}
```
The artifact will then evaluate as `boost-1.90.0-cmake.tar.xz`.
### Artifact Naming Errata
While `%VERSION%` replacement is generally good enough for well-packaged projects, occasionally there may be some problematic packages. Take, for instance, Vulkan Validation Layers:
- Tag (`version`): `vulkan-sdk-1.4.341.0`
- Artifact: `android-binaries-1.4.341.0.zip`
Attempting to add version replacement to the artifact definition **would not work here!** In this case, you must utilize the `numeric_version` field described earlier; we would set `numeric_version` to `1.4.341.0` and add `%NUMERIC_VERSION%` replacements into our artifact and version fields:
`artifact` will thus evaluate to `android-binaries-1.4.341.0.zip`, and `version` to `vulkan-sdk-1.4.341.0`. CPMUtil's auto-updater will also account for this and only update `numeric_version`!
### Patches
CPMUtil is able to apply in-place source tree patches to downloaded packages. These are defined in JSON as an array of names, preferably using `git-format-patch`'s scheme of `<4 digit number>-patch-name.patch`.
They are stored in `<CPMUTIL_PATCH_DIR>/<json-key>` (remember that `CPMUTIL_PATCH_DIR` defaults to `$ROOT/.patch`); e.g. `boost` patches would be in `.patch/boost`. Let's say we've made three patches and want to add them; in the Boost JSON definition, we would add:
```json
"patches":[
"0001-fix-clang-cl-compilation.patch",
"0002-fix-msvc-arm64-compilation.patch",
"0003-fix-bsd-linking.patch"
]
```
Then, when Boost is downloaded, it will apply these patches to the source tree in the order they are defined (compound/dependent patches are okay!). Note that when you add, remove, or modify patches, CPMUtil will invalidate your downloaded cache and re-fetch the source.
To learn how to make patches, see [Addendum: Making Patches](#addendum-making-patches).
## Pre-built CI Packages
The definition and usage of CI packages is subject to change in the very near future.
CI packages are, in essence, prebuilt binary distributions for libraries. They exist for a few reasons:
- Creating static libraries for system packages that normally lack them, e.g. Qt/SDL
- Reducing duplicated compilation effort on rarely-changing externals, e.g. SDL
- Creating debloated prebuilt packages specifically for your project to reduce binary size, e.g. FFmpeg
CPMUtil is specifically designed to work with a small subset of prebuilt CI packages; namely, those that follow the format of the [crueter-ci spec](https://github.com/crueter-ci/spec/blob/master/README.md).
To use them, you must add `ci: true` to your package definition. Alongside the common properties, CI packages define the following:
-`name`: The artifacts' name prefix (required), e.g. `openssl`
-`extension`: The artifacts' extension (default `tar.zst`)
-`disabled_platforms`: CPMUtil-supported platforms that are not built into this repository.
- This is subject to change.
**Note that `package` is subject to removal here.**
Example:
```json
"sdl2":{
"repo":"crueter-ci/SDL2",
"package":"SDL2",
"min_version":"2.26.4",
"ci":true,
"version":"2.32.10-a65111bd2d",
"artifact":"SDL2"
},
```
## Usage
Once you've defined your package in `cpmfile.json`, simply call `AddJsonPackage(<JSON key>)` and go from there! Specific instructions differ between individual packages, so you're on your own from here.
If you're only concerned with basic usage, you can stop reading. For more advanced use cases and package management, read these addenda.
## Addendum: Cache Storage
CPMUtil stores downloaded packages within `.cache/cpm` by default (see `CPM_SOURCE_CACHE`). Subdirectories stored within are lowercase representations of the `find_package` name for the package; for instance, a `vulkan-headers` definition with `package: "VulkanHeaders"` would be stored in `.cache/cpm/vulkanheaders`.
Within these subdirectories, additional directories are created for each individual version, corresponding directly to their `version` field. CI packages use `<platform>-<architecture>-<version>` unconditionally.
To see the cache directory for a given package, use `tools/cpmutil.sh package dir <JSON key>`.
## Addendum: Making Patches
CPMUtil has a dedicated command for making patches. You're recommended to have Git and a command line editor installed, but CPMUtil is able to work without either. To do so, follow these steps, noting your package's JSON key:
- Clean-fetch your package: `tools/cpmutil.sh package reset <package>`
- Make any necessary modifications to the package source.
- You can access the package source directory via `tools/cpmutil.sh package dir <package>`.
- Create the patch: `tools/cpmutil.sh package patch <package>`
- Follow the on-screen prompts. If you have Git installed, an editor will be opened so you can type your commit message. If not, just type a one-line description.
And you're done! CPMUtil will automatically create and name the patch, and add it to the list of patches in the JSON definition.
## Addendum: Package Identification Lists
CPMUtil will create three lists of dependencies where `AddPackage` or similar was used. Each is in order of addition.
-`CPM_PACKAGE_NAMES`: The names of packages included by CPMUtil
-`CPM_PACKAGE_URLS`: The URLs to project/repo pages of packages
-`CPM_PACKAGE_SHAS`: Short version identifiers for each package
- If the package was included as a system package, `(system)` is appended thereafter
- Packages whose versions can't be deduced will be left as `unknown`.
For an example of how this might be implemented in an application, see Eden's implementation:
If you are packaging a project that uses CPMUtil, read this!
### Network Sandbox
For sandboxed environments (e.g. Gentoo, nixOS) you must install all dependencies to the system beforehand and set `-DCPMUTIL_FORCE_SYSTEM=ON`. If a dependency is missing, get creating!
Alternatively, if CPMUtil pulls in a package that has no suitable way to install or use a system version, download it separately and pass `-D<PackageName>_CUSTOM_DIR=/path/to/downloaded/dir`.
### Unsandboxed
For others (AUR, MPR, etc). CPMUtil will handle everything for you, including if some of the project's dependencies are missing from your distribution's repositories. See [`eden-git`](https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=eden-git) for an example.
## Addendum: Dependent Packages
Consider the following scenario: the Vulkan Headers and Vulkan Utility libraries are both pulled in by my project. In order for both to compile cleanly, their versions *must* match. However, a user may have the Vulkan Headers installed, but *not* the Vulkan Utility Libraries! This can cause a version mismatch where the Utility Libraries expect a much newer version of the Vulkan Headers than the user has installed.
To solve this, CPMUtil has an `AddDependentPackages` command. This takes a list of JSON package keys that *must* either ALL be installed to the system, or ALL be bundled.
- The user has both Vulkan Headers and Vulkan Utility Libraries installed to the system, and both are new enough.
- Configuration proceeds without issue.
- The user has neither installed, or has a too-old version of Vulkan Headers installed
- Configuration proceeds without issue.
- The user has a valid Vulkan Headers installed, but not Vulkan Utility Libraries.
- CPMUtil instructs the user to either force bundled Vulkan Headers, or install Vulkan Utility Libraries.
- The user has both installed, but Vulkan Headers are too old.
- CPMUtil instructs the user to install a valid version of Vulkan Headers, or force bundled Vulkan Utility Libraries.
## Addendum: Module Path Packages
Sometimes, a prebuilt CI package may be packed in such a way that it's meant to be used in the context of a system install (e.g. pkgconfig or CMakeConfig files). In this case, CPMUtil normally will be unable to configure the downloaded subdirectory. To solve this, you can use `AddJsonPackage`'s `MODULE_PATH` mode, which adds the downloaded source directory to the `CMAKE_MODULE_PATH`.
### Example: OpenSSL
Say an OpenSSL CI package is packed to contain its CMake config files rather than a root `CMakeLists.txt`; in this case, you would call:
```cmake
AddJsonPackage(NAMEopensslMODULE_PATH)
```
The `NAME` argument is also required, as the parsing is different from the standard single-argument function signature.
From here, calling `find_package(OpenSSL)` will use the bundled OpenSSL.
## Addendum: Adding Qt
If you'd like to use customized Qt builds, CPMUtil provides a convenience function that allows you to add Qt builds. This usage and setup is subject to change.
See [crueter-ci/Qt](https://github.com/crueter-ci/Qt) for an example of how one might build customized Qt. To add a Qt build to your project, use `AddQt(<repository> <version>)`, e.g.:
```cmake
AddQt(QDash-CI/Qt6.11.1)
```
Then, call `find_package(Qt6 ...)` and it will pull Qt from your downloaded source.
## Addendum: Package-Specific Overrides
There are three variables that CPMUtil defines for each package; these can be overriden by the user or in your CMake. `package` refers either to the `package` value in the JSON, or the package's JSON key if unset (see `package` in [Common Properties](#common-properties)):
-`<package>_FORCE_BUNDLED`: Forcefully bundle the package. This has the same effect as `CPMUTIL_FORCE_BUNDLED`, but only for this package.
-`<package>_FORCE_BUNDLED`: Forcefully use the system package, failing if it can't be found. This has the same effect as `SYSTEM`, but only for this package.
-`<package>_CUSTOM_DIR`: Path to an extracted copy of the package. CPMUtil will not attempt to download the package and will instead use the custom directory.
- For an example, see [CPMUtil's test case](https://git.crueter.xyz/CMake/CPMUtil/src/branch/master/tests/dir/CMakeLists.txt)
Additionally, in CMake, you can add `FORCE_BUNDLED_PACKAGE ON` to your `AddJsonPackage` command--note that you will have to use the `NAME <key>` syntax as described in [Module Path Packages](#addendum-module-path-packages). This will overrule *all* other overrides, including `CPMUTIL_FORCE_SYSTEM` and `<package>_FORCE_SYSTEM`--use with caution!
## Addendum: Supply-Chain Security
Many package managers suffer from the issue of supply chain security, specifically in regards to silent overwrites of existing packages or archives, e.g. tag sliding and artifact overwriting. CPMUtil has three methods to protect against this.
### Checksumming
CPMUtil *requires* SHA512 checksums for standard packages, and soon will for CI packages as well. If an attacker or compromised account slides a tag, overwrites a release artifact, or otherwise attempts to compromise anything that CPMUtil may fetch, **CPMUtil will not allow the download to continue!** This means that consumers of your build system can **only** download an artifact if the contents of the artifact are *exactly* indentical to what it was when it was configured--any changes at all will be rejected by CPMUtil.
### Caching
CPMUtil uses a mutable cache system, stored by default in `.cache/cpm`. Dependencies are downloaded and extracted here, and can be reused infinitely. This means that, for instance, if a package is compromised but you already have a cached local copy, you won't have to worry at all!
### Immutable Commit Hashes
CPMUtil is capable of using immutable Git commit hashes for its artifacts. These are (barring SHA1 collisions) completely immune to supply chain attacks--that is, unless the entire root server gets compromised to serve infected artifacts/source code; at which point there are much larger issues to worry about. This means that once you set a package to use a Git commit hash for its version, **it will stay the same forever**. This is useful if you want to ensure that consumers are never faced with download failures stemming from hash mismatches in case of compromised artifacts.
Do note, however, that this will render the package incompatible with CPMUtil's built-in auto-updater, so you will have to manually update the package.
Use `AddDependentPackage` when you have multiple packages that are required to all be from the system, OR bundled. This is useful in cases where e.g. versions must absolutely match.
In each directory that utilizes `CPMUtil`, there must be a `cpmfile.json` that defines dependencies in a similar manner to the individual calls.
The cpmfile is an object of objects, with each sub-object being named according to the package's identifier, e.g. `openssl`, which can then be fetched with `AddJsonPackage(<identifier>)`. Options are designed to map closely to the argument names, and are always strings unless otherwise specified.
<!-- TOC -->
- [Options](#options)
- [Examples](#examples)
<!-- /TOC -->
## Options
-`package` -> `NAME` (`PACKAGE` for CI), defaults to the object key
-`repo` -> `REPO`
-`version` -> `VERSION`
-`ci` (bool)
If `ci` is `false`:
-`hash` -> `HASH`
-`hash_suffix` -> `HASH_SUFFIX`
-`sha` -> `SHA`
-`key` -> `KEY`
-`tag` -> `TAG`
- If the tag contains `%VERSION%`, that part will be replaced by the `git_version`, OR `version` if `git_version` is not specified
-`url` -> `URL`
-`artifact` -> `ARTIFACT`
- If the artifact contains `%VERSION%`, that part will be replaced by the `git_version`, OR `version` if `git_version` is not specified
- If the artifact contains `%TAG%`, that part will be replaced by the `tag` (with its replacement already done)
-`git_version` -> `GIT_VERSION`
-`git_host` -> `GIT_HOST`
-`source_subdir` -> `SOURCE_SUBDIR`
-`bundled` -> `BUNDLED_PACKAGE`
-`find_args` -> `FIND_PACKAGE_ARGUMENTS`
-`download_only` -> `DOWNLOAD_ONLY`
-`patches` -> `PATCHES` (array)
-`options` -> `OPTIONS` (array)
-`skip_updates`: Tells `check-updates.sh` to not check for new updates on this package.
Other arguments aren't currently supported. If you wish to add them, see the `AddJsonPackage` function in `CMakeModules/CPMUtil.cmake`.
If `ci` is `true`:
-`name` -> `NAME`, defaults to the object key
-`extension` -> `EXTENSION`, defaults to `tar.zst`
-`NAME` (required): The package name (must be the same as the `find_package` name if applicable)
-`VERSION`: The minimum version of this package that can be used on the system
-`GIT_VERSION`: The "version" found within git
-`URL`: The URL to fetch.
-`REPO`: The repo to use (`owner/repo`).
-`GIT_HOST`: The Git host to use
- Defaults to `github.com`. Do not include the protocol, as HTTPS is enforced.
-`TAG`: The tag to fetch, if applicable.
-`ARTIFACT`: The name of the artifact, if applicable.
-`SHA`: Commit sha to fetch, if applicable.
-`BRANCH`: Branch to fetch, if applicable.
The following configurations are supported, in descending order of precedence:
-`URL`: Bare URL download, useful for custom artifacts
- If this is set, `GIT_URL` or `REPO` should be set to allow the dependency viewer to link to the project's Git repository.
- If this is NOT set, `REPO` must be defined.
-`REPO + TAG + ARTIFACT`: GitHub release artifact
- The final download URL will be `https://github.com/${REPO}/releases/download/${TAG}/${ARTIFACT}`
- Useful for prebuilt libraries and prefetched archives
-`REPO + TAG`: GitHub tag archive
- The final download URL will be `https://github.com/${REPO}/archive/refs/tags/${TAG}.tar.gz`
- Useful for pinning to a specific tag, better for build identification
-`REPO + SHA`: GitHub commit archive
- The final download URL will be `https://github.com/${REPO}/archive/${SHA}.zip`
- Useful for pinning to a specific commit
-`REPO + BRANCH`: GitHub branch archive
- The final download URL will be `https://github.com/${REPO}/archive/refs/heads/${BRANCH}.zip`
- Generally not recommended unless the branch is frozen
-`REPO`: GitHub master archive
- The final download URL will be `https://github.com/${REPO}/archive/refs/heads/master.zip`
- Generally not recommended unless the project is dead
## Hashing
Hashing is used for verifying downloads. It's highly recommended to use these.
-`HASH_ALGO` (default `SHA512`): Hash algorithm to use
Hashing strategies, descending order of precedence:
-`HASH`: Bare hash verification, useful for static downloads e.g. commit archives
-`HASH_SUFFIX`: Download the hash as `${DOWNLOAD_URL}.${HASH_SUFFIX}`
- The downloaded hash *must* match the hash algorithm and contain nothing but the hash; no filenames or extra content.
-`HASH_URL`: Download the hash from a separate URL
## Other Options
-`KEY`: Custom cache key to use (stored as `.cache/cpm/${packagename_lower}/${key}`)
- Default is based on, in descending order of precedence:
- First 4 characters of the sha
-`GIT_VERSION`
- Tag
-`VERSION`
- Otherwise, CPM defaults will be used. This is not recommended as it doesn't produce reproducible caches
-`DOWNLOAD_ONLY`: Whether or not to configure the downloaded package via CMake
- Useful to turn `OFF` if the project doesn't use CMake
-`SOURCE_SUBDIR`: Subdirectory of the project containing a CMakeLists.txt file
-`FIND_PACKAGE_ARGUMENTS`: Arguments to pass to the `find_package` call
-`BUNDLED_PACKAGE`: Set to `ON` to default to the bundled package
-`FORCE_BUNDLED_PACKAGE`: Set to `ON` to force the usage of the bundled package, regardless of CPMUTIL_FORCE_SYSTEM or `<package>_FORCE_SYSTEM`
-`OPTIONS`: Options to pass to the configuration of the package
-`PATCHES`: Patches to apply to the package, stored in `.patch/${packagename_lower}/0001-patch-name.patch` and so on
- Other arguments can be passed to CPM as well
## Extra Variables
For each added package, users may additionally force usage of the system/bundled package.
-`${package}_DIR`: Path to a separately-downloaded copy of the package. Note that versioning is not checked!
-`${package}_FORCE_SYSTEM`: Require the package to be installed on the system
-`${package}_FORCE_BUNDLED`: Force the package to be fetched and use the bundled version
## System/Bundled Packages
Descending order of precedence:
- If `${package}_FORCE_SYSTEM` is true, requires the package to be on the system
- If `${package}_FORCE_BUNDLED` is true, forcefully uses the bundled package
- If `CPMUTIL_FORCE_SYSTEM` is true, requires the package to be on the system
- If `CPMUTIL_FORCE_BUNDLED` is true, forcefully uses the bundled package
- If the `BUNDLED_PACKAGE` argument is true, forcefully uses the bundled package
- Otherwise, CPM will search for the package first, and if not found, will use the bundled package
## Identification
All dependencies must be identifiable in some way for usage in the dependency viewer. Lists are provided in descending order of precedence.
URLs:
-`GIT_URL`
-`REPO` as a Git repository
- You may optionally specify `GIT_HOST` to use a custom host, e.g. `GIT_HOST git.crueter.xyz`. Note that the git host MUST be GitHub-like in its artifact/archive downloads, e.g. Forgejo
- If `GIT_HOST` is unspecified, defaults to `github.com`
-`URL`
Versions (bundled):
-`SHA`
-`GIT_VERSION`
-`VERSION`
-`TAG`
- "unknown"
If the package is a system package, AddPackage will attempt to determine the package version and append `(system)` to the identifier. Otherwise, it will be marked as `unknown (system)`
Simply call `AddQt(<Qt Version>)` before any Qt `find_package` calls and everything will be set up for you. On Linux, the bundled Qt library is built as a shared library, and provided you have OpenSSL and X11, everything should just work.
On Windows, MinGW, and MacOS, Qt is bundled as a static library. No further action is needed, as the provided libraries automatically integrate the Windows/Cocoa plugins, alongside the corresponding Multimedia and Network plugins.
## Modules
The following modules are bundled into these Qt builds:
- Base (Gui, Core, Widgets, Network)
- Multimedia
- Declarative (Quick, QML)
- Linux: Wayland client
Each platform has the corresponding QPA built in and set as the default as well. This means you don't need to add `Q_IMPORT_PLUGIN`!
## Example
See an example in the [`tests/qt`](https://git.crueter.xyz/CMake/CPMUtil/src/branch/master/tests/qt/CMakeLists.txt) directory.
## Versions
The following versions have available builds:
- 6.9.3
See [`crueter-ci/Qt`](https://github.com/crueter-ci/Qt) for an updated list at any time.
CPMUtil is a wrapper around CPM that aims to reduce boilerplate and add useful utility functions to make dependency management a piece of cake.
Global Options:
-`CPMUTIL_FORCE_SYSTEM` (default `OFF`): Require all CPM dependencies to use system packages. NOT RECOMMENDED!
- You may optionally override this (section)
-`CPMUTIL_FORCE_BUNDLED` (default `ON` on MSVC and Android, `OFF` elsewhere): Require all CPM dependencies to use bundled packages.
You are highly encouraged to read AddPackage first, even if you plan to only interact with CPMUtil via `AddJsonPackage`.
- [AddPackage](#addpackage)
- [AddCIPackage](#addcipackage)
- [AddJsonPackage](#addjsonpackage)
- [AddQt](#addqt)
- [Lists](#lists)
- [For Packagers](#for-packagers)
- [Network Sandbox](#network-sandbox)
- [Unsandboxed](#unsandboxed)
## AddPackage
The core of CPMUtil is the [`AddPackage`](./AddPackage.md) function. [`AddPackage`](./AddPackage.md) itself is fully CMake-based, and largely serves as an interface between CPM and the rest of CPMUtil.
## AddCIPackage
[`AddCIPackage`](./AddCIPackage.md) adds a package that follows [crueter's CI repository spec](https://github.com/crueter-ci).
## AddJsonPackage
[`AddJsonPackage`](./AddJsonPackage.md) is the recommended method of usage for CPMUtil.
## AddDependentPackage
[`AddDependentPackage`](./AddDependentPackage.md) allows you to add multiple packages such that all of them must be from the system OR bundled.
## AddQt
[`AddQt`](./AddQt.md) adds a specific version of Qt to your project.
## Lists
CPMUtil will create three lists of dependencies where `AddPackage` or similar was used. Each is in order of addition.
-`CPM_PACKAGE_NAMES`: The names of packages included by CPMUtil
-`CPM_PACKAGE_URLS`: The URLs to project/repo pages of packages
-`CPM_PACKAGE_SHAS`: Short version identifiers for each package
- If the package was included as a system package, `(system)` is appended thereafter
- Packages whose versions can't be deduced will be left as `unknown`.
For an example of how this might be implemented in an application, see Eden's implementation:
If you are packaging a project that uses CPMUtil, read this!
### Network Sandbox
For sandboxed environments (e.g. Gentoo, nixOS) you must install all dependencies to the system beforehand and set `-DCPMUTIL_FORCE_SYSTEM=ON`. If a dependency is missing, get creating!
Alternatively, if CPMUtil pulls in a package that has no suitable way to install or use a system version, download it separately and pass `-DPackageName_DIR=/path/to/downloaded/dir` (e.g. shaders)
### Unsandboxed
For others (AUR, MPR, etc). CPMUtil will handle everything for you, including if some of the project's dependencies are missing from your distribution's repositories. That is pretty much half the reason I created this behemoth, after all.
- Modify the generated ffmpeg.make (in build dir) if using multiple threads (base system `make` doesn't use `-j4`, so change for `gmake`).
- If using OpenIndiana, due to a bug in SDL2's CMake configuration, audio driver defaults to SunOS `<sys/audioio.h>`, which does not exist on OpenIndiana. Using external or bundled SDL2 may solve this.
- System OpenSSL generally does not work. Instead, use `-DYUZU_USE_BUNDLED_OPENSSL=ON` to use a bundled static OpenSSL, or build a system dependency from source.
## OmniOS
Install `developer/gcc14` on OmniOS using pkgsrc.
Since so many dependencies are missing on `OmniOS`, you may wish to use `-DCPMUTIL_FORCE_BUNDLED=ON -DYUZU_USE_EXTERNAL_SDL2=ON`
Since so many dependencies are missing on `OmniOS`, you may wish to use `-DCPMUTIL_FORCE_BUNDLED=ON`
For OmniOS you are required to build glslang yourself:
Gentoo's cross-compilation setup is relatively easy, provided you're already familiar with portage. A [cross toolchain file](../CMakeModules/toolchains/GentooCross.cmake) is provided. Throughout this section, replace `aarch64` with whatever target architecture you desire.
### Crossdev
First, emerge crossdev via `sudo emerge -a sys-devel/crossdev`.
Now, set up the environment depending on the target architecture; e.g.
```sh
sudo crossdev aarch64
```
### QEMU
If you don't have a host Gentoo system of your target architecture, you should install a QEMU user setup for testing. To do so, enable the relevant USE flags for `app-emulation/qemu`:
To use cross-emerged shared libraries, you will also need to tell qemu where the sysroot is. You can do this with an alias:
```sh
alias qemu-aarch64="qemu-aarch64 -L /usr/aarch64-unknown-linux-gnu"
```
### Dependencies
Dependencies are the same [as normal Gentoo](./Deps.md#Commands); simply replace the `emerge` command with `emerge-<target>-unknown-linux-gnu` (e.g. `emerge-aarch64-unknown-linux-gnu`). However, there are a few caveats:
#### Enabling GURU
Since Crossdev sysroots are effectively isolated from the system w.r.t Portage, you must manually enable GURU in your sysroot. Run the following as root:
Crossdev is not perfect, and you may face some challenges with package that are not properly keyworded or have issues on specific architectures. These behaviors are, unfortunately, not well documented, and certain build systems such as Meson--and certain troublesome packages like GTK--are generally unfriendly towards cross-compilation.
Thus, it may be desirable to emerge a minimal set of dependencies and allow Eden's build system to handle the rest for you. At a minimum, you *only* need standard system libraries (Crossdev does this for you) and Qt:
From here, CPMUtil will take care of everything else. For extra insurance, you may want to set `-DCPMUTIL_FORCE_BUNDLED=ON` in your configure command.
### Building
From here, building is relatively standard. The [cross toolchain file](../CMakeModules/toolchains/GentooCross.cmake) contains a few additional configurations, but generally all you need to do is set `CROSS_TARGET` and `CMAKE_TOOLCHAIN_FILE`. Disabling OpenGL is strongly recommended as well.
@@ -69,29 +69,6 @@ Expressions can be `variable_names` or `1234` (numbers) or `*var` (dereference o
For more information type `info gdb` and read [the man page](https://man7.org/linux/man-pages/man1/gdb.1.html).
## Simple checklist for debugging black screens using Renderdoc
# RenderDoc (Graphic Debugging Tool)
Renderdoc is a free, cross platform, multi-graphics API debugger. It is an invaluable tool for diagnosing issues with graphics applications, and includes support for Vulkan. Get it at [renderdoc.org](https://renderdoc.org).
Before using renderdoc to diagnose issues, it is always good to make sure there are no validation errors. Any errors means the behavior of the application is undefined. That said, renderdoc can help debug validation errors if you do have them.
When debugging a black screen, there are many ways the application could have setup Vulkan wrong.
Here is a short checklist of items to look at to make sure are appropriate:
- Draw call counts are correct (aka not zero, or if rendering many triangles, not 3)
- Vertex buffers are bound
- vertex attributes are correct - Make sure the size & offset of each attribute matches what should it should be
- Any bound push constants and descriptors have the right data - including:
- Matrices have correct values - double check the model, view, & projection matrices are uploaded correctly
- Pipeline state is correct
- viewport range is correct - x,y are 0,0; width & height are screen dimensions, minDepth is 0, maxDepth is 1, NDCDepthRange is 0,1
- Fill mode matches expected - usually solid
- Culling mode makes sense - commonly back or none
- The winding direction is correct - typically CCW (counter clockwise)
- Scissor region is correct - usually same as viewport's x,y,width, &height
- Blend state is correct
- Depth state is correct - typically enabled with Function set to Less than or Equal
- Swapchain images are bound when rendering to the swapchain
- Image being rendered to is the same as the one being presented when rendering to the swapchain
Alternatively, a [RenderDoc Extension](https://github.com/baldurk/renderdoc-contrib/tree/main/baldurk/whereismydraw) ([Archive](https://web.archive.org/web/20250000000000*/https://github.com/baldurk/renderdoc-contrib/tree/main/baldurk/whereismydraw)) exists which automates doing a lot of these manual steps.
Guidelines for graphical debugging using RenderDoc: **[RenderDoc usage](./RenderDoc.md)**
* **[Python3](https://www.python.org/downloads/)** 3.10+ - necessary to download external repositories
@@ -35,6 +35,11 @@ If you are on desktop and plan to use the Qt frontend, you *must* install Qt 6,
* For help setting up Qt Creator, run `./install.sh -h qtcreator`
* If you're using clang-cl and want to still use MSVC
* Check the option to add "C++ clang compiler for Windows" on Visual Studio installer and uncheck "x64/x86 build tool for MSVC" while selecting "C++ desktop developement tools" and change Visual Studio to 2026, from 2022.
* At qt creator section generator tab change Visual Studio 17 2022 to 2026.
* Finally, to use clang-cl: `cmake -S . -B build -G "Visual Studio 17 2026" -T ClangCL`
If you are on **Windows** and building with **MSVC** or **clang-cl**, you may go [back home](Build.md) and continue.
## Externals
@@ -42,7 +47,7 @@ If you are on **Windows** and building with **MSVC** or **clang-cl**, you may go
The following are handled by Eden's externals:
* [FFmpeg](https://ffmpeg.org/) (should use `-DYUZU_USE_EXTERNAL_FFMPEG=ON`)
* [SDL2](https://www.libsdl.org/download-2.0.php) 2.0.18+ (should use `-DYUZU_USE_EXTERNAL_SDL2=ON` OR`-DYUZU_USE_BUNDLED_SDL2=ON` to reduce compile time)
* [SDL3](https://www.libsdl.org/download-2.0.php) 3.2.10+ (Use`-DYUZU_USE_BUNDLED_SDL2=ON` to reduce compile time)
All other dependencies will be downloaded and built by [CPM](https://github.com/cpm-cmake/CPM.cmake/) if `YUZU_USE_CPM` is on, but will always use system dependencies if available (UNIX-like only):
In brief, the HOS kernel is a microkernel, all services and programs run in userspace, the primary way to do communication between these is via `HIPC` (not covered here); otherwise most of the primitives reside in the forms of syscalls invoked via `svc #imm`. The kernel supports both 32-bit and 64-bit programs, and has the capacity to use 32, 36 and 39 bits of address space for spawned processes. Most of the networking stack is based off FreeBSD's network stack.
The emulator implements the majority of the syscalls pertaining to the HOS kernel itself. When we talk about the HOS Kernel (in the context of the emulator) we are strictly speaking about the mechanisms from which syscalls are handled (and it's subsequent side effects, such as the page table book-keeping). The emulator at it's current state is unable to load a custom low-level kernel and do supervisor-level emulation.
Most programs in NX eventually invoke an `svc`, which, depending on it's immediate value, will go on to be dispatched into one of the specific syscall handlers.
These can be seen in [svc.cpp](/src/core/hle/kernel/svc.cpp). All of these correspond to syscalls which userspace programs may perform.
In turn, these syscalls create the mechanisms that allows programs to use CMIF/TIPC as their primary IPC form to contact other services/processes running on the system, the details of which will not be covered here, but you can consult the relevant [SwitchBrew article: 'HIPC'](https://switchbrew.org/wiki/HIPC).
From the point of view of the programs, no special devices (such as PCIE, Realtek drivers, Bluetooth or USB) has to be handled by the emulator; this is because most of the fun occurs in specialized services such as `usb:u` or `pcie` services. Which aren't emulated (yet).
Due to the nature of syscalls, many of them interact with memory. The emulated kernel has an internal tree-like structure, borrowed from FreeBSD's intrusive red-black tree; this is used to track and find mappings added or removed. Thus most of the process space is emulated in this way.
The kernel keeps it's own separate pagetable, in a traditional sense, each process has it's own pagetable, this is true for HOS as well.
Every process keeps it's own tracking of the following structures:
- Name (13 characters)
- 64-bit ID
- A handle table
- Exclusive monitor
- Threads
- Held locks
- Thread local pages
- A page table for each process
The emulator willingly restricts itself to only use 4 threads (to emulate 4 cores), this is because most existing applications do not benefit greatly from the added core count, and in fact can be detrimental due to extra contention. This translates equitatively to about 4 `ArmInterface` slots for each process, these are then redirected to whatever is the last `pc` of the last thread running on the core is meant to be; proceed to run it, then when returning (due to halt or interruption), proceed to reschedule the thread.
The scheduler as-is isn't 100% faithful to the original (for example the original is cooperative and not preemptive), and has great timing variance (especially due to the fact the emulator can run in systems with wildly different timings).
-`YUZU_USE_BUNDLED_OPENSSL` (ON for MSVC, Android, Solaris, and OpenBSD) Download bundled OpenSSL build
-`YUZU_USE_EXTERNAL_SDL2` (OFF) Compiles SDL2 from source
-`YUZU_USE_BUNDLED_SDL2` (ON for MSVC) Download a prebuilt SDL2
-`YUZU_USE_BUNDLED_SDL3` (ON for MSVC) Download a prebuilt SDL3
### Miscellaneous
@@ -44,6 +43,9 @@ These options control dependencies.
- UNIX may be better off appending `-flto=thin` to compiler args
-`USE_FASTER_LINKER` (OFF) Check if a faster linker is available
- Not recommended outside of Linux
-`YUZU_INSTALL_UDEV_RULES` (OFF) Install udev rules to enable hidraw access
- Needed for gyroscopes
- Only available on Linux
### Flavors
@@ -60,7 +62,7 @@ These options control executables and build flavors.
**Desktop only**:
-`YUZU_CMD` (ON) Compile the SDL2 frontend (eden-cli)
-`YUZU_CMD` (ON) Compile the SDL-based frontend (eden-cli)
-`YUZU_ROOM` (OFF) Compile dedicated room functionality into the main executable
-`YUZU_ROOM_STANDALONE` (OFF) Compile a separate executable for room functionality
-`YUZU_STATIC_ROOM` (OFF) Compile the room executable *only* as a static, portable executable
@@ -96,5 +98,6 @@ The following options were a part of Eden at one point, but have since been reti
-`ENABLE_SDL2` - While technically possible to *not* use SDL2 on desktop, this is **NOT** a supported configuration under any means, and adding this matrix to our build system was not worth the effort.
-`YUZU_USE_CPM` - This option once had a purpose, but that purpose has long since passed us by. *All* builds use CPMUtil to manage dependencies now.
- If you want to *force* the usage of system dependencies, use `-DCPMUTIL_FORCE_SYSTEM=ON`.
-`YUZU_USE_EXTERNAL_SDL` - This is now handled automatically. It was included even after CPM for purposes that have not applied for a very long time.
See `src/dynarmic/CMakeLists.txt` for additional options--usually, these don't need changed
Are you just a casual user? Take a look at our [User Handbook](./user) then!
If you want to register/signup as a contributor, take a gander at the [signup guide](./SIGNUP.md).
This contains documentation created by developers. This contains build instructions, guidelines, instructions/layouts for [cool stuff we made](./CPMUtil), and more.
Renderdoc is a free, cross platform, multi-graphics API debugger. It is an invaluable tool for diagnosing issues with graphics applications, and includes support for Vulkan. Get it at [renderdoc.org](https://renderdoc.org).
RenderDoc can capture Eden's Vulkan output when its Vulkan layer is loaded before Eden creates the Vulkan device. Before using renderdoc to diagnose issues, it is always good to make sure there are no validation errors. Any errors means the behavior of the application is undefined. That said, renderdoc can help debug validation errors if you do have them.
## Usage on Windows
You can either use RenderDoc UI to launch eden, or you can make eden attach it internally:
On Windows PowerShell:
```powershell
$env:ENABLE_VULKAN_RENDERDOC_CAPTURE='1'
.\eden.exe
```
When RenderDoc is attached, Eden logs the default Windows capture folder:
```text
%LOCALAPPDATA%\Temp\RenderDoc
```
Press RenderDoc's capture hotkey, usually `F12`, to capture a frame. To stop using RenderDoc, close Eden and launch it again without `ENABLE_VULKAN_RENDERDOC_CAPTURE`.
## Eden Hotkey
Eden also has a separate `Toggle Renderdoc Capture` hotkey behind the debug setting `renderdoc_hotkey`.
That hotkey does not load or unload RenderDoc. It only toggles Eden's own manual capture through RenderDoc's API:
- first press: starts a capture
- second press: ends that capture
## Simple checklist for debugging black screens using Renderdoc
When debugging a black screen, there are many ways the application could have setup Vulkan wrong.
Here is a short checklist of items to look at to make sure are appropriate:
- Draw call counts are correct (aka not zero, or if rendering many triangles, not 3)
- Vertex buffers are bound
- vertex attributes are correct - Make sure the size & offset of each attribute matches what should it should be
- Any bound push constants and descriptors have the right data - including:
- Matrices have correct values - double check the model, view, & projection matrices are uploaded correctly
- Pipeline state is correct
- viewport range is correct - x,y are 0,0; width & height are screen dimensions, minDepth is 0, maxDepth is 1, NDCDepthRange is 0,1
- Fill mode matches expected - usually solid
- Culling mode makes sense - commonly back or none
- The winding direction is correct - typically CCW (counter clockwise)
- Scissor region is correct - usually same as viewport's x,y,width, &height
- Blend state is correct
- Depth state is correct - typically enabled with Function set to Less than or Equal
- Swapchain images are bound when rendering to the swapchain
- Image being rendered to is the same as the one being presented when rendering to the swapchain
Alternatively, a [RenderDoc Extension](https://github.com/baldurk/renderdoc-contrib/tree/main/baldurk/whereismydraw) ([Archive](https://web.archive.org/web/20250000000000*/https://github.com/baldurk/renderdoc-contrib/tree/main/baldurk/whereismydraw)) exists which automates doing a lot of these manual steps.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.