Minor Edits(#244)

site/content/entry/yuzu-progress-report-dec-2020/index.md

@@ -1,9 +1,9 @@
 +++
-date = "2021-01-07T12:00:00-03:00"
+date = "2021-01-10T12:00:00-03:00"
 title = "Progress Report December 2020"
 author = "Honghoa"
 coauthor = "GoldenX86"
-forum = 0
+forum = 345724
 +++ 
 
 Happy New Year, dear yuz-ers! 2020 is finally behind us, so what better way to start 2021 than with a progress report? Follow us for a summary of the last changes yuzu saw in 2020, and a small preview of what will come. This time we offer you kernel changes, new input and user interface additions, and the first changes applied to get the Buffer Cache Rewrite finished.
@@ -71,6 +71,24 @@ A separate PR [added +/-](https://github.com/yuzu-emu/yuzu/pull/5205) to the fon
 
 Some games report the wrong device handle when sending vibration signals, like `NEKOPARA Vol. 3` (don’t Google this series). [Morph](https://github.com/Morph1984) fixed this by [validating the device handles before use.](https://github.com/yuzu-emu/yuzu/pull/5190) Man of culture.
 
+## Kernel Rewrites
+
+yuzu's kernel received important changes this month, focused on refactoring the code for thread management and synchronization. [bunnei](https://github.com/bunnei) started working on these changes two months ago, as covered on the previous progress report. Although a bit technical, these modifications are essential for accurate Nintendo Switch emulation. They also improve yuzu's code quality and make it easier to work with. There are still many changes planned for the kernel, so stay tuned for even more improvements in the very near future.
+
+First, there is an improvement to yuzu [ensuring safe memory access across threads](https://github.com/yuzu-emu/yuzu/pull/5206). A `Race Condition` happens when multiple threads are running simultaneously, and one thread modifies data while another thread accesses it. Race conditions can cause faulty or unexpected behaviour: a thread can retrieve partial data or even overwrite changes made by another. yuzu emulates the Nintendo Switch's internal memory using a type of abstract data structure called a `Page Table`, which works as a virtual layer between the physical and the emulated memory. It maps these addresses in a "contiguous table" that lets the programmer access memory easily without checking where actual memory stores everything. Most memory management operations were written before multicore CPU and asynchronous GPU were implemented. There was only a single thread back then, so there were no guards for thread-safe memory access. bunnei introduced a lock in this PR to alleviate a race condition where the data in the memory pages was being accessed while the GPU was operating on them.
+
+bunnei has also been rewriting the [kernel scheduler](https://github.com/yuzu-emu/yuzu/pull/5131). Modern operating systems run many processes simultaneously, however, a single CPU core can only process one of them at any given time. The scheduler is an essential piece of the kernel, as it is in charge of swapping CPU access to the different processes and choosing in which order this happens. This will make yuzu’s kernel match `Horizon OS` more closely.
+
+As a follow-up to this rewrite, bunnei reworked the way service calls were implemented in yuzu, by allocating their calls in their own [individual service threads](https://github.com/yuzu-emu/yuzu/pull/5208). Many services are running in the background on the Nintendo Switch. They are in charge of initializing and managing specific tasks, such as audio, graphics, user input, networking, etc. yuzu emulates these services through HLE - High Level Emulation. This means that, instead of dumping the binary code of these routines from the Nintendo Switch and translating their instructions so that a PC can run them, the programmer reimplements the functionality of these services in C++. Thus, HLE works like a "black box": these services are called whenever there's a request from the games, and they send (or ask) for the corresponding data, even though internally they may be different to how the service was originally implemented in hardware. But, as long as the information requested or sent through the service is valid and processed appropriately, the system is being emulated correctly.
+
+These service processes are independent of each other, so games call them asynchronously. But before this PR, all of these services were being processed in the `CoreTiming` thread -- a thread that is used to process events at certain times in the future (for example, when a frame completes rendering). This meant that games would call these processes, but they would not be processed until the `CoreTiming` thread was run, which resulted in these requests piling up in a queue and possibly introducing lag if the queue wasn't emptied fast enough.
+
+Thanks to the changes in this PR, each of these processes was moved to their own thread and is processed more quickly. An immediate benefit of this change is that load times improve significantly, and input lag is also reduced. But another important perk is that this implementation is more accurate, as it resembles the behaviour of services in the Nintendo Switch. GPU emulation also runs on its own thread now, which is synchronized on GPU pushes and flushes. This means that `async GPU` can be decoupled from multicore and these settings can now be toggled independently from each other.
+
+Finally, as a continuation to the previous two PRs, comes the [rewrite of the kernel synchronization primitives](https://github.com/yuzu-emu/yuzu/pull/5266) – namely, `Synchronization Objects`, `Condition Variables` and `Address Arbiters`. An in-depth explanation of how these mechanisms work goes beyond the scope of this report, but essentially they are tools used by threads in different processes to communicate with each other and be synchronized properly. The major benefit of these changes is that a lot of code that was being carried over from Citra (and that required major workarounds to make it function properly with multicore) has been changed in favour of mechanisms more appropriate for how yuzu works, besides making it closer to how the `Horizon OS` of the Nintendo Switch works.
+
+Going in hand with these synchronization changes, [epicboy](https://github.com/ameerj) introduced a PR to [incorporate a syncpoint manager for nvdec](https://github.com/yuzu-emu/yuzu/pull/5237). This utilizes the tools mentioned previously to implement a more accurate GPU-CPU synchronization mechanism. It is crucial to avoid race conditions when async operations are being performed by the emulator when decoding a video.
+
 ## UI changes
 
 Finally, a very needed User Interface change, [language support](https://github.com/yuzu-emu/yuzu/pull/5239) is here. Thanks to work done by [Tobi](https://github.com/FearlessTobi) and many, *many* members of the community from around the globe, we can now offer support for 11 different languages, plus regional variations. ¡Muchas gracias!