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:
Honghoa 2020-12-09 15:47:46 -03:00 committed by GitHub
parent 8049b670aa
commit 17730ebaf2
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -14,7 +14,7 @@ Salutations, yuz-ers! This is the November progress rreport which, for an unlimi
[bunnei](https://github.com/bunnei) and [Blinkhawk](https://github.com/FernandoS27) have been taking a look at yuzu's implementation of the kernel, searching for bugs or code that could be refactored — that is to say, rewritten to gain performance or make it easier to read, without changing the core functionality.
[4-JIT, or 4 instances of Dynarmic,](https://github.com/yuzu-emu/yuzu/pull/4996) focuses on modifying how the JIT (Just-in-time) Compiler, an elemental tool to emulate the Nintendo Switch's CPU, is being used in yuzu. These changes greatly benefit the user, since they will mitigate the need to set up a huge pagefile for the emulator: Now, defaulting the pagefile size to `auto` should be sufficient, although some games, like `Super Smash Bros. Ultimate`, might still need a pagefile with a more reasonable size due to the sheer amount of resources being allocated; to cover these worst-case scenarios, the user can set the pagefile size to 10000MB, if they wish to do so.
[This kernel refactor PR](https://github.com/yuzu-emu/yuzu/pull/4996) focuses on modifying how the JIT (Just-in-time) compiler, an essential tool to emulate the Nintendo Switch's CPU, is being used in yuzu. These changes greatly benefit the user since they will mitigate the need to set up a huge pagefile for the emulator. Setting the default pagefile size to `auto` should now be sufficient, although some games, like `Super Smash Bros. Ultimate`, might still need a pagefile with a more reasonable size due to the sheer amount of resources being allocated. Users may want to set the pagefile size to 10000MB to cover these worst-case scenarios.
Speaking of `Super Smash Bros. Ultimate`, these changes have also fixed a softlock that occurred quite frequently when the Final Smash of the DLC character “Hero” was used. You can now freely kick your opponents off the screen with all your might without needing to hold your breath and cross your fingers.
@ -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 when changing character costumes in Super Smash Bros. Ultimate, as well as other stutters that occurred in many games, like the performance drop that happened right before the world map and tutorial videos play in `Super Mario Odyssey`, have disappeared. 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 SSBU 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!"
@ -30,11 +30,11 @@ Additionally, the stutters experienced when changing character costumes in Super
"./smofix.mp4"
>}}
So, you might be wondering, what's exactly happening behind the curtains?
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; they 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.
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 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 an 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 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.
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.