No description
Find a file
Lioncash f2331a804a core/cpu_core_manager: Create threads separately from initialization.
Our initialization process is a little wonky than one would expect when
it comes to code flow. We initialize the CPU last, as opposed to
hardware, where the CPU obviously needs to be first, otherwise nothing
else would work, and we have code that adds checks to get around this.

For example, in the page table setting code, we check to see if the
system is turned on before we even notify the CPU instances of a page
table switch. This results in dead code (at the moment), because the
only time a page table switch will occur is when the system is *not*
running, preventing the emulated CPU instances from being notified of a
page table switch in a convenient manner (technically the code path
could be taken, but we don't emulate the process creation svc handlers
yet).

This moves the threads creation into its own member function of the core
manager and restores a little order (and predictability) to our
initialization process.

Previously, in the multi-threaded cases, we'd kick off several threads
before even the main kernel process was created and ready to execute (gross!).
Now the initialization process is like so:

Initialization:
  1. Timers

  2. CPU

  3. Kernel

  4. Filesystem stuff (kind of gross, but can be amended trivially)

  5. Applet stuff (ditto in terms of being kind of gross)

  6. Main process (will be moved into the loading step in a following
                   change)

  7. Telemetry (this should be initialized last in the future).

  8. Services (4 and 5 should ideally be alongside this).

  9. GDB (gross. Uses namespace scope state. Needs to be refactored into a
          class or booted altogether).

  10. Renderer

  11. GPU (will also have its threads created in a separate step in a
           following change).

Which... isn't *ideal* per-se, however getting rid of the wonky
intertwining of CPU state initialization out of this mix gets rid of
most of the footguns when it comes to our initialization process.
2019-04-11 22:11:40 -04:00
.appveyor Implement Citra pull 3043 2018-02-24 13:08:46 +01:00
.github ISSUE_TEMPLATE: changes to make it more expressive and prevent low-quality issues 2019-01-22 21:52:59 +01:00
.travis travis/macos: Use macpack to bundle dependencies 2019-03-23 01:37:38 +01:00
CMakeModules shader/decode: Split memory and texture instructions decoding 2019-02-26 00:11:30 -03:00
dist Show game compatibility within yuzu 2018-08-29 15:42:53 +02:00
externals video_core: Add sirit as optional dependency with Vulkan 2019-04-10 14:20:25 -03:00
hooks pre-commit: Change comment from citra to yuzu 2018-03-26 21:34:19 +02:00
src core/cpu_core_manager: Create threads separately from initialization. 2019-04-11 22:11:40 -04:00
.gitattributes Meta: Add gitattributes file 2018-09-22 23:31:44 +02:00
.gitignore Port #3702 from Citra 2018-07-26 15:35:24 +02:00
.gitmodules video_core: Add sirit as optional dependency with Vulkan 2019-04-10 14:20:25 -03:00
.travis.yml travis: Bump macOS version to 10.14 2019-03-07 23:34:37 -05:00
appveyor.yml build: Copy QtWebEngineProcess[d].exe to release dir on windows 2019-01-04 10:34:29 -05:00
CMakeLists.txt fix clang-format target when using a path with spaces on windows 2019-04-07 02:10:01 +02:00
CONTRIBUTING.md CONTRIBUTING.md: migrate to the wiki 2018-11-17 17:48:40 +01:00
Doxyfile Minor cleanup 2018-01-13 23:56:18 +00:00
license.txt added license txt file 2014-04-08 19:03:00 -04:00
README.md Yuzu can render 3D. 2019-03-02 17:23:05 +01:00

yuzu emulator

Travis CI Build Status AppVeyor CI Build Status

yuzu is an experimental open-source emulator for the Nintendo Switch from the creators of Citra.

It is written in C++ with portability in mind, with builds actively maintained for Windows, Linux and macOS. The emulator is currently only useful for homebrew development and research purposes.

yuzu only emulates a subset of Switch hardware and therefore is generally only useful for running/debugging homebrew applications. At this time, yuzu cannot play any commercial games without major problems. yuzu can boot some games, to varying degrees of success.

yuzu is licensed under the GPLv2 (or any later version). Refer to the license.txt file included.

Check out our website!

For development discussion, please join us on Discord.

Development

Most of the development happens on GitHub. It's also where our central repository is hosted.

If you want to contribute please take a look at the Contributor's Guide and Developer Information. You should as well contact any of the developers on Discord in order to know about the current state of the emulator.

Building

Support

We happily accept monetary donations or donated games and hardware. Please see our donations page for more information on how you can contribute to yuzu. Any donations received will go towards things like:

  • Switch consoles to explore and reverse-engineer the hardware
  • Switch games for testing, reverse-engineering, and implementing new features
  • Web hosting and infrastructure setup
  • Software licenses (e.g. Visual Studio, IDA Pro, etc.)
  • Additional hardware (e.g. GPUs as-needed to improve rendering support, other peripherals to add support for, etc.)

We also more than gladly accept used Switch consoles, preferably ones with firmware 3.0.0 or lower! If you would like to give yours away, don't hesitate to join our Discord and talk to bunnei. You may also contact: donations@yuzu-emu.org.