yuzu/yuzu-emu.github.io
1
0
Fork 0
mirror of https://github.com/yuzu-emu/yuzu-emu.github.io.git synced 2025-07-27 12:11:56 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update index.md

Browse source
This commit is contained in:
Matías Locatti 2020-12-09 16:20:57 -03:00 committed by GitHub
parent 17730ebaf2
commit f257ac7598
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
site/content/entry/yuzu-progress-report-nov-2020/index.md
View file

@ -22,7 +22,7 @@ Speaking of `Super Smash Bros. Ultimate`, these changes have also fixed a softlo
"./hero.mp4| Hero’s Final Smash (Super Smash Bros. Ultimate)"
>}}
Additionally, the stutters experienced in many games have disappeared. This includes those found while changing character costumes in SSBU and right before the world map and tutorial videos play in `Super Mario Odyssey` (the videos also play much more smoothly).
Additionally, the stutters experienced in many games have disappeared. This includes those found while changing character costumes in `Super Smash Bros. Ultimate` and right before the world map and tutorial videos play in `Super Mario Odyssey` (the videos also play much more smoothly).
{{< single-title-imgs
"World map in Super Mario Odyssey, before (left) and after (right) the changes, now stutter-free!"
@ -34,9 +34,9 @@ So, you might be wondering, what exactly is happening behind the curtains?
Computer programs, such as games, are usually written in high-level programming languages. These programs basically consist of a series of statements that will be carried out by the processor in sequential order to accomplish different tasks. The processor, however, does not understand these high-level instructions, so they are converted into a set of more elemental operations in binary called [machine code](https://en.wikipedia.org/wiki/Machine_code), which is directly compatible with the hardware of the system. The process of converting source code into machine code is called `compilation`, and this produces a file that can be loaded into memory and executed by the processor from there.
The Nintendo Switch uses an 4-core ARM-based CPU, so naturally the generated machine code of any switch game will be fully compatible with that architecture. This arises a problem, however, since yuzu was designed to run on computers using a processor with a AMD64 architecture, which is not capable of understanding these instructions. For this reason, they must be interpreted or translated from guest machine code (ARM) to host machine code (AMD64). There are different approaches to accomplish this, and yuzu does so by using [Dynarmic](https://github.com/MerryMage/dynarmic): a dynamic recompiler written by [MerryMage](https://github.com/MerryMage) that performs this translation in real time. This process, the so-called JIT Compilation, reads chunks of the program in memory, decodes the instructions, and emits the translated code so the host CPU can run it. By invoking Dynarmic, it is possible to recompile game code into machine code that runs natively on the host architecture.
The Nintendo Switch uses a 4-core ARM-based CPU, so naturally the generated machine code of any Switch game will be fully compatible with that architecture. This arises a problem, however, since yuzu was designed to run on computers using a processor with a AMD64 architecture, which is not capable of understanding these instructions. For this reason, they must be interpreted or translated from guest machine code (ARM) to host machine code (AMD64). There are different approaches to accomplish this, and yuzu does so by using [Dynarmic](https://github.com/MerryMage/dynarmic): a dynamic recompiler written by [MerryMage](https://github.com/MerryMage) that performs this translation in real time. This process, the so-called JIT Compilation, reads chunks of the program in memory, decodes the instructions, and emits the translated code so the host CPU can run it. By invoking Dynarmic, it is possible to recompile game code into machine code that runs natively on the host architecture.
Previously, yuzu would create one instance of Dynarmic per guest thread being emulated on the switch. This resulted in having multiple instances of the JIT running at the same time, which could be as many as twenty, if not more! As a consequence, a lot of resources were being wasted unnecessarily like this. But with the changes introduced in this PR, yuzu now creates only four instances of Dynarmic: one per core, which is a more efficient solution. The chart shown below compares the usage of memory among some popular titles before and after this PR was implemented; the test was performed during the internal testing phase, while yuzu was being run along Google Chrome and Discord. As it can be seen, the differences in memory usage vary between 3 GB and 6.4 GB, depending on the game. Similar results have been observed across other titles.
Previously, yuzu would create one instance of Dynarmic per guest thread being emulated on the Switch. This resulted in having multiple instances of the JIT running at the same time, which could be as many as twenty, if not more! As a consequence, a lot of resources were being wasted unnecessarily like this. But with the changes introduced in this PR, yuzu now creates only four instances of Dynarmic: one per core, which is a more efficient solution. The chart shown below compares the usage of memory among some popular titles before and after this PR was implemented; the test was performed during the internal testing phase, while yuzu was being run along Google Chrome and Discord. As it can be seen, the differences in memory usage vary between 3 GB and 6.4 GB, depending on the game. Similar results have been observed across other titles.
{{< imgs
"./memgraph.png| Memory usage before and after implementing 4-JITs"