d904706fc0
* Implement Jump Table for Native Calls NOTE: this slows down rejit considerably! Not recommended to be used without codegen optimisation or AOT. - Does not work on Linux - A32 needs an additional commit. * A32 Support (WIP) * Actually write Direct Call pointers to the table That would help. * Direct Calls: Rather than returning to the translator, attempt to keep within the native stack frame. A return to the translator can still happen, but only by exceptionally bubbling up to it. Also: - Always translate lowCq as a function. Faster interop with the direct jumps, and this will be useful in future if we want to do speculative translation. - Tail Call Detection: after the decoding stage, detect if we do a tail call, and avoid translating into it. Detected if a jump is made to an address outwith the contiguous sequence of blocks surrounding the entry point. The goal is to reduce code touched by jit and rejit. * A32 Support * Use smaller max function size for lowCq, fix exceptional returns When a return has an unexpected value and there is no code block following this one, we now return the value rather than continuing. * CompareAndSwap (buggy) * Ensure CompareAndSwap does not get optimized away. * Use CompareAndSwap to make the dynamic table thread safe. * Tail call for linux, throw on too many arguments. * Combine CompareAndSwap 128 and 32/64. They emit different IR instructions since their PreAllocator behaviour is different, but now they just have one function on EmitterContext. * Fix issues separating from optimisations. * Use a stub to find and execute missing functions. This allows us to skip doing many runtime comparisons and branches, and reduces the amount of code we need to emit significantly. For the indirect call table, this stub also does the work of moving in the highCq address to the table when one is found. * Make Jump Tables and Jit Cache dynmically resize Reserve virtual memory, commit as needed. * Move TailCallRemover to its own class. * Multithreaded Translation (based on heuristic) A poor one, at that. Need to get core count for a better one, which means a lot of OS specific garbage. * Better priority management for background threads. * Bound core limit a bit more Past a certain point the load is not paralellizable and starts stealing from the main thread. Likely due to GC, memory, heap allocation thread contention. Reduce by one core til optimisations come to improve the situation. * Fix memory management on linux. * Temporary solution to some sync problems. This will make sure threads exit correctly, most of the time. There is a potential race where setting the sync counter to 0 does nothing (counter stays at what it was before, thread could take too long to exit), but we need to find a better way to do this anyways. Synchronization frequency has been tightened as we never enter blockwise segments of code. Essentially this means, check every x functions or loop iterations, before lowcq blocks existed and were worth just as much. Ideally it should be done in a better way, since functions can be anywhere from 1 to 5000 instructions. (maybe based on host timer, or an interrupt flag from a scheduler thread) * Address feedback minus CompareAndSwap change. * Use default ReservedRegion granularity. * Merge CompareAndSwap with its V128 variant. * We already got the source, no need to do it again. * Make sure all background translation threads exit. * Fix CompareAndSwap128 Detection criteria was a bit scuffed. * Address Comments. |
||
|---|---|---|
| .github | ||
| ARMeilleure | ||
| Ryujinx | ||
| Ryujinx.Audio | ||
| Ryujinx.Common | ||
| Ryujinx.Debugger | ||
| Ryujinx.Graphics.GAL | ||
| Ryujinx.Graphics.Gpu | ||
| Ryujinx.Graphics.Nvdec | ||
| Ryujinx.Graphics.OpenGL | ||
| Ryujinx.Graphics.Shader | ||
| Ryujinx.Graphics.Texture | ||
| Ryujinx.HLE | ||
| Ryujinx.LLE | ||
| Ryujinx.ShaderTools | ||
| Ryujinx.Tests | ||
| Ryujinx.Tests.Unicorn | ||
| .gitattributes | ||
| .gitignore | ||
| .travis.yml | ||
| appveyor.yml | ||
| CONFIG.md | ||
| KEYS.md | ||
| LICENSE.txt | ||
| README.md | ||
| Ryujinx.sln | ||
| Ryujinx.sln.DotSettings | ||
Ryujinx
An Experimental Switch emulator written in C#
A lot of games boot, but only some are playable. See the compatiblity list here.
Usage
To run this emulator, you need the .NET Core 3.0 (or higher) SDK.
If you use a pre-built version, you can use the graphical interface to run your games and homebrew.
If you build it yourself you will need to:
Run dotnet run -c Release -- path\to\homebrew.nro inside the Ryujinx project folder to run homebrew apps.
Run dotnet run -c Release -- path\to\game.nsp/xci to run official games.
Every file related to Ryujinx is stored in the Ryujinx folder. Located in C:\Users\USERNAME\AppData\Roaming\ for Windows, /home/USERNAME/.config for Linux or /Users/USERNAME/Library/Application Support/ for macOS. It can also be accessed by clicking Open Ryujinx Folder under the File menu in the GUI.
Latest build
These builds are compiled automatically for each commit on the master branch, and may be unstable or completely broken.
The latest automatic build for Windows, macOS, and Linux can be found on the Official Website.
Requirements
-
Switch Keys
Everything on the Switch is encrypted, so if you want to run anything other than homebrew, you have to dump encryption keys from your console. To get more information please take a look at our Keys Documentation.
-
System Titles
Some of our System Module implementations, like
time, require System Data Archives. You can install them by mounting your nand partition using HacDiskMount and copying the content toRyujinx/bis/system. -
Executables
Ryujinx is able to run both official games and homebrew.
Homebrew is available on many websites, such as the Switch Appstore.
A hacked Nintendo Switch is needed to dump games, which you can learn how to do here. Once you have hacked your Nintendo Switch, you will need to dump your own games with NxDumpTool to get an XCI or NSP dump.
Features
-
Audio
Everything for audio is partially supported. We currently use a C# wrapper for libsoundio, and we support OpenAL (installation needed) too as a fallback. Our current Opus implementation is pretty incomplete.
-
CPU
The CPU emulator, ARMeilleure, emulates an ARMv8 CPU, and currently only has support for the new 64-bit ARMv8 instructions (with a few instructions still missing). It translates the ARM code to a custom IR, performs a few optimizations, and turns that into x86 code. To handle that, we use our own JIT called ARMeilleure, which uses the custom IR and compiles the code to x86.
-
GPU
The GPU emulator emulates the Switch's Maxwell GPU using the OpenGL API (version 4.2 minimum) through a custom build of OpenTK.
-
Input
We currently have support for keyboard, mouse, touch input, JoyCon input support emulated through the keyboard, and some controllers too. You can set up everything inside the configuration menu.
-
Configuration
The emulator has settings for dumping shaders, enabling or disabling some logging, remapping controllers, and more. You can configure all of them through the graphical interface or manually through the config file,
Config.json.For more information you can go here (Outdated).
Compatibility
You can check out the compatibility list here.
Don't hesitate to open a new issue if a game isn't already on there.
Help
If you have homebrew that currently doesn't work within the emulator, you can contact us through our Discord with the .NRO/.NSO and source code, if possible. We'll take note of whatever is causing the app/game to not work, on the watch list and fix it at a later date.
If you need help with setting up Ryujinx, you can ask questions in the support channel of our Discord server.
Contact
If you have contributions, need support, have suggestions, or just want to get in touch with the team, join our Discord server!
If you'd like to donate, please take a look at our Patreon.