yuzu on yuzu

Progress Report January 2024

GoldenX86 — Sat, 10 Feb 2024 12:00:00 -0300

Welcome to 2024, yuz-ers! What better way to begin the year than to do major code refactors resulting in almost full applet support. We present this, and plenty more, to you today! Remember to right click and unmute the embedded videos.

Multiprocess, services, LLE applets, and Project Leviathan

Converting a single process emulator into a multiprocess one is no simple task.

Typing speed challenge with the Nintendo keyboard?

2024 started out quite busy thanks to the combined efforts of byte[], german77, Blinkhawk, and Maide in implementing multiprocess support, taking advantage of it in multiple areas (heh, get it?) including GPU, input, services, and applet emulation, and fixing long standing problems along the way.

As of writing, multiprocess support is not yet merged, but fixes in the GPU, input, and other modules (implemented by byte[], Blinkhawk, and german77) have already been staged and released, allowing full support to be added in parts.

Implementing the requirements to support multiprocess in yuzu led us to make five significant changes in the past month:

Allow the GPU to run multiple programs. This is where SMMU support comes in, which we will discuss in the next section.
Rewrite the old, basic applet manager.
Rewrite presentation. Part of the prerequisites to run more than one program simultaneously is to be able to display all of them to the user.
Rewrite every other relevant area (for example, input) to support multiple processes.
Automate the serialization of service calls.

Device mapping and SMMU

We start off with a big one: Blinkhawk implemented device memory mapping emulation and rewrote the GPU implementation with support for the SMMU, or for desktop enthusiasts/Linux VM users/UEFI lurkers, its other common name, IOMMU.

The ARM System Memory Management Unit handles memory mapping for peripheral devices like the GPU. It’s a hardware component on the Switch in charge of translating device virtual memory addresses into physical memory addresses. The GPU adds an MMU of its own, GMMU, an additional layer that maps over the SMMU.

The emulator already had a performant memory translation layer for the GMMU, but it could only handle a single program using the GPU at a time, unable to share it with other processes. And support for multiple processes was needed.

The main benefits of this rewrite are:

Increased accuracy.
Reduced video memory usage (testing shows around a 300MB reduction).
Enables multiprocess use of the GPU.
Allows other emulated devices to use the device mapper.
Leaves room for potential future optimizations

One downside of this change was how it increased debugging complexity, which led to more development time spent with every bug found on its implementation. For example, games on Android getting stuck at 0 FPS randomly, breaking compatibility with NCE, or running out of memory on some game engines. This led to a couple of fixes implemented first by byte[] and then Blinkhawk himself, with more on the way.

This change opened the floodgates to applet emulation and is the starting point to implement Direct Memory Import sometime in the future — but let’s slow down a bit, there’s more to cover.

Your browser doesn't support mp4 video. :(

Time to launch another program, GPU!

Project Leviathan

german77 had to adapt his input rewrite, Project Leviathan to the requirements of multiprocess too. The rewrite is still ongoing, with more parts planned. But just in January, the following changes, either specifically for multiprocess or more generally as part of the rewrite, were implemented:

Use individual applet resources, so each applet has its own view of the controller input.
Implement NpadResource emulation, now using the input process ID to distinguish HID state and controller style configuration between multiple processes.
Create the abstracted pad structure, which is in charge of updating the shared memory and assignment of controllers. The old implementation was too simple, causing the controller applet to unnecessarily be shown, or showing up with no supported controllers available.
Fully implement abstract vibration, removing old inaccurate code and matching the behaviour of newer Switch firmware.

While this leads to us being able to load the native controller applet (among others) and have fun with it, it doesn’t have much use for emulation.

Just for fun

Now Presenting

Besides the emulated GPU, presentation to screen also needed some work to support running applets — without it, none of the benefits could actually be displayed. If there is no multi-layer composition in place, there is no applet fun.

byte[] rewrote almost all of the presentation code to support layer overlays and blending, taking special care to not break the existing filtering and antialiasing options. FSR in particular was converted from a compute shader to a fragment shader, so proper blending could be enabled. The end result is the same, with no image quality changes — but now FSR can be used while games display the native inline keyboard, for example.

Your browser doesn't support mp4 video. :(

That transparency behind the keyboard wasn’t free.

I AM the applet manager

Another critical service that required a rewrite to have proper multiprocess support is AM, the Applet Manager. AM has now been almost completely refactored to track state for every applet individually, properly allowing it to support running more than one at the same time.

Your browser doesn't support mp4 video. :(

Help is only one button press away (Super Smash Bros. Ultimate)

While byte[] got the rewrite up and running, german77 fixed an issue causing The Battle Cats Unite to softlock past the starting loading screen.

This is one of the games of all time. Nyaa. (The Battle Cats Unite)

Sounds good

Maide was responsible for making audio emulation compatible with multiprocess. Games should be able to share audio playback with applets, right? Sharing is caring.

Your browser doesn't support mp4 video. :(

Special menus included (Super Mario 3D All-Stars).

Universal Serialization Byte[]

The serialization and deserialization of service calls from programs is one of the most important tasks yuzu must perform when interacting with guest programs. Communication between programs and the Switch system modules uses a special binary format with custom parsers. Interacting with guest processes required tedious and error-prone layout calculations for every single interface method yuzu needed to implement, wasting a lot of development time on error checking and maintenance.

With the increased involvement in service implementations and the exponential growth of complexity you’ve seen so far, byte[] aims to automate and simplify serialization by using a template-based approach that automatically generates the code needed for the method.

So far, the work on multiprocess has taken over twenty thousands lines of code and continues growing. All you have to do now to enjoy your native applets is to dump your firmware. The minimum required version to get the applets running is firmware 14.0.0.

Other service rewrites and fixes

Here’s a toast to Maide for fixing one of the longest standing bugs in yuzu: the passage of time in games like Pokémon Sword/Shield and Pokémon Quest.

In the past, while time tracked during saving, some game events like Dens or Pokéjobs wouldn’t reset, forcing users to manually advance time with the custom RTC option. It was quite bothersome.

It took an entire rewrite of the time services to resolve the issue, “only” about nine thousand lines of code. The new implementation is much more accurate, allowing Pokéjobs and other timed events to finally be enjoyed normally in this low-poly, almost-always-30-FPS masterpiece.

Get to work! (Pokémon Sword)

Continuing this work, Maide removed some old workarounds that were no longer needed in the time services, and fixed network clock to local clock synchronisation on every game boot. This fixed time progression in Pokémon Quest. No longer a Time Quest.

Set camp (Pokémon Quest)

To close the section, byte[] fixed how the AOC service lists available DLC for multi-program applications, allowing Assassin’s Creed Rogue to boot with its DLC installed. Just like the Navy intended.

Graphics changes

A dose of Dozen

Unforeseen issues are one of the signature “comes with the job” moments of emulation — you never know from where a new problem will arise, so we’ll have to start this section with a PSA.

PSA: If yuzu has recently started showing Microsoft as the GPU vendor for you, and you can no longer play any game, uninstall the package named OpenCL™, OpenGL®, and Vulkan® Compatibility Pack, or if you prefer to keep it, go to Emulation > Configure… > Graphics > Device and change the GPU to your correct model, without “Microsoft Direct3D 12” at the start of its name.

AMD and Intel users running Windows 11 suddenly started having their hardware completely incapable of launching any games while using Vulkan. The reason is something none of us expected at all, Microsoft… And Mesa! Please lower those pitchforks.

Microsoft decided to roll out an install of this package, which allows incapable hardware to run the mentioned APIs if no proper driver was provided from the hardware vendor, or just if the hardware is incapable of running it.

The project used to achieve this is Mesa Dozen, which runs Vulkan atop a Direct3D 12 interface. The intended purpose is to offer Vulkan support to devices that only ship a Direct3D 12 driver, for example, Qualcomm ARM laptops. We don’t know why Microsoft decided to silently test this feature on x86-64 PCs that already ship hardware capable of proper Vulkan support, but here we are.

Those new devices generated by Dozen are added to the Vulkan devices available to the OS, named “Microsoft Direct3D 12 (GPU model name)”, and conflict with how yuzu orders its device list.

To ensure the best GPU is selected by default on yuzu, three sorts are performed in order:

Prefer NVIDIA hardware over AMD, AMD hardware over Intel. This favours NVIDIA hardware and also double ensures dedicated GPUs get selected over integrated ones. Plus, in the rare case a user has multiple GPUs from different vendors on a system, we ensure the one with the least issues is picked by default. “Outdated NVIDIA tablet-turned-console likes NVIDIA drivers,” after all.
Prefer dedicated hardware over any other, including integrated and CPU rendering. There are people out there trying to run yuzu with CPU rendering.
Order in inverse alphabetical order. This helps ensure an RTX 4090 is picked over a GTX 1050, or an RX 7900 XTX over an RX 780m.

Did you notice it? The last point is the problem. Dozen devices share the same identical features as the real Vulkan device but change the name. Since the list is ordered in inverse alphabetical order, a device named “Microsoft” will take priority over an identical one named AMD or Intel.

The issue is simple enough to solve: detect when a device is Dozen and demote it to the bottom of the list. Even if Dozen was capable of running yuzu, we would prefer not to run a layered implementation by default.

Nice way of having a Dozen GPUs

Sadly, Dozen isn’t compatible with yuzu for the moment — it lacks multiple mandatory extensions and has some issues your writer enjoyed reporting to its devs while testing this. Fixes for multiple of them arrived in just a couple of days. Mesa devs are built differently.

This could be an interesting experiment for Fermi users or other end-of-life hardware once Dozen is suitable for yuzu.

Your regularly scheduled GPU changes

The fun testing for multiprocess revealed a graphical issue when opening the web applet help page in Super Smash Bros. Ultimate. One fix for pitch linear reading and writing in the software blitter code later, and Blinkhawk resolved the issue.

Da Rules (Super Smash Bros. Ultimate)

Android users have regularly reminded us that Mortal Kombat 11 is unable to boot. After his enthusiastic walk through the code, byte[] found that 8-bit and 16-bit storage writes in shaders were completely broken on hardware which did not support them.

The problem, at least one of them, was lack of hardware support for shaderInt8 and shaderInt16, something the big three, NVIDIA (the Switch included, of course), AMD (and by extension, Xclipse), and Intel, have full support for with up-to-date drivers, but Android devices with Adreno and Mali GPUs don’t.

Mali moment #1, along with Adreno.

The solution byte[] implemented to solve this specific issue is the usual for the lack of hardware support. If you can’t run it, emulate it! Those are very enthusiastic walks. These platforms support storage atomics, so by performing a compare-and-swap loop to atomically (in the thread safety sense, not radioactive) write a value to a memory location, 8-bit and 16-bit values can be written to larger 32-bit memory words without tearing the value seen by other threads.

Dear gods, you don’t need to make the menu low resolution too (Mortal Kombat 11)

This emulation incurs a small performance loss, but beggars can’t be choosers. Mobile GPUs are very stingy with their feature sets, which frequently holds our development back and necessitates adding workarounds.

We doubt only Mortal Kombat 11 is affected — this change improved many unknown games that were crashing on Android devices or for people running outdated GPU drivers on desktop/laptop PCs. Sadly, this change alone isn’t enough to make the game playable on Android devices. This issue exposed other shader problems related to lack of support for StorageImageExtendedFormats, but that’s homework for later, most likely for future byte[].

Switching to the other Linux kernel equipped OS (erm, Linux), Tuxusers reported garbled rendering issues when resizing the yuzu window while on Wayland.

The solution was thankfully simple, reverting an unnecessary change in one of the previous DMA fixes. By forcing a recreation of the swapchain each time the window frame size changes, the issue is gone.

Proper tear-free gameplay with safe window management shall return to Wayland. HDR support when, Linux?

Newcomer shinra-electric updated the MoltenVK dependency to its latest version. Thank you!

While the update brings tons of improvements and many Vulkan extensions are now supported, there are no new changes to report in rendering or compatibility on Apple devices. But hey, no reported regressions is good news!

Android augmentations

t895 kicked off the new year with a flurry of changes to improve yuzu Android. While one of these changes enhances the overall app performance, the majority are quality-of-life (QoL) fixes that some of our users have been anticipating.

As many of you might already be aware, yuzu Android supports exporting user data and saves in ZIP format to transfer between different versions of the app. ZIP compression, in most cases, can result in a reduction of file size compared to the original size of files on disk. However, applying compression overtop of encrypted data is almost always a waste of time.

t895 observed that when compression was turned on, these ZIP exports were excessively slow, while still resulting in negligible size reduction gains, as the largest files in the user data are NCAs, and those are encrypted. Therefore, he disabled compression for these ZIP exports, exhibiting up to a 3x decrease in export times.

Moving on to the QoL fixes, t895 extended support for custom screen orientations. With this change, yuzu now supports a total of seven orientation styles, listed below.

Auto. Selects any of the four orientations based on the phone’s sensor.
Sensor Landscape. Limits the sensor detection to only landscape orientations.
Landscape. Fixed regular landscape.
Reverse Landscape. Fixed inverted landscape.
Sensor Portrait. Limits the sensor detection to only portrait orientations, if the device allows it.
Portrait. Fixed regular portrait.
Reverse Portrait. Fixed inverted portrait

Reverse portrait, the way it’s meant to be played

Next up is the improved global save manager. There are two possible save directories for games, and the original global save manager was only checking one of them. So, t895 removed this broken feature a while back and has now reintroduced an improved version of the same.

With this improved version, you can now also use exports made with the global save manager in the per-game save manager and vice versa.

Following that are the new uninstall add-on buttons. t895 added an uninstall button for every kind of add-on in the Android app. yuzers can now easily uninstall any updates, DLCs, mods, and cheats that they might have installed. Note: Currently, yuzu on PC doesn’t have UI support for uninstalling mods or cheats.

Your internal storage starts breathing again

Ever spend a long time copying over your dumps or installing content to NAND, only to have them fail to work? Look no further: t895 brings the PC version’s integrity check features to Android. You can now easily verify the file integrity of your game dumps and your NAND contents. To verify a game dump, simply go to your game’s properties and under Info, select Verify Integrity. There is also a separate, self-explanatory button within Settings labelled Verify Installed Content.

Great for peace of mind after experiencing a game crash

How many times have you accidentally opened the in-game menu when using the left thumbstick area? Well, you can now lock the in-game menu so as to avoid accidentally triggering it. When locked, you can still bring up the in-game menu by using the “back” button or gesture on your device.

Anti-frustration changes

Now, let’s delve into game shortcuts on your home screen. With Android’s dynamic shortcuts feature, apps can now provide users with quick access to specific actions or content within an app directly from the home screen. Although this feature was introduced back in 2016, it seems that some Android launchers do not yet support it.

While this feature is already supported on yuzu and works perfectly, it becomes pretty tedious when you have to launch each and every game to get a shortcut for it, especially after a reinstall. As a one-size-fits-all solution to this problem, t895 implemented a button in the game properties activity that allows you to easily add a shortcut to any game to your home screen without needing to launch the game first.

Gotta pin ’em all

t895 followed that up with some controller focus optimizations. Android controller focus is the highlight you see over buttons indicating that you can select it. These changes fix a few issues observed when using a controller to navigate the yuzu app UI and solved an issue where the emulation surface would appear gray.

In his quest to bring feature parity between yuzu on PC and yuzu on Android, t895 implemented the ’encryption keys missing’ warning on Android. You will now get this warning on app startup if you don’t have the keys required to decrypt games/firmware.

Time to grab that jig

t895 also implemented support for multi-program app switching. This feature allows for game compilations like Super Mario 3D All-Stars and Klonoa: Phantasy Reverie Series to switch between games within the bundle.

Your browser doesn't support mp4 video. :(

Multi-game drifting! (Klonoa: Phantasy Reverie Series)

He also made some minor UI improvements like:

Show driver vendor in the FPS overlay. This informs users which driver is loaded.
Show System GPU driver information in the driver manager for improved visibility.

Now you can know how outdated it is

And that’s not all. Newcomer Emma implemented basic support for the game dashboard feature found on Pixel devices. Thank you!

Resident AMD tester Moonlacer noticed that Samsung mobile devices with the new RDNA-based Xclipse GPUs had the same wireframe issues in various Pokémon games, that plague the PC AMD Vulkan drivers. With some help from byte[], a fix for these Xclipse GPU drivers was implemented by considering these devices as AMD, gaining access to the same old workarounds Radeon cards benefit from. Thanks to user no.kola on discord for testing these!

Xclipse moment #1. We have some bad news for Xclipse users we’ll discuss in the hardware section.

Miscellaneous changes

One notable standing issue with yuzu is profile corruption, when after a badly-timed crash, the emulator creates a new profile and leaves all user data in the old one, forcing the user to manually move their saves back to the newly created active profile. Thankfully, german77 fixes user profile corruption issues by only saving profile data when contents change.

While NCE has been with us for some time now, that doesn’t mean it’s entirely stable yet. As an Android user pointed out, some hardcore mods like Luminescent Platinum for Pokémon Brilliant Diamond/Shining Pearl would get stuck in a black screen while using NCE.

After the detective work was finished by byte[], the reason was found to be in how some mods make assumptions about the module layout, and yuzu would try to give each module a dedicated patch section. To alleviate this bottleneck, GPUCode modified the NCE loader to try to use the same patch section for as many sequential modules as possible.

The community never fails to provide impressive mods (Pokémon Brilliant Diamond)

This should allow mods for other games that make assumptions about module layout to work under NCE as well.

Jumping to a bit of input changes, german77 was notified that a user tried to dump their Amiibos, but yuzu failed to generate any dump because the Amiibos were mounted as read-only and no backup was available. The solution? Dump Amiibos if no backup exists, no questions asked.

Resident helper anpilley decided it was time to improve the available command-line arguments for the yuzu binaries, adding the use of -u to specify a user to load and suppress the user selector from showing. Thank you!

Back for more, FearlessTobi decides to tackle a few problems with the virtual file system emulation, or VFS. Since Project Gaia is in indefinite hiatus, priorities have shifted into patching as much of the current implementation as possible.

The list of changes is long: it includes moving files, unifying error code naming for ease of debugging, making file system definitions more consistent with current reverse engineering information available, and leaving the overall structure prepared for future code additions. Never hurts to improve an area that was designed back when there was little information available.

The boss of Dynarmic herself, merryhime, updated the bundled build in yuzu to the latest version, bringing some new changes and fixes with it. There are some instruction emulation optimizations, more 32-bit ARM instructions were added, and the startup times of games on Android was improved — it’s not as fast as NCE, but it’s considerably faster for those games that must run on JIT.

To close this section and move to an interesting hardware discussion, t895 has one last gift for us this month, per-game audio settings. One of the missing settings that could be set on a per-game basis, and it includes the full set, output engine, output device, input device, etc.

Sounds good to me!

The more you’re able to choose, the better, right?

Hardware and software section

As promised last month, we’ll talk about frame generation, and the new tools available to take advantage of it in yuzu. But first, one last HDR example for NVIDIA users.

NVIDIA TrueHDR

With the 551.XX series of drivers, NVIDIA introduced the option to auto-generate an HDR output for any video displayed on a Chromium-based browser (Google Chrome, Microsoft Edge, Brave, etc). It didn’t take long for the community to come up with plug-ins to take advantage of this change in local video players, but that’s not the only application outside NVIDIA’s official intended use.

Enter NvTrueHDR, an alternative to Windows AutoHDR and Special K HDR. Always fun to have more options to pick from!

Lossless Scaling to the rescue

Lossless Scaling, a program intended for resolution scaling, recently introduced a generic frame generation option, making it the first vendor agnostic implementation.

Clean UI

Simply set Frame Generation on the right to LSFG. If you’re an Intel iGPU user, set Legacy capture API to enabled, open yuzu, enable Scale, and switch back to playing your game, or press the default hotkey Ctrl + Alt + S while in-game. Exclusive fullscreen is recommended.

Scroll down to find it

The results are good on smaller displays, but on larger monitors (such as 27 inch displays), the artifacts of the generated frames are too noticeable, making this tool more suitable for laptops and handhelds than for desktop or TV gameplay. Still, it’s a cheap way of improving perceived framerates and bypassing CPU bottlenecks on any GPU vendor without driver or hardware restrictions.

Below you can see comparison videos between native 30 FPS and Lossless Scaling generating frames to 60 FPS in The Legend of Zelda: Breath of the Wild. Due to YouTube only supporting 60FPS video, you won’t see the true 120 FPS framegen examples.

The above videos demonstrate native 30 FPS vs Lossless Scaling generating frames from a 30 FPS base. You can see with so little information, artifacts are common. Lossless Scaling doesn’t handle scene transitions.

The above videos demonstrate native 60 FPS vs Lossless Scaling generating frames from a 60 FPS base. With more information to play with, Lossless Scaling does a better job. Scene transitions are still an issue.

While the quality is not perfect, it’s a simple and harmless way of improving the experience on any hardware — especially on ~~ugly~~ 30 FPS games like the Pokémon series, or cinematic experiences like the Xenoblade saga. No double standards here. Still, for those with recent AMD GPUs (RDNA2 and RDNA3 so far), there’s a better option available now:

AMD Fluid Motion Frames

Driver release 24.1.1 introduced the first public release of AFMF, AMD’s game-independent frame generation algorithm.

“But writer, AFMF is only for Direct3D 11 and 12 games!” you say. That’s where you’re wrong. You see, the Guru3D forums has some fantastic information, AFMF can be run on Vulkan, OpenGL, and Direct3D 9/10 too, it only needs a registry edit:

[HKEY_LOCAL_MACHINE\SOFTWARE\AMD\DVR]
"GFGEnableAPI"=dword:00000007

Manually make this change with regedit, reboot Windows if needed, add yuzu to the Radeon Software, set Wait for Vertical Refresh to Disabled, enable AMD Fluid Motion Frames:

Good looking UI, AMD

In the performance tab, you can set the overlay to show the generated frames’ performance (it won’t show up on regular apps or yuzu, as it isn’t informed by the game engine), along with latency and stuttering.

Open yuzu, set Fullscreen Mode to Exclusive Fullscreen:

It’s as shrimple as that

And that’s it, start a game, go into fullscreen by pressing F11 or the hotkey assigned to your controller, and enjoy 2x to 3x the perceived framerate.

Note that, while the image quality is much better than the result from Lossless Scaling, AMD disables AFMF if there is too much variance between one frame and the next in order to avoid smoothing out scene transitions like camera changes or opening the menu. This leads to a noticeable frametime inconsistency when a lot of action is happening on screen. We hope AMD adds an option in the future to toggle the sensitivity of this behaviour.

The above videos demonstrate native 30 FPS vs AFMF generating frames from a 30 FPS base. While a better result than Lossless Scaling at 30 FPS, artifacts are still noticeable in faster movements, especially on vegetation. Scene transitions are clear and there is less shimmering around the player.

The above videos demonstrate native 60 FPS vs AFMF generating frames from a 60 FPS base. And at 60 FPS, the results are great! Allowing for smoother gameplay on 120-180Hz displays.

No performance graphs are included because your writer doesn’t consider perceived framerate as real performance, but to provide an example, The Legend of Zelda: Tears of the Kingdom, which produces solid 60 FPS in open world with a 5600X and an RTX 3060 Ti, can produce 170-180 “FPS” with AFMF enabled, and with little to no distortion visible.

The games can be rendered with an NVIDIA or Intel GPU while still generating frames with AFMF, although the experience is slightly worse than just using the AMD card directly due to the added latency of transmitting the finished frames over PCIe. The only requisite for AFMF to work is to have the display connected to the compatible AMD GPU, any other GPU can do the actual rendering after that. Time to invest in an RX 6400? Smash must look amazing at 240 FPS.

Intel delivering on its promises

As promised, Intel fixed their crashes while building geometry shaders, starting with driver version 31.0.101.5186/5234.

While this allows for games like Xenoblade Chronicles 3 to finally get in-game on integrated GPUs and ARC dedicated cards, it seems like there are other areas where the driver needs to mature to produce proper rendering:

Intel moment (Xenoblade Chronicles 3)

On the flip side, The Legend of Zelda: Tears of the Kingdom improved stability with this driver fix, so Intel Windows specific rendering issues aside, the game should be quite playable now.

Qualcomm

K11MCH1’s driver releases continue to flow out, improving performance and compatibility for Adreno users. We strongly recommend staying up-to-date.

While there have been new releases of the proprietary driver, nothing of value has been added or fixed yet.

Total Adreno moments count this month: 1.

Exynos and Mali

Why together? Because we found some interesting limitations in the Exynos hardware that reminds us of the existential crisis Mali suffers. Besides the AMD specific issue we previously mentioned, Exynos’ Xclipse GPU series shares a quality with Mali: total lack of support for BC4 to BC7 texture decoding.

While this is fine for native Android games (developers just have to scratch their head at the decision to skip basic texture support, and use an alternative like ASTC), Switch games do use BCn textures, extensively in some cases, and adding the extra CPU work of having to decode those textures into something the GPU can handle (RGBA8) will limit performance and increase memory usage. This is one of the main reasons these GPUs are not on par with Adreno in terms of feature support.

So:

Total Xclipse moments count this month: 2.

Total Mali moments count this month: 2.

Linux

Certain distributions like SteamOS, Fedora since version 39, and any distro with a linux-zen package available (Arch Linux for example), have significantly increased their default vm.max_map_count values, leading to much more stable out-of-box experiences when running Unreal engine games on yuzu.

Progress feels so good! You could learn a little, Windows.

Future projects

Work on multiprocess support is far from over. We’re aiming to support QLaunch, meaning being able to boot the native game launcher, launch games from there, close them, suspend them, launch a different game, the whole deal.

Your browser doesn't support mp4 video. :(

QLaunching in 3, 2, 1!

Resuming a game works too.

Your browser doesn't support mp4 video. :(

Back and forth.

The work on applets and multiprocess is exposing a lot of hidden bugs in multiple areas — the accuracy improvements are a very welcome addition; we’re having so much fun testing and running the applets.

That’s all folks! Thank you for reaching the end of this progress report. We hope to see you next time!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report December 2023

GoldenX86 — Wed, 10 Jan 2024 12:00:00 -0300

Happy New Year, yuz-ers! We say goodbye to 2023 with several great changes, ranging from driver fixes to big memory savings, and quite a bit in between! Let’s go.

Graphics changes and driver fixes

Vulkan

Drivers are fantastical creatures. They love to exhibit major behavioural changes while still following the Vulkan specification — or more correctly for this issue, the SPIR-V specification.

Such was the case with NVIDIA drivers. Since the release of the 540 branch back in September, users have reported sudden crashes when building specific shaders in games, the most common example being some cutscenes and scenarios in Bayonetta 3. However, the problem extended to many other games in unexpected places.

After investigating the issue, your writer and byte[] came to the conclusion that the problem was not the drivers, but a miscompilation in yuzu’s shader compiler for texture gradient operations.

Pesky shaders, why don’t we just make them disappear? Well, if you like your games displaying anything besides a black out, you want them, all of them.

In some cases, yuzu would incorrectly (and unintentionally) fetch the gradient derivatives as integers (U32), when they were intended to be reinterpreted bitwise as floats (F32). While older drivers would implicitly reinterpret when using the wrong type, the 540 driver series will throw a proper shader validation error, which is the correct behaviour for a bug like this.

This meant that if a user with any NVIDIA GPU loaded a pipeline cache with the affected shader after updating to a 540 series driver, or reached a moment where a new affected shader would be built, the game would crash. At the same time, if the user reverted the driver to the older 536/537 series drivers, the same cache would work fine.

Culprit found (it was us the whole time), sentence dictated: texture gradient operations will now enforce F32 types on derivatives to comply with the SPIR-V specification. Now games don’t have to crash, users can keep their drivers up to date, and your writer sleeps peacefully at night knowing this is resolved. Anyone using an NVIDIA GPU, regardless of operating system, feel free to update to the latest release for your platform.

Magical Infernal Ladies Fighting (Bayonetta 3)

Android users have a knack for finding bugs, partially thanks to the different set of default settings we use for the small screen. Handheld mode, for example, is selected by default to improve performance (Mali users appreciate this substantially) and save a tiny bit of RAM, but hey, we’re not in the Android section yet!

Fight'N Rage, a fantastic beat’em up, had its screen cut in half in handheld mode, something most desktop users missed since it runs fine in docked mode. The issue was — and this is a classic for sprite games by now — in how swizzle and window origin adjustments were being handled. Viewport transform and window origin mode are handled separately in the GPU, so splitting the two jobs is what doctor byte[] ordered. Feel free to smash that attack button now.

Quite a big difference (Fight'N Rage)

Guess who’s back. A game that is special in many aspects, an emulator itself, one of the few native Vulkan titles on the Switch, a game that is even out of print in an era of digital releases, and the reason byte[] started contributing to yuzu.

That’s right, Super Mario 3D All-Stars is back in a report, this time addressing one of its remaining interesting quirks: the incredibly slow performance of its intro video on non-NVIDIA and non-Mesa drivers.

The quirkiness was the result of the game causing yuzu to continuously recreate its swapchain on every single frame. A swapchain is a set of framebuffer images used by the graphics API and the GPU to draw to the screen.

The game used one of its framebuffer images as sRGB during startup, which caused yuzu to detect it as sRGB. The other framebuffer image was only used as linear. Since yuzu tries to respect the colorspace of the output image, this problem was causing yuzu to incorrectly think it needed to recreate the swapchain on every single frame. This constant, per-frame swapchain recreation is not that expensive on NVIDIA and Mesa drivers, but anything else (Intel, AMD, Android drivers) can spend as much as 30ms processing this switching. That’s around 30 FPS lost in a game supposed to render at 60!

How do we avoid this? Well, Vulkan always interprets any framebuffer currently being presented to screen as sRGB, so replacing the frame with a non-sRGB one is just adding unnecessary additional work and pissing off several drivers. Changing the logic to ignore sRGB in framebuffer images provides smooth frametimes for users of these drivers.

What does Mario do with that many stars? Not sing Peaches I hope (Super Mario 3D All-Stars)

On a related note, let’s talk about presentation limits and how they affect asynchronous presentation, which moves presenting to the screen to a different CPU thread.

Due to several factors, yuzu’s Vulkan renderer could only process up to 6 frames at a time. While this isn’t normally an issue on desktop, especially for users that don’t enable Asynchronous Presentation (available in Emulation > Configure… > Graphics > Advanced), Android, a platform that demands always using asynchronous presentation, showed us that low enough performance with the setting toggled on, regardless of OS or platform, can cause the queue of swapchain images to grow beyond the limit of 6 frames. Thus, leading to a driver crash and your progress being lost. Ouch.

Feel free to test enabling it now

Android users found a workaround to this very early on: lowering the game speed limit under 100%, which slowed down the presentation rate, thereby usually keeping yuzu under the 6 frame limit.

While that technically worked, the idea is to run games at least at 100% speed whenever possible, right?

The easy solution byte[] found for this problem after identifying it was to force the presentation process to wait before reaching the limit, improving stability substantially on low-end hardware, including Android devices, while also improving input lag! Now asynchronous presentation is safe to use, improves frametimes, reduces input latency, and does your laundry! That’s a solid win for everyone.

Enough about presentation, let’s talk about clip distance instead now. I can hear you asking in the back, “what the living Koopa Castle is a clip distance?”

Most GPUs allow shaders to set up custom clipping planes for vertex data, which allows the GPU to cut geometry invisible to the viewport with no extra triangles generated or rendering cost. The members of gl_ClipDistance, a global variable and float array declared in the shader, represent the distance to the clipping plane on each vertex.

Many games use these values, including Red Dead Redemption, Fire Emblem Warriors: Three Hopes, DEAD OR ALIVE Xtreme 3 Scarlet, Hyrule Warriors: Definitive Edition, and Portal. Weird group, isn’t it? A cowboy, a skimpy Japanese fighter, two medieval warriors, and a Companion Cube walk into a bar…

On most desktop drivers, the default values for all global variables will be zero implicitly. However, SPIR-V says that these values are actually undefined. This assumption broke rendering in Portal on the radv Mesa driver ― for clip distances specifically.

byte[]’s first fix attempted to only declare an array of clip distances as large as actually needed, which would prevent any undefined values from persisting in the array. While some shaders (like those used in Portal) write directly to the clip distance array values, others (like in Red Dead Redemption) use a loop variable to access the array. Thus, the first fix attempt resulted in declaring an array of zero clip distances in those games, which is illegal in SPIR-V.

Emulation, when The Void does indeed stare back (DEAD OR ALIVE Xtreme 3 Scarlet)

After revisiting the issue, byte[] implemented a more robust solution: when clip distances are used, always declare an array of as many clip distances as the host driver supports, and use a default value to ensure the array members are all set to zero, avoiding any undefined behaviour. All drivers except Mali support eight clip distances; Mali supports zero, so a special case had to be made for this driver. Mali moment #1.

This was a triumph

GPUs often work with texture data in a variety of formats. Among the parameters used by compressed textures like ASTC and BCn is pitch, which is the size of one row of compressed blocks. This eventually gets divided by the block size of the texture by the emulator, giving the number of blocks per row. This worked flawlessly for linear 1x1 block-sized uncompressed textures, but broke compressed ones that have larger block sizes. Vulkan expects the pitch to be the number of texels (the minimum unit of a texture map, think of pixels but for textures) per row, plus some padding, but yuzu was calculating the value incorrectly.

A new tournament begins (THE KING OF FIGHTERS XIII GLOBAL MATCH)

Fixing the buffer row length, and, while at it, tuning the software BCn decoder Mali needs (Mali moment #2), is how GPUCode fixed the rendering of THE KING OF FIGHTERS XIII GLOBAL MATCH and the Eatsa Pizza minigame from Mario Party Superstars.

Your writer is old enough to remember playing this on the Nintendo 64 (Mario Party Superstars)

That ends the Vulkan section, so what’s left is to follow up with the:

And you can’t prove Khronos wrong

OpenGL

Because epicboy won’t let the old API rest.

One remaining issue (of many) for the OG open API was a bug with the shadows of Metroid Prime Remastered. By bringing the counter query accuracy, which was first seen in Vulkan, to OpenGL, this issue is now solved.

SPAAAAACE (Metroid Prime Remastered)

OpenGL users saw another win with the implementation of two fixes for Xenoblade Chronicles 3. This is particularly important for AMD users, Windows or Linux, since most AMD GPUs can’t avoid vertex explosions while running the game with Vulkan in the Pentelas region of the main story, and the DLC, Future Redeemed.

First, by implementing the DrawTransformFeedback macro, which is the OpenGL equivalent of Vulkan’s DrawIndirectByteCount, particles were fixed.

Your browser doesn't support mp4 video. :(

Remember the Game Awards flute guy? (Xenoblade Chronicles 3)

And second, a lesson of how a simple typo can cause havoc, fixing the transform feedback binding from strides to sizes stopped the grass in the game from becoming some space demon abomination.

That experiment really went wrong, Dr. (Xenoblade Chronicles 3)

With these changes, AMD users suffering from the Pentelas/DLC vertex explosion bug can safely play the game in OpenGL.

But you know what would help even more? If epicboy also added more optimizations for the AMD proprietary OpenGL driver. Which is exactly what he did.

With the release of the new OpenGL driver back in July of 2022, several unsavoury workarounds that yuzu code had for the red vendor could be removed (and now have been), improving performance.

Android adventures, and kernels with benefits

Instead of a bulleted list like in previous articles, let’s start with the big change first.

Saving RAM makes games boot fast

One of the properties of the Linux kernel, which GNU/Linux distributions and Android benefit from, is its flexibility and constant progress made by the community and contributors. One such case is the Linux kernel extension MADV_REMOVE, which allows for freeing up a given range of memory pages, “punching a hole” in the specified range of memory.

Thanks to byte[]’s work, the emulator can take advantage of this extension to remove the requirement of needing 3GB of free RAM immediately after booting a game, and to also significantly decrease boot times while at it. Memory isn’t a problem for most users with 16GB of system RAM (unless you have too many background processes), but for users with 8GB or lower running an OS with a Linux kernel (desktop Linux or Android), this greatly reduces immediate memory requirements, even allowing Celeste to work on 4GB devices…

…For a time. While the system doesn’t need to provide the full 3GB at game boot now, the game will still slowly demand that amount as it runs. But this might be enough to let 8GB devices, or even 6GB ones (which we don’t officially support, but users use them anyway) reach the next save point.

Feel free to play the most complex games now on your 8GB Linux laptop or phone and enjoy the improved boot times! We believe only The Legend of Zelda: Tears of the Kingdom still requires 12GB on ASTC compatible devices (Android devices or Intel iGPUs) to be safely playable now.

For the Windows gang, sorry: only bad news. The Windows kernel doesn’t have an equivalent to MADV_REMOVE, so if you have a low-end device with a small amount of RAM, Linux is the way to go.

No surprise there though.

4K

The resolution? No, worse, crazier than pixel density. Remember Paper Mario: The Origami King? Good game, pretty graphics, and fun humour. This game has a unique situation on its hands, its ARM CPU code is illegal. Not “FBI OPEN UP” illegal, but “not able to run natively on contemporary systems due to a difference in stack pointer alignment handling” type of illegal. The Switch clears a hardware bit that checks the stack pointer alignment and generates an exception, but practically every other operating system sets it, and there is no way to turn it off without a kernel modification.

This meant modern devices couldn’t run this game with NCE enabled. Until now.

By using the ARM parser of Dynarmic, byte[] parses the instructions responsible for causing the crash due to the alignment error this game produces, and interprets them in software. The result? Three thousand eight hundred and fifty eight lines of code added to get a game that doesn’t render correctly on Android booting, and it still needs a save file to get past the intro…

Luigi sure is brave to drive in the Dark Woods (Paper Mario: The Origami King)

So, wasted effort? With byte[]? Never. The game wouldn’t render correctly because the emulator was binding float images with a mismatched sampler type. By forcing the use of floats for all pixel formats in the shader cache which aren’t explicitly declared as integer, mobile drivers are now able to properly render the Mario brothers in all their flat glory, along with at least 71 other games!

Now that’s more like it, it only costs us a shader invalidation (Paper Mario: The Origami King)

Slight deja-vu with the fix for NVIDIA 540 driver series previously mentioned, right? This work was an additional one hundred and eighty four lines of code, giving a total of four thousand and thirty eight lines of code, 4K, spent on Origami paper, just for Android.

Other Android specific GPU changes

Another peculiar problem the Android builds faced were the slow video decoding performance in games like SUPER MARIO ODYSSEY, famous for its video pop-up tutorials. The culprit was unnecessarily downloading some texture memory which was about to be overwritten anyway. Some tweaks to the DMA code by Blinkhawk, and the performance is now fixed!

No more hints here, scra-CAW! ♪ No more hints (SUPER MARIO ODYSSEY)

One early regression yuzu had when the Android builds were first introduced affected the FXAA antialiasing filter. As it turns out, the fix for the colour banding FXAA experienced on desktop hardware (which byte[] implemented back in June) missed updating the renderpass to the proper format. By properly using the VK_FORMAT_R16G16B16A16_SFLOAT format for the renderpass, GPUCode resolved the issue.

From Cursed Triforce to proper Triangle of Death

The Switch offers a JIT service (not to be confused with yuzu’s JIT, Dynarmic) that allows games to write to code memory during runtime — which wouldn’t normally be possible due to the restrictions of the platform. This is currently only used for the official Nintendo 64 emulators in Super Mario 3D All-Stars and the Nintendo Switch Online collection.

Properly using code memory handles allows the JIT service to work with yuzu’s NCE backend, letting the user run games from the Nintendo 64 - Nintendo Switch Online library. Thank you byte[] for yet again making an emulator work inside an emulator.

Look, savestates! (SUPER MARIO 64)

As a continuation to November’s progress on improving Mali stability due to their lack of support for nullDescriptor, byte[] now added the workaround to not pass null views.

Mali moment #3.

nullDescriptor was added with the Vulkan extension VK_EXT_robustness2, back in 2020, for version 1.1 of the API. Vulkan is currently at version 1.3. Given that the feature has native hardware support on all Direct3D-compatible GPUs, and is trivial to emulate in the driver, we are not sure why this has not been implemented yet…

Turnip drivers are a work in progress from the Mesa developers — while they typically perform and render very well, they are still in development. One case that demonstrated this was how a change to improve driver compatibility in Mali caused Turnip to regress in response. Mali moment # 4? No. This was last month.

This only specifically affects the Adreno 610 series GPUs when running Turnip drivers. byte[]’s solution to the issue is to purposely use the Vulkan API incorrectly for Turnip while we wait for Mesa to address the issue. Now Adreno 610 users can run Turnip drivers again.

Android-specific UI and miscellaneous changes

Let’s round up the Android changes — we have more to cover, affecting both desktop and Android users too.

First and most important to mention, t895 outdid himself and finished implementing Game Properties .

Kept you waiting, huh

This new feature can be accessed by long-pressing a game in the list, and allows access to the following menus:

A game information page to check program ID, game developer, game version running, and game ROM path.

Great for diagnosing update installation shenanigans

Per-game settings page, with the option to revert a setting to the global default.

As a game tester, and an 8GB sufferer, your writer considers this a huge blessing

Similarly, a per-game driver selector, for the cases where Qualcomm did something correctly, or an older Turnip release is better.
An add-ons manager to install, enable, and disable updates, DLCs, and mods. While there are plans to support compressed mods, right now they must be uncompressed and manually selected here.

Bet you enjoy this one the most

A save data manager, allowing users to export or import per-game saves, alongside the global option.
An option to delete all save data of that particular game.
An option to clear the pipeline cache of that particular game.
And a Start button, which allows you to select a global or custom configuration. Launching from the game list will always load the custom configuration.

To round it up

This covers one of the biggest missing components the Android build has left. The only remaining settings are a content manager to delete installed content, and a controller mapping UI. Rest assured, we’re working on them.

t895 has continued to work on bringing Android to feature parity with the desktop build, while considering the specific needs of the mobile platform. Some of the recent changes included are:

Hiding the Fastmem toggle if CPU debugging is disabled, avoiding confusion on how it operates.
Exposing the anisotropic filtering setting in graphics, an option that greatly helps visuals in several games with minimal performance cost.
Centering the switch setting title when no description is present.

One of the unique Android features is their Oboe audio backend, which is, as expected of something unique to the platform, quite robust. byte[] implemented it into yuzu to stop audio from cutting off when changing audio outputs (switching to wireless headphones for example) or starting a screen video capture.

The option can be found at Settings > Advanced settings > Audio > Output engine. While Auto is the recommended value (it will always use Oboe on Android), users can take advantage of per-game settings to test Oboe vs Cubeb in any game they want.

And finally, a minor change for end users which we think someone out there will enjoy. With the work on the game properties section, t895 also had to equalise the configuration file config.ini to make it work on both desktop and Android builds.

Memory heap allocation, or how the Linux kernel can be wrong sometimes

Yes, Linux did an oopsie, how will they ever recover?

The Linux kernel has a large set of runtime parameters. One in particular is a limit on how many times a program can use the mmap system call. The default maximum value is 65530, which “ought to be enough for anyone”, or so the meme goes, but in practice that isn’t always the case.

Typically, Switch games will query the amount of memory heap they have available, reserve all of it, and then suballocate from their OS-level reservation as they use up memory. This is already well-supported when using host-mapped addressing (most commonly known as fastmem) on Linux-based operating systems, as it only requires a few calls to map the physical memory blocks which comprise the heap.

Games based on Unreal Engine 4 do not do this. Instead of reserving all of the available memory heap immediately, they reserve small blocks from the kernel on demand. If only the software page table is being used, there’s no problem, as the blocks aren’t resulting in calls to mmap.

When yuzu uses host-mapped addressing, the emulator propagates all of these mappings into the host address space. That in itself wouldn’t normally be a problem, if it wasn’t for the fact that Unreal Engine 4 can allocate hundreds of thousands of small heap blocks, going over the kernel limit with ease, and crashing the entire program.

yuzu is not the only project affected by this completely arbitrary limitation — it has been a complaint for quite a long time.

To work around this limitation, byte[] inserts a layer between the software page table and the host mapping system, constantly tracking the heap allocations made by programs and automatically recycling some less recently used mappings, which causes some stuttering ― but that’s better than a game crash. Collection will reduce the number of mappings to around half of the 65530 limit most systems ship with.

Yep, 64k is not enough for everyone.

This way, Unreal Engine games can be safely played on Linux-based systems, like desktop distributions and Android devices, without needing to disable fastmem and NCE, two big performance settings that no one wants to keep off.

Project Leviathan, applets, and input fun

As usual, german77 has been having his good share of fun working on input and the native applets.

First in the list is a solution for Amiibos with read-only permissions. If a program mounted them as read-only, yuzu doesn’t access any of their encrypted data, and could mark them as corrupt, which wasn’t really the case. Since read-only data is set from the factory, skipping the corruption check allows the use of read-only mounts in games like The Legend of Zelda: Tears of the Kingdom.

Next up, an announcement. german77 started working on a rewrite for the HID (human interface devices) code, called Project Leviathan with the intention of further improving the accuracy of yuzu’s input emulation. So far only preliminary work has been done, but some results have already been put into service.

The first part finished is the emulation of AppletResource, which allows the developers to start working on multiprocess support in the near future, as well as other necessary resources like AppletResourceUserId, or simply aruid.

Following up, german77 implemented the necessary code to allow the creation of multiple instances of HID shared memory, removing an old workaround and relieving the kernel from being responsible for handling shared memory, which in turn allows having a single shared memory instance per aruid.

Another spot that is starting to shape up thanks to this HID rewrite is object creation, more specifically, InitializeVibrationDevice, which would cause games like Rocket League to crash.

But not only german77 worked on input this month, newcomer HurricanePootis brought us an interesting fix for Linux users. Linux handles hardware permissions on a per-user level. For example, if for some reason the administrator desires it, a user can be completely blocked from having access to the video group, or audio, etc.

Connected devices are often only able to be accessed by the root user or group. While this usually isn’t a problem for just using the device, it can block access to the custom Joy-Con and Pro Controller drivers german77 implemented, regardless of whether the user runs an appimage or Flatpak yuzu build. By adding a udev rule to grant access to hidraw devices, HurricanePootis circumvented this limitation. Thank you!

Miscellaneous changes

Multiprocess preliminary work

We spoke about preliminary work for multiprocess support. There’s more to cover on the matter.

byte[] refactored how yuzu emulates CPU core activation. He assures us writing three thousand lines of code simplifies the design of the ARM interface the emulator uses. This has the added benefit of allowing code from multiple guest processes to run simultaneously, which is another of the prerequisites for starting the multiprocess effort.

ARM guest emulation also received support for multiple memory instances, which can now coexist and interact with multiple server sessions. One step closer with every pull request.

Core, kernel, and file system changes

german77 found some… unexpected… behaviour in how the user profile manager behaved. It generated around 13 instances of itself, which lead to multiple, hard to explain bugs related to user data, including the sudden loss of profile after emulator crashes. Slapping the profile manager and telling it to run a single instance should mitigate most random profile loss issues.

Sometimes, games have unexpected file organisation strategies. A recent episode of this phenomenon affects the Batman: Arkham trilogy: the base games ship with a null RomFS. That shouldn’t have been a problem; having a RomFS is never a requirement to run a program. Batman: Arkham Asylum did have a RomFS, and was launching fine, but Batman: Arkham City and Batman: Arkham Knight require their updates installed to be playable (their base game size is only 8MB). The update contains the RomFS, but since the base game didn’t contain it, yuzu couldn’t find the RomFS to load, even with the update installed.

Handling this peculiar case fell into byte[]’s hands, and the World’s Greatest Detective can now go fetch ? signs all over the place at ease.

I am vengeance! I am the night! (Batman: Arkham Knight)

Another file system implementation byte[] gave us was support for the OpenDirectoryMode flag, which allows Portal 2 to save and load properly. One has to wonder why this wasn’t fixed earlier.

Are we going to space? (Portal 2)

Some additional work was needed to get this masterpiece fully playable. An entire service needed some patching-up, specifically, ro, or relocatable object (allowing programs to load libraries on the fly), needed to be rewritten a bit — just over a thousand lines of code.

And finally, vi, one of the services responsible for drawing on the screen, needed to distinguish between closing and destroying layers in order to get Portal 2 in-game.

Ever get that feeling of Deja Vu? (Portal 2)

A silly issue byte[] made in the SSL buffer size configuration broke the Open Course World section of SUPER MARIO MAKER 2. Fixing this configuration mishap allows the game to run its “main mode”.

Yet another set of findings by byte[], yet another battle won against shutdown crashes. This time we have timing related crashes in core timing being addressed, and a rather rare shutdown crash in the kernel being squashed.

Let’s close this longer-than-expected report and move to the hardware section. Our last section in the list is:

UI changes

german77 spotted an oopsie in the UI configuration files, leading to the language selection never getting saved. If anyone noticed yuzu always selected the default language, you now know what the reason was. Making this value persistent solved the problem.

And lastly one last minor buff to Linux desktop users, from the hands of newcomer ReillyBrogan.

When using a Wayland compositor, program windows are matched to their .desktop shortcut file. The appId window property is intended to match the name of the .desktop file, for example, org.yuzu_emu.yuzu.desktop. Plasma desktop, by default, sets this property to the name of the binary file, which in this case is just yuzu, and doesn’t match the expected value of org.yuzu_emu.yuzu. This led to Plasma desktop users (Steam Deck included) displaying yuzu without our glorious icon. One manual override later, and the icon is properly there. Thank you!

Hardware section

NVIDIA, safe to update

Proprietary NVIDIA driver

As previously mentioned, it’s safe to update to the latest driver versions thanks to the fixes implemented by byte[]. This will become more critical once the SUPER refresh of Ada cards is out, so perfect timing there. Hopefully they finally provide good value.

NVK

What’s this? A free and open source Mesa Vulkan driver for Turing and later NVIDIA hardware?

It’s still very early days, Mesa just started shipping preliminary support for this new driver, but we can’t wait to try it out once it’s mature enough. There’s nothing better than having the option to choose.

AMD

We identified Pokémon Scarlet & Violet crashes on RDNA1 hardware exclusively (RX 5000 series). The usual standard procedure was followed, a custom test case was provided in a bug report.

Intel…

In contrast, Intel failed us again. No word on the fix for the geometry shader crash we reported back in October yet.

We hope it’s just a delay from the holidays. 2024 is the year of ~~the Linux desktop~~ working Intel Windows drivers.

Qualcomm

Proprietary Qualcomm driver

We recently got our hands on a Snapdragon 8 Gen 3 device (a Red Magic 9), and while the official Qualcomm driver is still mediocre at best, we’re very impressed with the performance of the new Adreno 750 GPU. In spite of its driver, it managed to bruteforce amazing framerate numbers. It still produced the same graphical glitches any other Adreno card has with their respective official drivers.

Some games reached the 120 FPS limit imposed by the device’s screen refresh rate. In short, Balanced mode in the Red Magic 9 is faster than Diablo mode in the previous Red Magic 8.

Even Turnip, with its early support already shows outstanding results. Here is an Adreno 740 vs an Adreno 750:

i9-14900K who? (The Legend of Zelda: Breath of the Wild)

Speaking of which.

Turnip

Leaving Adreno 750 aside for a moment, the Turnip network of support continues to improve. Current releases have added support for rare GPU variants, like Adreno 642L and Adreno 644. Performance and stability have improved as well.

Keep up to date with Turnip releases; they usually only bring improvements.

Mali moment

Total Mali moments count this month: 3.

But it’s not all bad news dear Mali sufferers!

Newer generations of Mali hardware, codenamed “Panthor” will have an officially backed Mesa driver, the already existing but almost abandoned Panfrost/PanVK driver. This means that Mali moments may cease existing sometime in the future, in a similar way to how Turnip provides a much better experience to Adreno users.

Future projects

Multiprocess GPU SMMU support is almost done now, thanks to Blinkhawk. We’ll cover it in more detail next month, but you can check the pull request draft meanwhile to see the expected benefits it brings.

And maybe the rest of the team has something more going on, yeah. But let’s save that surprise for later, it’s more fun that way (this in no way means any attempt to leak a picture of the current progress was rejected by all devs, no no).

That’s all folks! Thank you for reading until the end, we hope to see you all again in the first progress report of 2024!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report November 2023

GoldenX86 — Mon, 18 Dec 2023 12:00:00 -0300

Hello there, yuz-ers! November brought us many GPU fixes, followed shortly by driver fixes, significant Android/ARM changes, more applet work, new input projects, and much more!

Mario Role-playing as Mario!

As if Super Mario Bros. Wonder wasn’t enough, a cult classic is back, with improved graphics to boot! Super Mario RPG brings some distilled nostalgia to the old SNES-era guard (we still stand strong), so the question was at the tip of their tongues on release day: “Does it run in yuzu?”

It did ― with some buts, as usual. Two things needed to be fixed to get this colourful cast into good shape: an audio fix affecting everyone and a separate fix for NVIDIA users.

Is she in that castle? (Super Mario RPG)

Users immediately noticed how the game’s background audio was completely muted, detracting a lot from the experience. After performing a cross-examination, with music and all, byte[] found out the cause was a leftover from the Opus rewrite Maide did back in September. With this specific case fixed, the game started playing audio as it should.

Meanwhile, epicboy performed a separate investigation in the shader recompiler for NVIDIA’s broken rendering.

Imagine if the Switch was capable of HDR (Super Mario RPG)

For those not familiar with the shader pipeline of yuzu and other emulators:

Games have compiled shaders built for the architecture of the console they are intended to run on – in this case, the Switch. Those shaders are useless for any other device, so the emulator has to intercept those shaders during run-time, convert them into a shader format the selected graphics API can understand (in yuzu’s case the options are SPIR-V, GLSL, and GLASM), and only then those converted shaders can be sent to the GPU driver for rendering. After multiple steps of conversion, a Switch shader finally gets turned into a, for example, Ampere shader, or Adreno, or RDNA3. (And now you know why shader stuttering is a thing.)

NVIDIA drivers have a lot of optimizations for various code patterns in shaders. When you hit a bug in these optimizations, odd stuff can happen, regardless of settings, API, or shader backend in use. There’s no escape. In this case, it led to swapped character colours in menus because NVIDIA drivers disliked the specific pattern the game’s shader used in menus ― and unlike most other driver bugs, it was broken in every single backend!

Here’s a generic example provided by epicboy:

uint low = uint(bitfieldExtract(some_number, 0, 16));
low <<= 16U;
uint high = uint(bitfieldExtract(some_number, 16, 16));
uint swapped = low + high;

epicboy’s solution was to detect this specific pattern in yuzu before passing it to the driver, and replace the last line with a bitwise OR:

uint swapped = low | high;

This makes the NVIDIA compiler happy and provides colour accurate character sprites in the game–everyone wins.

Wario? (Super Mario RPG)

With both issues out of the way, there’s only one thing left to say: Happy stomping!

Project NiCE

Here it is! Time to graduate from a PC emulator compatible with Android to a “native” Android emulator.

NCE support, or Native Code Execution, a huge effort made by GPUCode and byte[], adapted Skyline’s ability to run game code natively on ARM devices, with no recompiler to slow things down.

This sounds great on paper, but what does it mean for users? The advantage of using a JIT recompiler is ensuring compatibility regardless of the device in use ― that’s how an AMD64 computer can run 64-bit ARM games. While this method is good enough for AMD64 desktop and laptops (and one of the few possible ways to do it), it’s very slow on Android phones and tablets, not to mention very taxing, as the recompiled code is less efficient, uses a lot of resources, and requires more power to execute as a byproduct, resulting in increased heat.

Thanks to dropping the translation overhead of a JIT, NCE increases performance proportional to how much power and thermal headroom is available on the user’s device. NCE also saves up to 128MB of memory per guest CPU core (of which the Switch has four), meaning up to 512MB of RAM is saved by dropping the JIT.

Having a device with active cooling will still produce the best results, but with NCE, performance is higher, battery life is higher, heat output is lower, and games load faster. The FPS boost is usually around 20-100%, depending on the game and device.

Results aren’t comparable between the two devices, Mali was run at 0.5x to reduce its bottleneck

Sadly, as always, it’s not all perfect ― “restrictions may apply.” Not all games can take advantage of NCE. Due to limitations in the Linux kernel and the requirements to run on a very restricted memory address space, some early Switch games need to have their updates installed to be able to run with NCE. Games like The Legend of Zelda: Breath of the Wild and ARMS use a deprecated 36-bit address space in their original v1.0.0 release, and NCE requires 39-bit to work. Here the emulator automatically reverts to JIT to allow booting the game. These games get full 39-bit support only with their respective updates installed. You can confirm this when enabling the framerate counter, which will show if NCE or JIT is in use:

As simple as that (The Legend of Zelda: Breath of the Wild)

Another limitation is 32-bit games. Mario Kart 8 Deluxe and Captain Toad: Treasure Tracker, among others, just won’t work with NCE, and the emulator will, just like with 36-bit games, automatically revert to using the Dynarmic JIT.

While there are ways to be able to use NCE with 32-bit games, our investigation found that it would require a secondary 32-bit build target, which we have never supported, and it is no longer viable on Android API versions for Android 11 or later, which happens to be our minimum requirement.

There are also rare cases of games refusing to work with NCE, due to Linux being less permissive than the Switch operating system. One example is Paper Mario: The Origami King, which needs to have NCE manually disabled to run correctly for the moment.

These limitations apply to both Android devices and other ARM devices like Linux ARM boards or laptops.

We enable NCE by default on the latest GitHub and Play Store builds. The option can be found in Settings > Advanced settings > Debug > CPU backend.

Doesn’t hurt to double check

For the setting “optimizers” out there, disabling Fastmem disables NCE with it, so we don’t recommend disabling it unless you cannot run the game you want otherwise. If you see old pictures of games running with Fastmem disabled but still showing NCE under the framerate counter, that’s because the counter didn’t consider this scenario originally; it has since then been patched to correct this.

Yet more changes for Android

But why stop there? There’s more work baked into the Android builds ― here’s this month’s list:

byte[] authored and t895 uploaded the FPS counter. The text was changed to white, its reading is now continuously updated, and it now mentions what CPU backend is in use, JIT or NCE. The FPS counter can be enabled by dragging from the left while running a game and selecting Overlay options > FPS counter.
Many improvements were made to the settings tab, thanks to t895. Icons and descriptions have been added, and the order of the elements and the location of some settings was changed.

Pretty
The Settings tab and About page have been tweaked to add a landscape layout. This work by t895 improves usability for tablets, foldables, and other large form-factor devices.

Thank you Alphonsokurukuchu for the tablet pics
t895 added a drop shadow to the FPS counter to improve readability, and allowed the device’s font style to control the text size of the FPS readout.
When enabled, t895 now blocks Picture-in-Picture during startup or shutdown, improving stability.
Blinkhawk disabled write syncing on Android devices running Turnip drivers, fixing crashes in games like Red Dead Redemption and Luigi’s Mansion 3.
By democratic decision from the users, t895 has disabled Picture-in-Picture by default.
Blinkhawk re-enabled using multithreaded pipeline compilation for Android, reducing stuttering when loading caches at boot and building new shaders while in-game. This was made possible thanks to the lower resource consumption under NCE.
byte[] found another cause for crashes on Mali GPUs: they don’t support multi-viewport rendering. Disabling this feature greatly improves stability on Mali equipped devices. (And so the list of features Mali doesn’t support keeps growing.)
The upper speed limit was increased to 400%, as t895 found out using a high limit is more stable than disabling it at all. Happy benchmarking!
When accessing the Search tab, t895 set the first results before filtering to be your most recently played games.
Thanks to t895, you can now store save exports locally by using a file picker.
Another Mali limitation, another workaround by byte[]. This time nullDescriptor got a special slower codepath so Mali devices can run Super Smash Bros. Ultimate. Everyone is here!
byte[] also fixed an edge case in the query cache that caused crashes on Turnip drivers.
Users reported the face ABXY buttons on Redmagic controllers were flipped, so german77 addressed the issue.
t895 added support in the UI for multiple game folders and the ability to scan subdirectories. Feel free to be as disorganised as you want now; we won’t judge.

We chads use a single folder
And to close up, after fixing issues affecting Mali and Turnip, byte[] decided it was Qualcomm’s turn to get the axe. The vertex input dynamic state Vulkan extension is marked as supported by most official Qualcomm drivers and devices, yet on older 600 series GPUs it’s completely broken, leading to games only displaying a black screen. Excluding this extension solves the issue, and exposes how Qualcomm only tests its drivers on very basic conformance tests and nothing else. Do the bare minimum work, let the community do the rest for you…

Graphics changes

The Force maximum clocks setting seems to cause a lot of confusion among users, which sadly leads to it being enabled in cases where it isn’t intended to be used, particularly power/thermally restricted devices.

The setting was originally intended to solve an AMD problem: their RDNA based cards suffer from severe downclocking, or what your writer calls “chronic downclocking syndrome”, when emulating many games. The GPU load the emulator produces is often so low, its workload fails to be detected as a game, causing the card to keep its clock speeds set to extremely low values. As you might expect, this leads to very low performance.

Enter Force maximum clocks, which on desktop yuzu simply generates a dummy compute load to run on the GPU, triggering the card to clock up by force. While this solves the issue and puts the performance of AMD cards on par with NVIDIA (and even helps NVIDIA cards under some scenarios), running a compute load like this is not a viable option for integrated GPUs. Mobile devices have limited cooling and a power budget: there’s a limited amount of power the CPU and the GPU can share, and enabling the setting will shift that budget’s priority to the GPU, while the user wants to run an emulated game, which is almost always severely CPU bottlenecked. The extra power demanded by the compute load leads to increased heat, which will cause lower performance when cooling is not up to par.

So, what we mean by all this is, don’t use Force maximum clocks on handhelds like the Steam Deck, integrated-GPU-only portable computers with limited cooling capabilities, or integrated GPU desktop PCs. The setting will result in degraded performance and extra bothersome fan noise, and it is only intended for dedicated GPUs with proper cooling. Not every guide online knows what they are talking about.

To help combat this, byte[] expanded the blocklist of this setting to include the recently released Steam Deck OLED. Since there’s no hardware variance in the Steam Deck, it’s a safe case to block.

After Linux NVIDIA users running the Wayland display server reported crashes when using the latest drivers, newcomer lucasreis1 found the cause: The new driver seems to need allocating window resources before asking or system info. Adding the correct line in the correct place makes all the difference in the world. Wayland NVIDIA users can now load games crash-free. Thanks!

byte[] and Maide have been working on performance improvements for video decoding, aiming to not rely exclusively on FFmpeg for this task. The initial changes are up, but more work is needed until the results reach the end user.

Blinkhawk managed to catch and fix several regressions affecting Pokémon Scarlet/Violet introduced by the new Query Cache.

Playable again (Pokémon Scarlet)

In a bit of sad news, byte[] had to disable the support for the depth bias Vulkan extension which was intended to solve the D24 issues affecting AMD cards on Linux (the Windows driver doesn’t support it yet, and uses a different workaround). RADV users (the Linux Mesa Vulkan driver for AMD GPUs) noticed issues with certain stages in Super Smash Bros. Ultimate. Investigating the cause reveals that, even with the use of the extension, you can only fix some games and break others in the process. While we investigate alternatives for this situation, the old workaround is back in place, allowing players to fight in the Nintendo 64 Zelda stage without going blind from the glare.

Back to the drawing board (Super Smash Bros. Ultimate)

Never forgetting about good old OpenGL, epicboy has a list of changes for it this month too.

First of all, he implemented asynchronous downloads, a feature that was previously only available on Vulkan, leading to an 11% performance boost when using the old API.

Next, epicboy fixed the rendering issues affecting Xenoblade Chronicles: Definitive Edition and Xenoblade Chronicles 3 when using the GLASM shader backend ― these two games heavily rely on transform feedback to render. That Monado can look good even if you’re still rocking a Kepler GPU.

Continuing the work on improving the performance of OpenGL, epicboy implemented the use of the glBindVertexBuffers and glBindBuffersRange commands, making the use of the previous GL_NV_vertex_buffer_unified_memory extension obsolete. This reduces the API call overhead that is so notorious in OpenGL, reducing CPU use as a result.

And finally, to close the section, epicboy helped to mitigate a bothersome disadvantage OpenGL has, shader build times ― but only when the user is running NVIDIA hardware. By lowering the size of the constant buffer in the declaration to the size actually used by the shader, shader compilation performance is improved! It’s not as good as Vulkan, but it’s certainly a VERY welcome addition for those cases where OpenGL is the only option.

Applets, input, and other services

Back this month for more is Macj0rdan along with german77, partners in crime working in implementing the controller menu applet. Functionality is limited at the moment, but you can now see your connected controllers just as intended. As usual, a firmware dump is required to launch any applets.

While this is native fun, don’t expect it to be very usable for the time being

Working on his own, german77 managed to fix the profile pictures for all currently available system applets, like for example, during profile selection. The Switch wants exactly 256x256 images, so included as part of the package is a resizer to just give the applet what it wants.

They’re multiplying!

Continuing his previous work on infrared shenanigans (which thankfully don’t involve explosives or self-guidance), german77 finished implementing the moment image processor. This means games like Trombone Champand WarioWare: Put a lid on it are now playable with Joy-Cons. Feel free to crack that volume dial and torture your neighbours to your heart’s content. Here’s an example by german77 himself, enjoy:

Your browser doesn't support mp4 video. :(

Guitar Hero got nothing on this (Trombone Champ)

Switching a bit to input, german77 fixed an omission in the input code regarding the single Joy-Con SL and SR buttons, allowing one of the minigames of WarioWare: Plug your leaks to be playable. Oops.

Got teflon tape? (WarioWare: Plug your leaks)

This breaks backwards compatibility with saved input profiles of single right Joy-Cons ― an unlikely configuration for most games. If you are using this configuration, you might have to rebind your controller, but other profiles are unaffected.

Thanks to the work of newcomer dima-xd, the native software keyboard applet can be run. Sadly, it’s not possible to use it in games at this moment, as it can’t be launched on demand yet ― multiprocess support is needed for this. As an apology, here’s how it looks:

Tactile switches? Touch Switch!

Since yuzu can now work with Mii data inside Amiibos, the code will also automatically validate their integrity. Thanks to german77’s work, the emulator can now detect corrupted Amiibos and automatically load a backup. This avoids crashes in games sensitive to Amiibo integrity, like Super Smash Bros. Ultimate.

Macj0rdan, working solo this time, has a separate fix for us. The controller applet started crashing after the release of firmware 17.0.0. New firmware, new functions to implement ― in this case, implementing SetTouchscreenDimensions solved the problem.

One of the calls SUPER BOMBERMAN R 2 makes checks for blocked users. Since the emulator doesn’t yet store that information, nor has any use for it anyway, it’s safe to stub, which is exactly what newcomer daisymlleung did. Thank you!

The game only boots for now, it doesn’t reach in-game yet (SUPER BOMBERMAN R 2)

To close out this section, toastUnlimited had to deal with Qt shenanigans. Qt’s text parsing didn’t like how yuzu’s frontend strings were stored, causing it to miss many UI translations. A bit of restructuring by the Unlimited Toast, and we’re back in business.

Miscellaneous changes

To help users check the status of their firmware installation, and since the firmware version makes a difference for the system applets, german77 added a firmware version indicator to the status bar of the user interface. Gone is the confusion about “when was the last time I updated this?”

One day there will be an easier way to install firmware

Mouse emulation, along with keyboard emulation, are options for users within yuzu for the few games that support it. These are available in Emulation > Configure… > Settings > Controls > Advanced, and report to games that a USB keyboard and/or mouse is plugged to the console.

To help mouse players ― and we don’t mean “use mouse as a stick for aiming”, we mean emulating an attached USB mouse ― german77 made sure the actual native cursor of your OS doesn’t leave the yuzu window. If you hate clicking your own game out of focus, you will like this change.

While continuing his work on improving yuzu’s file system emulation, byte[] solved a bug that caused MONSTER HUNTER GENERATIONS ULTIMATE to fail to boot when RomFS mods for the game were installed.

But that was only an appetiser; here’s the main dish. byte[] improved the performance of parsing and building RomFS mods, lowering the patch time of The Legend of Zelda: Tears of the Kingdom with mods applied from 2.8 seconds to 0.3 seconds on a high performance CPU (a Ryzen 9 5950X in this case). This was very noticeable in testing.

Modders out there, fill up that list ― you won’t waste time now waiting for games to load.

Exactly the same fix needed for Super Mario RPG, but in a different spot, allows Star Ocean: The Second Story R to boot and play. What did the trick? Allowing a stereo count of zero or higher and fixing a typo. Coding shenanigans.

And to close out this section, what better way to end than enumerating some of the battles byte[] won for improving shutdown stability!

Audio gets the first one. When enough stream data is still waiting in the output queue, the audio renderer will wait until it has space to add more data. But during shutdown, more space might never be made available, which would block the audio renderer forever and hang. Fixing this blockade fixes shutdown operations on Android.

Next one is quite a bit more involved, as it involves the procedure needed to ~~kill~~ terminate a process, James Bond style. This procedure consists of two steps for each thread in the terminated process:

The thread is marked for termination and an interrupt is sent to all cores with that thread’s affinity if it is runnable.
The kernel then waits for the thread to actually terminate.

Runnable threads marked for termination are not removed from the scheduling priority queue. This means they can get scheduled during termination, even if the core already cleared the interrupt when a previous thread was terminated. Checking for termination just before running the thread again, as the Switch does, fixed a very common shutdown deadlock on Android.

And lastly, the timing event queue was causing issues. On shutdown, the system calls to clear pending events, even while the timing thread may still be removing items from the event queue. Locking access to the event queue solves the final shutdown crash of this month.

Hardware section

AMD, mixing drivers

Last month, we reported that AMD is discontinuing driver support for Polaris and Vega products, and speculated how it would affect yuzu.

What we didn’t consider is what happens to mixed configurations, for example running a Vega iGPU and an RDNA2 dGPU. This kind of configuration is quite common, as AMD is still selling new devices with integrated Vega GPUs, and laptop vendors can sell configurations with dedicated RDNA2 or RDNA3 products.

Unlike Intel, who just decided to say “good luck and goodbye” to their Gen 9/9.5/11 graphics userbase with no warning, AMD implemented a system where you can still run drivers for mixed configurations. Since on an all-AMD laptop you can’t use different vendor drivers for the two GPUs, this was basically mandatory.

What AMD did is provide two different drivers, one for RDNA based hardware, and another for Vega and Polaris. If you have a mixed device, you can install the driver for RDNA based hardware first, and then on top install the driver for Vega and Polaris. This allows you to access all software features of the driver, and allows you to have both GPUs operating with no issue.

But there’s a price to pay: the Vulkan driver in the Vega and Polaris driver is older than the one in the RDNA-based hardware driver, and all AMD GPUs running this mixed configuration will run a single Vulkan driver. This results in a setback in features and fixes for the RDNA-based GPU just to keep compatibility.

If you experience issues in yuzu when running this configuration, you now know the reason. Sadly, the only solution is to run Linux, which has a single unified and up-to-date Vulkan driver: RADV.

Intel, fixing drivers (WIP)

Intel confirmed that the geometry shader crash affecting multiple games has been fixed internally, and it’s just a matter of time until a driver comes out with the fix implemented. The currently latest release at the time of writing, 101.5122 (first release driver for gen 2 Iris Xe products), doesn’t include the fix yet.

We hope when we mention this in the next progress report, the issue will be fixed.

Future projects

We’re past the middle of December and we already know the next report will be juicy, just from changes already merged alone. Some things to look forward to include memory savings, improved load times, and higher performance. Blinkhawk is up to something and your writer should really stop spoiling it. Maybe some Christmas gift? Only Emperor Nero knows.

That’s all folks! This Folk Blues is over, see you next month, space cowboy.

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report October 2023

GoldenX86 — Thu, 16 Nov 2023 12:00:00 -0300

Hello yuz-ers! This past month, we got a plethora of GPU fixes, support for new applets, a lot of work poured into the Android builds, some interesting news of the future, and more. Let’s get to it!

Wowie Zowie!

A new Mario game! And it’s an excellent one at that. Super Mario Bros. Wonder joins the fray of side-scrolling Mario games and refines the genre’s gameplay with its new and wonderful levels.

Such a pretty game (Super Mario Bros. Wonder)

The game didn’t boot at release due to incorrect used memory reporting in the kernel. Thankfully, byte[] quickly found the culprit. It was a single-line change!

Hope your platforming skills are up to par (Super Mario Bros. Wonder)

However, this wasn’t enough to get the game in a playable state. Depending on where you are in the game, Super Mario Bros. Wonder internally switches between double and triple buffered VSync presentation modes. This causes the number of images it has available for presentation to frequently change.

yuzu wasn’t ready for this due to a misunderstanding of how nvnflinger works. On Android, SurfaceFlinger (the OG Flinger) can free buffers that are beyond the maximum count a program has allocated, but nvnflinger (the Switch’s fork) is never supposed to free any buffers unless the program requests it. Maide made a few presentation code changes to support this behaviour, and players are now set to grab those fun Wonder Flowers!

Classic Mario (Super Mario Bros. Wonder)

I bet you didn’t expect to see the sole input change of the month here ― yet here we are. Super Mario Bros. Wonder loves vibration, to a point of saturating the old implementation when using HD Rumble on Nintendo controllers (Joy-Cons, Pro Controllers). This is because waiting for the controller to reply takes time, more than the game would have the patience for, leading to noticeable and bothersome vibration stuttering. That’s right, ASTC, you’re not the only one in town causing stutters. By making vibration calls asynchronous, vibration is, while not entirely solved, now much more pleasant.

The GPU changes

Undefined behaviour: the formal way to say “here be dragons”. It’s a good practice to avoid dragons ― I mean, undefined behaviour ― in your code, especially when dealing with a complex graphics API like Vulkan.

Remember our explanation of depth stencils back in August? You may wish to reread that, as it provides useful context to what we will talk about next.

When a game is using a depth buffer, it is usually drawing into a busy 3D scene while taking advantage of a hardware-accelerated process called depth testing.

During depth testing, the GPU hardware determines if a pixel is visible or hidden (occluded) by another pixel. This is decided by their depth values. The depth buffer tracks how far away each stored pixel is from the camera. If a rendered pixel is further away than what has already been drawn on the scene, then the pixel is discarded; if it is closer, then it is kept and the colour buffers are updated. Typically, the depth buffer is also updated and written to, in this case, to store the depth of the new, closer object.

It is possible for a game to use depth testing alone, and turn the actual writes to the depth buffer off for specific elements, and many games do this when rendering partially transparent objects. However, the opposite is not allowed by graphics APIs like Vulkan ― hardware designs require depth testing to be enabled in order update the depth buffer. yuzu’s masked clear path for depth/stencil buffers has a shader which updates the depth buffer, and so enables depth writes, but forgot to also enable depth tests. Most of the time, this worked by coincidence, as the game was enabling depth tests and yuzu was not clearing this state. However, not all games enabled them, and without depth tests, games like Super Mario 64, part of Super Mario 3D All-Stars, can’t properly render the face of a certain character (I think his name is in the title of the game.)

Wonder who he is (Super Mario 64)

Thanks to the work done by Maide, Mr. Mario Mario renders correctly now.

Not stopping there, Maide’s dragon-hunting continued for another pull request. One advantage of using the standard Vulkan Memory Allocator (VMA for short) is how it can help sanitise code.

VMA will raise asserts if things are wrong somewhere. In this case, we were accidentally marking a device-local buffer we intend to use exclusively in VRAM as CPU mapped. VMA is very clear here: device local buffers should not be allocated as mapped because they are outright not intended for CPU access. Making it happy has soothed another dragon.

Thanks to users’ reports, Blinkhawk managed to figure out why the new query cache was leaking memory in many games, including The Legend of Zelda: Tears of the Kingdom. After some slight tweaking, RAM consumption is put in its place.

Starting a campaign to combat holes in yuzu’s format support, Squall-Leonhart has been working on implementing some of the more obscure format conversions, like D32_SFLOAT. For this particular depth format on Vulkan, it can now be converted to ABGR8_UNORM when the game needs this behaviour. Combined with adding support for the Z32, FLOAT, UINT, UINT, UINT, LINEAR variants in the internal format table, this work solves rendering issues in games like Disney Speedstorm and Titan Glory.

Look, the most powerful mouse in the world (Disney Speedstorm)

Some games also make aliases of images in the D32 depth format. Since a similar limitation with format conversion was present here too, ARGB8_SRGB and BGRA8_UNORM/BGRA8_SRGB can now be converted to D32_SFLOAT to provide proper compatibility.

Aged graphics have this feel of nostalgia (Gothic)

Continuing with this streak, Maide implemented the X8_D24 depth format, allowing A Sound Plan to start rendering. However, more work is needed to make this game properly playable.

Robustness is a feature Vulkan provides that lets developers handle invalid memory accesses in a cleanly defined way. This can help prevent the application from crashing or ~~summoning dragons~~ invoking undefined behaviour when some part of the code tries to access memory out of bounds.

For some reason, either Maxwell and Pascal NVIDIA GPUs have broken robustness support on uniform buffers, or yuzu’s codebase makes a wrong assumption somewhere (most likely the latter). As a result, those two NVIDIA GPU generations (GTX 750/GTX 900/GTX 1000 series) suffer from oversized graphics on Crash Team Racing Nitro-Fueled, due to the game accessing memory out of bounds in the shader. Manually clamping out-of-bounds buffer reads to 0 on the affected GPU architectures solves the issues. We are also now investigating what causes this problem in the first place. Maide gets to play detective yet again, dear Watson.

This GTX 1050 needed a diet (Crash Team Racing Nitro-Fueled)

Maide also fixed a hidden issue with the resolution scaler. Images were being marked as rescaled, even if the resolution scaler was not in use (running at 1x). This led to a slight additional overhead, and rarely, some assertion failures. While no game bug was known to be caused by this, it’s good to have preemptive fixes for once instead of just reactionary ones.

In the meantime, Maide has also been removing image alias bits for all image attachments in an effort to allow the drivers to use more memory optimizations. This pull request also includes some other minor fixes with it.

By implementing the first and subsequent draw commands for vertex arrays, Super Meat Boy finally renders correctly! No more black screens!

Well done (Super Meat Boy)

And now, one for the Linux gang. v1993 tested and re-enabled CUDA video decoding on Linux, allowing better video decoding performance for NVIDIA users (running the proprietary driver, of course). We previously disabled CUDA by default because it can fail on systems running both a dedicated NVIDIA GPU and a dedicated AMD GPU (iGPUs are fine), a decently rare configuration that only a few people, like your writer, actually ever use.

For those few users running mixed hardware vendors on your systems, please manually select “CPU Video Decoding” if you’re affected by video decoding issues now. This was the previous default behaviour.

We received user reports of crashes occurring when grabbing a Grand Star in Super Mario Galaxy, as part of Super Mario 3D All-Stars. byte[] found that the problem is in how the Vulkan scheduler incorrectly flushes data. The solution? Use a lock. And if that doesn’t work, use more locks. Happy star hunting!

To improve OpenGL support even further, Epicboy returns. First, he found that the shfl_in_bounds variable, which is used to track data used in compute shaders, could result in undefined behaviour when threads were inactive and return invalid results. The solution was to move the shfl_in_bounds check after the readInvocationARB function, which requires all threads to be active, to avoid ~~dragons~~ undefined behaviour. This fixed some graphical corruption issues in unit tests, which should lead to fixes in real games too.

Next, a simple gift from epicboy: force enabling Threaded optimization, an NVIDIA-specific OpenGL optimization that enables the use of a new separate CPU thread for graphics rendering. This is a solid performance boost for those running OpenGL with NVIDIA hardware. And for those asking, yes, Vulkan allows the use of a separate thread for rendering too ― but we do it on an API level, instead of a driver setting, so all GPUs can benefit.

Maide found a problem occurring with compute shaders when they were triggering invalidations in the buffer cache. yuzu has a lot of code to track the sizes of buffers used by the games. Consider a game using two buffers: the first, with an address range from 1 to 2, and another with a range of 3 to 5. They don’t overlap, so there is no issue. Then, after the game runs for a while, a buffer requiring a range of 1 to 5 is used. The previous two buffers would be considered to overlap it and will be deleted. Then, the old buffer data from the two overlaps gets moved to the new third buffer. While this was already working for graphics-related buffers, it didn’t correctly consider compute buffers.

Adding the missing loop to fix this behaviour, problems ranging from minimal graphical issues to completely broken game logic are potentially solved. You know what they say: with compute, the sky’s the limit. Just ask AI developers.

Another optimization Maide implemented affects how buffers are handled after they are successfully deleted. The previous method would unnecessarily create several copies, wasting resources. By removing one synchronisation step, only the exact amount of needed copies are used.

Now let’s discuss a long-standing issue: some 2D games were flipped on AMD, Intel, and Android GPUs. Games can use different APIs to run on the Switch. Nintendo allows the use of Vulkan, OpenGL, and their proprietary API, NVN. This poses a problem for emulation on Vulkan, since only NVIDIA GPUs support the viewport swizzle extension (which allows for transforming viewports).

To allow other GPU vendors to render properly in most cases, a fallback implementation was made to handle the case of vertical flips, for use by OpenGL games. A tiny error in its implementation made it unable to correctly track invalidations of the viewport flip state, resulting in garbled graphics in several games. byte[] solved that issue with a one-line change, making games like Stardew Valley, and Streets of Rage 4, finally render properly on non-NVIDIA hardware. No more mirrors needed!

THE cozy farming game (Stardew Valley)

While investigating this, a similar but different issue came to light. Many OpenGL games (that is, games using OpenGL to render, not yuzu rendering on OpenGL) ask for a 1920x1080 framebuffer, regardless of whether the game is running in handheld or docked mode. The game then simply moves and resizes the region it’s rendering to inside that 1920x1080 buffer, like moving a small box inside a bigger box, if you will. In the final step, the image is flipped and sent to the bottom of that 1080p render target. yuzu was incorrectly rendering only the top of the render target due to how it used to calculate that flip in the final pass.

Adjusting this behaviour made Tiny Thor render correctly in handheld mode.

To Valhalla (Tiny Thor)

And to close the graphics section, by following this chain of events, the previous pull request helped spot a bug in our Vulkan presentation that led to Arcaea being incorrectly cropped in handheld mode. 95 lines of cropping-behaviour code changes later, and byte[] solved the issue.

Good art style (Arcaea)

Android changes

This month the Android build got not only significant UI changes to improve quality of life, but device compatibility was greatly improved for Adreno users. Here’s the full list!

A new GPU driver manager was developed by t895, allowing the listing of multiple drivers, useful for quickly switching between proprietary Qualcomm or Mesa Turnip releases, or several versions of each. Due to the beta status of Turnip drivers and the immature code of Qualcomm drivers, the latest release is not always the best.

For all your driver-switching needs!

byte[] solved a crash related to surface recreation, which could be triggered by simply rotating the device.
byte[] solved an issue affecting some Android devices that ship an outdated Vulkan 1.1 loader instead of the current latest 1.3, causing the device to report older features than the driver in use actually supports. This resulted in specific Adreno 600 and 700 devices crashing at boot when using any Mesa Turnip driver version. Forcing the correct Vulkan 1.3 features the driver supports solves the issue. We’ll expand on this at the end of the article.
t895 implemented a home settings menu grid for devices with bigger screens and/or higher DPIs. This should please our tablet and foldable users. Enjoy!

Landscape lovers rejoice

byte[] fixed another case where yuzu would fail to recreate the surface on screen rotations.
t895 moved the game list loading process to a separate thread to reduce stuttering when opening yuzu. The process still takes a similar amount of time, but the perceived smoothness is very welcome.
t895 solved an issue that caused the touch buttons overlay to get stuck while drawing the in-game menu from the left side.
While waiting for a controller settings menu, t895 fixed a bug that caused all controller input to move to player 2 on some devices, blocking users from playing most games. Devices with integrated controllers should have a much better experience now.
And finally, following the recent changes in the desktop version, t895 added a menu to access the currently supported applets, Album and Mii editor, along with the Cabinet applet to manage amiibo data. Wii think you will have fun!

We hope to expand this selection in the future

Wii want to play

The settings menu was also reorganised:

Hope it’s more convenient now

UI and Applet changes

After a rocky start, thanks to the early work of roenyroeny, boludoz, and FearlessTobi, we now have proper shortcut creation support for Windows too!

To access this feature, simply right click a game in yuzu’s game list, select Create Shortcut, and pick if you want it on your desktop or the applications section of the start menu. This allows you to start games with a quick start menu search or even from a pin in the menu/taskbar if you so choose.

Populate that taskbar

Helping improve this, german77 made the required changes to save multiple resolutions per icon, making smaller sized desktop icons much more readable than before.

Scaling images down doesn’t always look the best

DanielSvoboda made several changes in file system handling to improve directory path detection for the shortcuts, making them far more usable and stable. Thank you!

Work on improving user experience (UX) is always welcome, it is your writer’s belief that UX is as important as proper functionality, and should never be ignored. To improve the quality of life of people playing with multiple controllers, flodavid changed the behaviour of how users interact with the number of connected controllers in the Controls settings. Users can now more intuitively click the green lights at the bottom to select how many players/controllers they would like to be active. Thank you!

Epic Smash sleepover!

Another welcome UX addition is by Macj0rdan, who implemented a quick control for game volume with the mouse wheel when the pointer is placed over the volume button in the UI, removing the need to click it and drag a small slider. Thank you!

Continuing his work on applet support, german77 implemented the SaveScreenShotEx0 service method and its variants, allowing users to take captures from within games themselves instead of globally with the screenshot hotkey. This works for games like Super Smash Bros. Ultimate ― however, note that screenshot editing is not available yet. Homework for later!

Save your best moments (Super Smash Bros. Ultimate)

german77 also implemented the SaveCurrentScreenshot method, allowing users to take in-game screenshots in Pokémon Scarlet/Violet with its latest update installed. Happy selfie shooting!

Feeling cute, might capture a shiny later (Pokémon Scarlet)

One of the changes german77 introduced broke the Find Mii stage in Super Smash Bros. Ultimate. Since it’s not a popular stage, even among the Smash community, we didn’t notice this issue, and no one reported in our Discord server, forums, or GitHub bug report page ― we only found out thanks to complaints on Reddit. This is a reminder to you, the users, please try to report issues in the proper channels! Doing so ensures we see the problems you are having and can work to fix them.

yuzu is a large project with many “black box” areas. There will be bugs, many thousands of bugs, that our team may never encounter. Your voice is so important, we hate to see any bug reports slip through the cracks outside of our channels.

With that out of the way, by creating random Miis with names, german77 solved the issue.

german77 also expanded the character limit of cheats to more than 64 characters. Now you can cheat to your heart’s content.

You know our developers spend a lot of time opening and closing yuzu when byte[] can accurately measure that 10% of shutdown crashes are caused by the game list. He found that the issue was in how Qt deals with messages from objects that were destroyed or disconnected (like stopping the emulator while the game list is loading). By changing the behaviour of how the game list is reported to those events, another source of shutdown crashes has been defeated.

Kernel, CPU, and file system changes

byte[] has been having a lot of “fun” lately fixing and implementing kernel changes. First off, he fully implemented transfer memory, fixed incorrect page group tracking, updated the implementation of KPageTableBase, and has now nearly completed the entire KProcess implementation!

As preliminary work for NCE support coming in the near future, byte[] implemented native clock support for arm64 devices running on Linux or Android. There is no support for ARM Windows devices for now, as none have bothered to include a Vulkan driver yet.

The kernel was updated to reflect changes made in firmware version 17.0.0, ensuring support for future games.

v1993 solved some warnings that were spamming our build logs ― namely, using std::forward where appropriate, and qualifying std::move calls. This should solve build issues for those experimenting with Darwin build targets.

By user request, byte[] further improved the build performance of RomFS mods by getting rid of some unnecessary object copies. This also fixed a file handle leak, which now allows modders to edit mod files after stopping emulation, helping them work faster on those juicy and delicious game mods.

Audio changes

Thanks to user reports, our audio connoisseur, Maide, found that Ancient Rush 2 would crash at the end of the first developers screen. Clearing the DSP buffer after each execution fixes the issue.

Diggy Diggy Hole! (Ancient Rush 2)

Speaking of audio, byte[] delivered another resounding victory in the shutdown department by fixing a deadlock in the audio renderer.

Hardware section

We have some sad news for the old Red Team guard, a warning for the Green Team, and very good news for Adreno droids.

NVIDIA, our fault this time

The 545 and 546 series of drivers have solved the high VRAM usage crashes we reported this last month, but users are reporting new crashes in games with these drivers. Reverting to the 53X series of drivers solves the problem, but this time, it’s not NVIDIA’s fault! Mesa also has many new crashes with the 24.0.0 release, and having the top two drivers crashing under the same conditions is not a coincidence.

We found that the problem is in how we are recompiling shaders ― the types of some variables are mismatched. The fix will take some time to implement, so for NVIDIA and Mesa users experiencing crashes in games like Bayonetta 3, we suggest not updating your drivers for the time being.

AMD, giving a last hurrah to Polaris and Vega

The time has come. The last 2 remnants of the GCN architecture are on their way to be discontinued. AMD started releasing split drivers for those products, which run outdated Vulkan driver branches compared to RDNA and newer hardware. The news of AMDVLK, the official Linux AMD driver, killing support for these products means no new Vulkan drivers will be available.

This doesn’t mean the show is over for their owners. For the time being, no new change breaks compatibility with the cards, and Linux Mesa drivers like RADV will continue to provide support, most likely extending it past what the Windows drivers report as supported (as is usually the case with Mesa).

But for those stuck on Windows, this is the last ride.

GCN4.0, GCN5.0, you weren’t the most efficient cards, but you gave us good value in the worst moments, years of amazing gameplay, and great FineWine moments. We salute you and thank you for your impeccable service, few GPU architectures leave the stage with such a round of applause.

Turnip, a very quickly improving work-in-progress

yuzu uses a single codebase for all its releases, upstream/master/main, however you prefer to call it, Mainline, Early Access, and Android all start from there. When improvements to the codebase are added, they eventually reach all releases, Android included.

We recently added improved support for occlusion queries (part of project Y.F.C.) to Android to increase performance and accuracy on all devices. But occlusion query support on Turnip drivers with Adreno 725 and 730 GPUs was not working correctly, and this took us a very long time to find. Users experienced crashes that forced them to remain on outdated GitHub versions, and we needed to stall a new Play Store release until the problem was investigated and properly solved.

The issue was found, reported, and resolved by Mesa in record time in their current Adreno 700 branches, which then driver packagers like K11MCH1 use to build packages Qualcomm users can load on emulators.

For this reason we strongly recommend Adreno 730 and Adreno 725 users to update to the latest Release X driver, which not only fixes the crashes caused by occlusion queries, but also the lack of support for the Adreno 725 and some variants (yes, there are several) of the Adreno 730. It isn’t only desktop GPU vendors who love to rename things.

By using this driver, we were able to launch newer Android builds with the latest upstream changes, and all Qualcomm users can safely use the latest GitHub builds if they prefer.

By the way, the GitHub builds are now properly signed. Rejoice, as you can now update from one to the next without needing to uninstall first. If you want to test experimental and potentially unsafe (but maybe faster) changes before Play Store updates, it’s now much easier.

Future projects

Let’s begin with what most people want to hear about: Project Nice for Android devices. NCE (Native Code Execution) is progressing very well, but there are still some bugs to iron out. Games are becoming not only playable, but also faster on devices with thermal restrictions. Additionally, the time spent loading and closing games has been significantly reduced now! NCE has helped us understand issues in our CPU emulation in x86_64 too, so expect gains on both fronts.

Your browser doesn't support mp4 video. :(

Recorded with a Red Magic 7S Pro (SUPER MARIO ODYSSEY)

No promises on a release date per usual, but as politicians love to say: “We’re working on it.”

Your browser doesn't support mp4 video. :(

Destroying those touch screen controls! (Bayonetta 2)

Blinkhawk is suggesting that your writer informs you he is working on a new project seeking to make the GPU process-agnostic, allowing multiprocess emulation within the GPU. No fancy names this time, we’ve simply been calling this “Multiprocess” internally. Multiprocess is a mandatory step towards UMA support, which will provide huge gains for iGPUs and SoC users, as well as reducing RAM consumption.

That’s all folks! Apologies for the delay, university homework and finals are killing your writer. Thank you for reading until the end. See you next time!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report September 2023

GoldenX86 — Fri, 20 Oct 2023 12:00:00 -0300

Hi yuz-ers! Last month has been interesting, and we’re excited to report what we’ve been up to. Miis come out to play, GPU changes, Android improvements, and more! Let’s get into it.

Of Miis and applets

Wii want to play

For quite some time, it has been possible to load the default Miis in supported games on yuzu. However, yuzu’s implementation of the Mii service was lacking the necessary support for the Mii database.

The Mii database is a file saved on the Switch which holds up to 100 Miis. Without the proper support for this database within the Mii service, it was impossible to load your custom Miis.

Our in-house input emulation expert, german77, embarked on an adventurous journey to test the MiiEdit applet as part of his ongoing quest to make system applets function smoothly on yuzu. Initially, things were progressing well, but his efforts hit a roadblock when softlocks while booting the applet became a recurring issue.

Suspecting that erroneous data from the Mii service might be the root cause of these softlocks, german77 decided to undertake the task of completely reverse engineering the Mii service. His dedicated efforts led to an almost fully-implemented Mii service, with the only missing piece being the ability to send and receive Miis from nearby users. This comprehensive implementation involved rectifying some of the older code, reorganising data structures, and, at long last, providing support for the eagerly anticipated Mii database. Adventurous users have the ability to load their own Mii characters in any game by placing their console’s database file at %appdata%/yuzu/nand/system/save/8000000000000030/MiiDatabase.dat.

With the Mii service completed and behind him, Narr swiftly returned to the task of making the MiiEdit applet function seamlessly on yuzu. Thanks to some troubleshooting assistance from byte[], he ultimately managed to make it work. The last piece of the puzzle was completing Mii database support for the applet, and with this crucial addition, yuzu’s Mii functionality is now more robust than ever. Users can now seamlessly create, edit, and store their Miis using the new MiiEdit applet via Tools > Open Mii Editor, and games can automatically generate a random Mii for players without crashing.

Edit to your heart’s content

Building on the success of the MiiEdit applet, Narr continued his productive streak by fully implementing support for the Cabinet applet. The Cabinet applet, if you weren’t already familiar, is the amiibo manager applet. With these recent changes, users can register, rename, delete, and restore their amiibo data via Tools > Amiibo.

And register as many as you want

Graphics changes

Switching to the graphics department, let’s begin with some interesting decisions from the Khronos group that affected the Linux Mesa drivers.

After getting reports of crashes when running Pikmin 4 on Linux, byte[] discovered that Khronos removed the ability to declare an OpTypeSampledImage for buffer textures from the latest release of the SPIR-V specification, the shader backend used by yuzu for Vulkan support.

This is extremely unusual — usually a deprecation is preferred (to not affect old code). Mesa, being the textbook example of following the specification, followed through with this change, forcing us to skip samplers for buffer textures. With these weird Vulkan decisions properly handled, Pikmin 4 is once again playable for those running Mesa drivers.

Speaking of Pikmin 4, and of Master Detective Archives: RAIN CODE, byte[] also found the cause of the lighting issues and wrong faces rendering affecting the former and the latter game, respectively.

byte[] noticed an additional validation error Mesa was providing when debugging the issue with sampled buffers. yuzu’s SPIR-V emitter was generating atomic operations on a typeless image, which the SPIR-V specification has never allowed. After a false start by trying to avoid typeless images, he found the real culprit: the code for generating SPIR-V atomics incorrectly used the array index of the image, instead of its designated descriptor.

Correcting this shader behaviour fixed the headlamp lighting required in specific dark sections of Pikmin 4 and the facial expressions of characters in Master Detective Archives: RAIN CODE.

Your browser doesn't support mp4 video. :(

A little bit of exploration never hurt anyone (Pikmin 4)

GPUCode also joined the fray this month with several code additions.

First of all, something light, let’s introduce separate command buffer uploads! This gives the benefit of a slight performance uplift, caused by reduced renderpass breaks, which greatly helps mobile GPUs. The larger the renderpass, the longer mobile GPUs can keep data in tile memory, so breaking it is a costly operation. Dedicated GPUs benefit from this change, but much less.

We measured an 8% performance increase in some games with a 5800X3D. Lower end systems could see bigger gains.

GPUCode also fought against the rendering issues affecting Mortal Kombat 1 and Sonic Forces when using Vulkan. For those deep into the yuzu lore, this is a compute shader implementation of MSAA image copies, similar to what epicboy did back in February. As said back then, compared to OpenGL, Vulkan requires a lot more work.

Round 1, Fight! Emutality! (Mortal Kombat 1)

This change also improves the original shader, allowing games like Pinball FX3 to render and work correctly now, regardless of the graphics API in use, while also improving the rendering of games like Fate/EXTELLA: The Umbral Star.

I ask of you. Are you my Master? (Fate/EXTELLA: The Umbral Star)

Don’t break it, please (Pinball FX3)

Players of The Legend of Nayuta: Boundless Trails, and other Falcom games like The Legend of Heroes series, reported that text was rendered incorrectly, displaying weird colour highlights. GPUCode investigated this and found that we were using the wrong colour component order (BGR vs RGB for example) for the A4B4G4R4_UNORM texture format. Instead, A4B4G4R4_UNORM_PACK16_EXT has the order the game expects, providing correct rendering.

Ask Jobs what he thinks about good font rendering (The Legend of Nayuta: Boundless Trails)

Continuing this trend of texture fixes, GPUCode also identified a bug in how sRGB textures were being handled.

The problem was that sRGB textures could not be used as storage images in shaders. The solution was to create the texture as linear, which is another colour space that does not have gamma correction, and then use an sRGB view to access it. This way, the texture can be used as a storage image and still have the correct colours.

However, this solution had an unintended side effect. When the texture was used directly without the view — for example, when it was resolved by copying it to another image — the colours were wrong because the colour space had changed.

To fix this, the pull request ensures sRGB creation is only disallowed when transcoding, which means that it always applies except when converting compressed formats to uncompressed formats on the GPU. This way, the texture is created as sRGB and has the correct colours in both cases.

Thanks to this, Momotaro Dentetsu and Star Ocean First Departure R can now render with the colours and gamma intended by their developers. The way it’s meant to be played, as a certain luxury-focused graphics card vendor says.

Don’t mess with my gamma! (Momotaro Dentetsu)

Now’s the turn for our classic Key visual novel fans, your writer included. Users reported the games had some terrible flickering. The cause, as Maide found out, is due to how particular the rendering for these classic games is. Most games create a single render target on a single address, either 1080p or 720p. Key’s visual novels instead use the same address to create both 720p and 1080p render targets, with the 1080p one being created first, but never being used. yuzu, by default, always picked the first render target.

This wasn’t an issue for other games, but for this engine, the texture cache constantly detected the wrong image, causing it to alternate between both render targets on each frame. This resulted in a black frame being rendered between two valid frames, causing dangerous flickering for those with photosensitive epilepsy.

By changing yuzu’s behaviour to look for the most recently modified image to present, the issue is completely fixed, and users can now cry entire nights reading these games.

All the stars in the sky are waiting for you (planetarian)

And to close this section, Blinkhawk fixed some memory leaks caused by the recent query cache rewrite.

Android additions

Our resident Terminator and Nier: Automata enjoyer t895, and other members of the team, continue to work hard on improving the experience of the Android build:

A hardware limitation exposed by the Buffer Cache Rewrite from Project Y.F.C. was worked around. This change was done by GPUcode.
A bug where certain temporary settings would be reset on emulation start (for example, “Limit emulation speed”) has been fixed.
An issue where game shortcuts would appear cropped on certain devices was fixed.
The amount of thread workers for shader compilation was reduced to one. This is intended to reduce memory consumption.
More screen orientation and aspect ratio misbehaviours were fixed.
An issue where the input overlay would draw offscreen on some devices was fixed.
An issue where the settings activity would appear dim when in landscape mode while using 3 button navigation was fixed.
The in-game menu could be unintentionally opened during the loading animation. This is now fixed.
Several crashes related to the initial setup, emulation activity, and emulation fragment are now fixed.
The emulator will now correctly reload the settings file after resetting all settings.
Lastly, a new settings menu unifies all content installation into a single place. Users can now access the Manage yuzu data menu to import/export firmware, saves, user data, and install game content, console, and Amiibo keys. The new User data option allows users to backup and restore all app data. Useful for example when migrating to other builds, like from a GitHub release to a Play Store release.

For the convenience of the lady and the gentleman

Audio changes

Maide shines here by giving us a rewrite of the hardware Opus service, responsible for handling decompression of Opus-formatted audio in games. The old implementation lacked several functions documented by the reverse engineering community, which is what this rewrite focused on the most.

Now the hardware Opus implementation matches the current information available. Maide also took the opportunity to move the processing of Opus to the emulated ADSP (the emulated implementation of the audio coprocessor of the Switch).

The end result of this effort is allowing games that previously faced crashes when trying to decode Opus audio, like MLB The Show 22 & 23, the Touhou series games, Pokemon Quest, Pokemon Let's Go Eevee!/Pikachu!, and Sea of Stars to play the audio correctly without crashing.

Maide also fixed audio command processing, avoiding some command lists from returning early before being properly finished. After an interruption, the previous implementation would restart processing the list from the beginning instead of continuing from where it left off. This stalled audio rendering until it finished properly. Correcting this behaviour solved cases where the audio engine would run too slowly, improving performance.

Another issue that required quite the investigation caused background sound in Xenoblade Chronicles 2 to cut off randomly. The cause was found to be in the data source commands during loops. Changing the behaviour between its different versions restored proper ambient noises to this great game and a few others.

To close this section, Maide also discovered what caused the dropping of music and voices in New Super Mario Bros. U Deluxe’s final level. The audio command buffer sometimes took longer to process than estimated, which caused voices in the renderer to be dropped. The game depends on this behaviour to some extent, but yuzu’s calculation of the estimation was subtly incorrect, causing almost everything to be dropped.

Improving the time estimation algorithm solved the issue. Let’s hear those voices!

Miscellaneous changes

Sometimes, we overlook testing on devices that don’t meet our standard hardware recommendations. With the addition of the new Vulkan VSync options, we made an incorrect assumption. As it turns out, users do not always have Vulkan drivers installed! Shocking, right?

While most of the time users do have support for Vulkan, that certainly is not the case for NVIDIA Fermi users (people that were promised a Vulkan driver but never got it), or users of Linux distros which don’t package GPU firmware files, like Trisquel. This caused the VSync combobox to refuse to offer any options when no Vulkan driver and device was detected, which blocked OpenGL-only users from toggling VSync.

While it’s easy to just ask the users to upgrade to newer hardware, and/or use a more functional distro, that doesn’t change the fact that the behaviour is incorrect.

Enter toastUnlimited, who fixed the UI and took the opportunity to improve the broken Vulkan detection, ensuring OpenGL is selected as the default API if needed.

Fermi still rocking it

byte[] fixed language selection being ignored in multi-program applications, which was affecting games like Super Mario 3D All-Stars, Grandia HD Collection, and others. Proper localisation is very important to us! Not everyone can corrupt their minds by learning English, after all.

¡Mamá Mía! (Super Mario 3D All-Stars)

Newcomer rkfg found one of those bugs that makes you question how this even worked before. yuzu’s parsing for the PFS file format would try to read filenames from the header as a C string. C strings definitionally end at a null byte, but this failed to account for the fact that the next null byte could sometimes be well past the end of the header, and parsing a file with this specific construction would cause yuzu to fail to find files inside the archive and/or crash. By unconditionally inserting a null byte after the header data, rkfg solved this one. Now games like Luigi’s Mansion 3 don’t encounter strange crashes seemingly out of nowhere.

While working on more file system improvements, byte[] implemented a simple NCA (Nintendo Content Archive) verification system, which checks that the names of NCA files match their contents to guard against filesystem corruption. Now users can check the integrity of their game dumps by right clicking a game in the game list and selecting Verify Integrity. Implementing proper signature and hash-based verification is planned, but expected to be very slow in comparison.

Always helpful

By stubbing the GetSaveDataSizeMax filesystem service method, FearlessTobi made Minecraft Legends Deluxe Edition able to display its boot screen. Sadly the game crashes after that, guess there’s more work to do!

This is as far as it goes for now (Minecraft Legends)

Continuing with the stubbing procedures, fixing up purchase info calls allows The Settlers: New Allies to start properly.

NVIDIA on the left, AMD on the right (The Settlers: New Allies)

As you can see, more work is needed to get this game to render properly. Extra points for being a game that renders better on AMD over NVIDIA.

But what about a new service? byte[] added a stub for the ngc service, allowing the Baten Kaitos HD collection to work.

Old-school (Baten Kaitos HD collection)

Likewise, adding the GetFileSystemAttribute service method makes Tiny Thor playable; it no longer gets stuck during the initial loading screens. C’mon, without googling, spell the name of Thor’s hammer correctly.

So adorable! (Tiny Thor)

Back again with good fixes is Squall-Leonhart, who now focused on Windows file system error handling. For example, yuzu would simply crash if you disconnected a removable storage containing games loaded into yuzu’s list, a network SMB share, or a Bitlocker protected location was unavailable.

But not anymore! By adding the proper error handling to these file system exception cases, the emulator now avoids a crash here; complaining, but working.

Managing another critical blow to the fight for proper shutdown behaviour, byte[] managed to spot an optimization that should save around a second of time on high-end CPUs. Does this mean the fighting is over? No, some edge cases remain, but now under normal circumstances, closing a game should be almost instantaneous. We have a medal ready for byte[].

Hardware section

NVIDIA: VRAM fixes, and focusing on the latest hardware

The latest driver releases have proven to be stable for Turing and newer products, but we got reports of small regressions affecting Pascal and Maxwell users. If you’re still running older 750, 900, and 1000 series products and you face new issues in games, try reverting to older driver versions like the 52X series.

Still, it’s worth to mention that driver release 545.84 seems to have solved the instabilities caused by excessive VRAM use, like for example while running The Legend of Zelda: Tears of the Kingdom in the Depths with 2GB/4GB GPUs of any architecture. This is great news for low-end users struggling to run this particularly ASTC-heavy game.

AMD: general fixes, AutoHDR, VSync problems, and frame interpolation

First, good news, the latest Windows driver version at the time of writing, 23.10.2 has solved the D24 issue affecting AMD cards on Vulkan. Those bothered by clipping lines and textures should upgrade to get the proper graphics experience. Keep in mind that this doesn’t solve the vertex explosions affecting the Pentelas region and the DLC of Xenoblade Chronicles 3, we manage to confirm this is a different issue affecting AMD cards on a much lower level, as it is architecture, OS, and driver agnostic.

Another good bit is that recent drivers also seem to have introduced DXGI swapchain support, allowing AMD cards to work with AutoHDR out of the box. There doesn’t seem to be a driver toggle for this though. Users interested in enabling AutoHDR for yuzu can use this piece of software to do the registry work for them.

Now for a bit of bad news. Windows driver version 23.9.3 and newer cause the VSync options to be ignored, resulting in tearing during gameplay. If you’re affected by this, revert back to driver 23.9.2 for now. The standard procedure was followed: we’ve opened a ticket with AMD regarding this issue and provided a generic test case.

ED: Driver 23.10.2 seems to have solved this issue entirely, we recommend updating to it.

Switching to something more interesting, we heard you! Despite our previous rants about frame generation, we think vendor-agnostic frame generation like FSR3 would be cool to make Pokémon games playable, but the same requisites which prevent us from using FSR2, or even DLSS/XeSS for that matter, apply here. Games don’t report their motion vector data to the console, since they were never developed to support DLSS.

There are ways to implement this, such as adding one frame of delay and extrapolating data. The downside here is that 33ms of delay for 30 FPS games would be an awful experience. We could guess motion from previous frames, but this could have a very high performance cost and can potentially produce erratic results, old frames can’t read the future. Or we could dip our toes into AI, which has given us unsatisfactory results in the past. While coding a generic way to extract motion vector data might be possible, it’s a huge endeavour, so expect it to be a very low priority at the moment. We have bigger fires to put out first, after all.

What could work is AFMF, if AMD adds Vulkan support for it in the future.

“But writer, AFMF is not vendor-agnostic! It’s an AMD Windows driver exclusive feature!” you say. Ah, but that’s where you’re wrong. It is vendor-agnostic on desktop PCs! Kinda.

The only thing you have to do is get an RX 6400 (or higher) as a secondary GPU in your desktop PC, connect your displays to it, and enjoy enforcing frame interpolation even when using a primary Intel or NVIDIA GPU for rendering! Sadly, this doesn’t apply to yuzu yet, because the current beta driver for AFMF at the time of writing only supports the Direct3D 11 and 12 APIs.

Let’s hope we get Vulkan support and we may be able to finally see Tears of the Kingdom hitting over 100 FPS, or Pokémon Scarlet model animations reaching ~~smooth~~ cinematic 30 FPS. Meanwhile, try to enjoy converting 20 FPS to 40 when using Path Tracing. At least you don’t have to pay 500+ bucks for this.

Intel…

Sadly, we have another driver-level issue to report from Team Blue. This time, the problem is in geometry shaders. The SPIR-V shader compiler crashes the Vulkan Arc driver due to a null pointer dereference. This affects many games, even popular ones like Xenoblade Chronicles 3 and The Legend of Zelda: Tears of the Kingdom.

The bug report has been filed. Fingers crossed for a resolution faster than seven months this time, and a more satisfatory result than 14th gen products.

Turnip, steadily progressing

The latest release of the Turnip driver for Adreno 700 series at the time of writing, R7, seems to reduce overhead considerably, resulting in less overheating for Qualcomm Android users. Since the driver is also compatible with Adreno 600 series GPUs, we recommend users to give it a try.

A word of warning though! Turnip drivers don’t have support for Adreno 725 and Adreno 730 GPUs at the moment. Older releases like R5 can be used on these devices instead.

The official Qualcomm driver got some updates, but it continues to be absolutely terrible, so we don’t recommend using it, if at all possible.

Future projects

Project Nice, the implementation of native code execution (NCE) for ARM devices is booting its first games!

And so it begins…

A lot more work is needed before we can even move to the internal testing phase. There are many crashes and softlocks to sort out first, so please have some patience, Android gang.

With the progress on the Album applet going so well, german77 is progressing further into other interesting applets too. Stay tuned.

There’s an easter egg somewhere here!

That’s all folks! Hope you enjoyed this month’s report. See you next time!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report August 2023

GoldenX86 — Wed, 13 Sep 2023 12:00:00 -0300

Tuturu~ yuz-ers. Did you feel that the last report was too short? Well, August was at full throttle! This month offers important graphical fixes, developers working around GPU limitations, several long overdue file system fixes, Skyline framework support, some Android and Apple love, and more!

yuzu Fried Chicken Forever

And Robin.

This is the final piece of Project Y.F.C., the Query Cache Rewrite, and the implementation of Host Conditional Rendering. But before we start, we must explain a few things.

Why do we need a query cache?

Many GPUs expose counters, which are used to gather data from the various commands that GPU executes — things like how many pixels were drawn or how many triangles were generated. Games use queries to fetch and load these counters into memory whenever they need to use them.

yuzu’s query cache is responsible for tracking the values of GPU counters for Switch games and services query requests from the game.

What is it used for?

Some games can make use of this fetched data to further optimise their rendering. For example, SUPER MARIO ODYSSEY optimises the amount of triangles it renders using a commonly used technique called occlusion culling.

Occlusion culling is a feature that disables rendering of objects when they are not currently seen by the camera because they are offscreen or obscured (occluded) by other objects.

In SUPER MARIO ODYSSEY, the game first renders simple boundary boxes that cover all objects that will be rendered on the screen. It then queries the number of pixels rendered to each box, and only renders the real objects whose corresponding boxes had any pixels rendered.

Similarly, Splatoon games use pixel counts to check whose ink a given character is touching. The game tests for both ally ink and enemy ink and if both tests fail, then the character is not standing in any ink.

Medium-well (Splatoon 2)

Development & Challenges

yuzu already had a query cache which was developed many years ago. However, this implementation was not perfect and had many issues. To name just a few:

It could not hold any queries except pixel counts
It failed to write to memory in the correct order
It didn’t invalidate queries that were later overwritten by other query types

Our resident GPU dev, Blinkhawk, set out to rework the query cache to fix these issues and modernise the code. But, as he would later come to figure out, it wasn’t going to be easy.

Recall that the query cache works by running queries on the host GPU. As it turns out, figuring out how to make it work on the host GPU was actually the hardest part of the entire rewrite, due to significant differences between what the Switch GPU does and what host graphics APIs like Vulkan expose.

During development, Blinkhawk ran into two big challenges with Host GPU queries. First, for performance reasons, we can’t submit commands to the host GPU immediately upon processing them. We need to batch them in order to get any reasonable level of speed. This leads to the question: when do we need to perform the queries and sync the memory?

As soon as you start a game, the game begins making queries to get GPU counters. Normally, the results are obtained by the Switch’s GPU immediately after counting is done — when the rendering is done. But games like SUPER MARIO ODYSSEY, which use occlusion culling, make a lot of queries.

So, if we tried to run all those queries and write the results on the host (user’s) GPU in the same way, it would stall the GPU heavily after drawing each scene element to write back the counters.

To prevent this from happening, Blinkhawk synchronises memory whenever the game requests the GPU to wait for commands to finish rendering. This allows for efficient batching, and for GPU commands which occur after the wait to utilize the counter values.

Turn the camera around and the whole city magically disappears (SUPER MARIO ODYSSEY)

Second, in the guest (Switch’s) GPU, counters can be reset at any time or not at all. But this behaviour is not exposed in graphics APIs such as OpenGL and Vulkan. Instead, these APIs have queries that only count a smaller section such as a single draw or multiple draws. This meant that we would need to take all the query results and sum them up, especially if the game never resets the counter.

In the old query cache, we used to sum all of the query results on a single GPU thread, which couldn’t keep up with heavy workloads. As the number of query results increased, so did the time it took to sum them. This was fine for around 50 or 80 queries, but some games can easily make thousands of queries within a single frame.

Blinkhawk experimented with a few different algorithms before finally settling on an implementation based on the Hillis Steele Scan Algorithm.

The result? Well, let the following list speak for itself:

The lantern in Luigi’s Mansion 3 is fixed.

No flashbangs (Luigi’s Mansion 3)

The level of detail in Pokémon Scarlet & Violet is fixed when using High GPU accuracy. No more tree flickering.
Rendering in some Koei Tecmo games like Marvel Ultimate Alliance 3: The Black Order is fixed when using High GPU accuracy.
Glow particles in Xenoblade Chronicles 2 & 3 are fixed when using High GPU accuracy and disabling Asynchronous shader building.

Your browser doesn't support mp4 video. :(

Properly filling the Flame Clock (Xenoblade Chronicles 3)

Shadows in Metroid Prime Remastered are fixed.

Not that Dark Samus (Metroid Prime Remastered)

Performance increased for low-end and/or power-limited hardware in games that make use of Host Conditional Rendering, like Pokémon Scarlet & Violet, Luigi’s Mansion 3, SUPER MARIO ODYSSEY, most Koei Tecmo titles, and many others.
And more!

More GPU changes

GPU changes don’t end there; there’s still quite a bit to cover.

Let’s begin with a surprise port: Red Dead Redemption arrived on Switch and other consoles this month, and with it came a new take on the proprietary RAGE engine, giving our devs some quirks to iron out. You know, the usual with new releases.

The Dynamic GPU Duo (Blinkhawk and Maide) analysed the game and concluded that the reason for the initial broken rendering was caused by the lack of support on Vulkan for masked depth stencil clears.

A depth stencil, or combined depth and stencil buffer, is a type of image that combines a depth buffer and stencil buffer into a single image in memory, speeding up the GPU’s tests to determine if any given pixel will be drawn.

To elaborate a bit further:

The depth buffer stores the distance between the camera and pixel currently closest to it, allowing the GPU to determine which pixels will be covered up by other objects and therefore shouldn’t be drawn.
The stencil buffer is more specialised: it stores a single byte for each pixel, which developers generally use to tag certain types of objects. As an example, the ground may be assigned a value of 1, trees and foliage 2, the player 17, and so on. It’s useful to know which pixels belong to which objects for applying various effects. Here is a great video showing an example of how stencil buffers are used in The Legend of Zelda: Breath of the Wild. The material mask buffer mentioned in this video is a stencil buffer, and is used to prevent effects from applying to undesired materials.

The main use for these buffers is to correctly render scenes with shadows, reflections, and transparency. As the video example shows, many types of graphical effects are made much easier by tagging each pixel, since this allows the GPU to conditionally apply an effect based on the pixel’s material type.

So why were clear operations a problem on Vulkan? In graphics programming, clears are used to reset all of a buffer’s data to a specified value. Graphics APIs such as the Switch’s NVN and OpenGL support applying a mask to clear operations. The mask changes which bits of the image will be affected when the clear is applied: bit positions set to 1 are affected by the clear, and bit positions set to 0 are left alone. For example, if the game needs the upper 4 bits of the 8-bit stencil for a subsequent draw, then it may set the mask to binary 00001111, and clear the stencil with a value of 0. This will cause only the lower 4 bits to be cleared, and the upper 4 bits are left alone, as desired.

OpenGL supports masks on all clear operations, including colour, depth, and stencil buffers. However, Vulkan was designed to support mobile GPUs, and on mobile GPUs, the most efficient implementation may be to entirely discard the old buffer when clearing it. This avoids reading the buffer back from memory, which can be expensive. So Vulkan does not have a direct equivalent of masked clears, and requires clearing the entire “aspect” of an image (colour, depth, or stencil) at once.

Red Dead Redemption was using a masked clear on its stencil buffer. This is why the bug was only affecting grass and bushes: the game was trying to keep those values intact with the mask. But since we translated clears directly from the game to Vulkan clears, we were just wiping out the entire stencil buffer, breaking the bush and grass rendering in the process.

The solution we came up with for Vulkan is similar to a trick we previously used for Persona 5 Royal: use a regular draw, rather than a clear. With a regular draw, we are able to use the built-in hardware support for applying a stencil mask, and produce the same result as OpenGL.

The new system in place works by drawing a fullscreen triangle, which allows the regular stencil hardware to handle masking and buffer writing. Thanks to this, rendering issues in grass and bushes in Red Dead Redemption are now solved. Howdy! You get correct rendering directly to your face, like it or not.

You have some tequilas, then Juan decides he is an adventurer (Red Dead Redemption)

Blinkhawk and Maide also spotted an old regression in how indirect compute dispatch is emulated. For the uninitiated, indirect dispatch is a technique used to allow the GPU to get the amount of work it needs to perform from a result generated by another compute shader or GPU operation, instead of being passed by the CPU at the moment of recording. Avoiding the slower CPU path by letting the GPU work indepedently like this improves performance. Such an independent and strong Tegra X1 GPU. Look at it grow.

Thanks to this late intervention, Mario + Rabbids Kingdom Battle, Mario + Rabbids Sparks of Hope, and Sea of Solitude now render much better: shadows in the Rabbids series have the proper level of shade, and environments in Sea of Solitude are now visible.

This one took a while, eh (Mario + Rabbids Kingdom Battle & Sea of Solitude)

The water in Sea of Solitude requires emulating other very tricky aspects of the Tegra X1, so that’s homework for later.

As Maide also has learnt by now, Accelerated DMA fast path is an eccentric lady. She’s responsible for uploading and downloading image data directly from the GPU, converting image data on the CPU and system memory. But, it can only work when just the right conditions are met. If you don’t tread carefully enough near her, you will get the wrong data, in the wrong place, at the wrong moment. Such was the fortune of Sid Meier's Civilization VI, a game that crashed on Vulkan, and rendered completely broken on OpenGL.

The culprit? Not marking a destination buffer and/or image as modified, causing any future read to not trigger the corresponding download. This resulted in the game reading the wrong data. This quirk of the fast path has now been solved, and a CPU fallback path for cases when an address isn’t valid for a given image format has been added. Strategy fans can now nuke each other to their heart’s content. Gandhi says peace was never an option.

Just one more turn (Sid Meier's Civilization VI)

For our cultured players out there, Blinkhawk and byte[] bring us much-awaited fixes for Bayonetta 3. They involve emulating how the Switch’s GPU drivers emulate a feature the hardware doesn’t support. Yep.

This story revolves around textureGrad, an OpenGL function that does texture lookups over multiple mipmap levels based on the supplied angle, and returns a single texel.

Well, the Maxwell-based GPU on the Tegra X1 of the Switch can’t do this natively for 3D textures, so it uses the SAM and RAM instructions to enter into and leave a special mode, which we don’t know much about — but we do know it is used for calculating the derivatives for the texture fetch.

By looking for this instruction pattern, Blinkhawk implemented preliminary support for the fog and clouds in Bayonetta 3. byte[] later fixed the implementation to make it behave the way Blink initially intended, and to avoid crashes on Mesa and RDNA3-based GPUs (AMD Radeon RX 7000 series).

Mystic Mist (Bayonetta 3)

Not intending to stop there, Blinkhawk also improved the logic for discarding unnecessary writes in the buffer cache, and improved how the size of the index buffer (where indices of vertices to form meshes is stored) is estimated. The result? A 69% or higher performance boost in Bayonetta 3, depending on the system specs. Nice.

Ara, ara (Bayonetta 3)

byte[] discovered that yuzu’s implementation of nvnflinger, the service responsible for presenting to screen, was missing a scale mode option, preserve aspect ratio. Implementing it solves the rendering of Gunvolt Chronicles Luminous Avenger iX in its base version.

Hell yeah, sprites! (Gunvolt Chronicles Luminous Avenger iX)

A user reported an unknown change from a long time ago was causing AI: THE SOMNIUM FILES to constantly crash. byte[] found the culprit was hiding in how mappings were being aligned during allocation but not deallocation, a bug originally discovered by ex-Skyline emulator developer bylaws. Regression solved, game stable, case closed.

Elementary, my dear user (AI: THE SOMNIUM FILES)

And finally, to close this section with what is more of a build process change than a graphics code change, vonchenplus added MoltenVK as an external dependency to yuzu’s CMake settings, allowing Apple users to automatically get the latest version of this translation library when building yuzu on their Vulkan-starved machines. (AGXV, anyone?)

Let’s begin with simple stuff (DRAGON QUEST III The Seeds of Salvation)

Properly keeping up with MoltenVK updates allows macOS builds to run some basic games, but there’s still much to do to get the forbidden fruit company’s devices up to speed.

OpenGL-specific improvements, which also improve Vulkan

That’s right, Mesa and NVIDIA Fermi/Kepler users, it’s your turn to get some love. Epicboy is back with some great changes for the ~~old~~ classic API that started it all, OpenGL.

First on the list is a major overhaul for GPU ASTC decoding, for both OpenGL and Vulkan APIs. Code optimizations in several areas of the compute shader-based decoder improved Vulkan ASTC decoding performance by up to 60%, but it made OpenGL on NVIDIA 15 times faster, making it now slightly faster than Vulkan at decoding ASTC textures.

Subtle jump

GPUs which were left behind on Vulkan support can now enjoy much smoother performance in titles like The Legend of Zelda: Tears of the Kingdom, Bayonetta 3, Luigi’s Mansion 3, etc.

To get the most out of this change, the ASTC recompression method must be set to Uncompressed, and Enable asynchronous presentation should be enabled if you’re using Vulkan. Both options can be found in Emulation > Configure… > Graphics > Advanced.

toastUnlimited later blocked Mesa’s native ASTC decoder, as it is now considerably slower than our implementation.

And lastly, Epicboy solved what was a very common issue for Pokémon Legends: Arceus players before we made Vulkan the default API. Sit down, kids, it’s story time.

In the not-so-far-away good old days, yuzu was only experimenting with an incomplete and immature Vulkan backend, there was no LDN/LAN support, and an Android release was considered to be a fever dream. Back then we used the OpenGL API by default, and out of its three options for shader backends, GLASM was the shader backend of choice, since it didn’t affect incompatible drivers — it’s an NVIDIA-only “feature” and any other driver would automatically revert to the vendor-agnostic GLSL. This provided NVIDIA users the best experience at the time, with the lowest shader build times available, until Vulkan improved enough to be the full replacement it is today.

A very common report during these migration days was that character shading in Pokémon Legends: Arceus was wrong — it either introduced weird motes to characters, or they looked completely devoid of any form of lighting. This problem was quickly found to be rooted in GLASM.

Since GLASM was, and continues to be, almost impossible to work on due to its complete lack of tools to debug and assist development, no developer wanted to touch it after Rodrigo introduced it. As he later left for greener pastures, this has resulted in our GLASM shader backend becoming entirely unmaintained.

Well, enter 2023, and Epicboy rolled up his sleeves and got to work. He discovered that the issue was in how GLASM handled transform feedback. By implementing support for multiple transform feedback buffers, he has not only solved the issue in the only good main Pokémon release in the Switch (writer’s opinion, you can’t prove me wrong), but most likely many other modern Switch games that rely on transform feedback to render.

Still good graphics for the Gamecube (Pokémon Legends: Arceus)

We hope our warriors still rocking the never-dying GTX 400 to 700 series GPUs benefit from these changes.

Skyline framework: Part 3

After a long, looong wait, support for the Skyline framework, and with it, support for the ARCropolis modding framework for Super Smash Bros. Ultimate has finally landed! But we’re getting ahead of ourselves. Let’s see how byte[] made this possible.

As part of implementing a security technique called ASLR (Address Space Layout Randomization), there is a large range of addresses that a program’s code can be loaded at on the Switch. In fact, even though the Switch only has 4 GB of physical memory, the size of the region where program code can be virtually mapped can be as large as 512GB. Programs shouldn’t make assumptions about where they are loaded inside the address space, because they can be shifted around anywhere inside this range on the console. As it turns out, the Skyline framework requires that the program not be loaded at the very start of the region, but yuzu always loaded it there, causing it to reliably crash. byte[] worked around this limitation of Skyline by shifting the code load address further into the ASLR region, allowing room for it to operate.

yuzu’s code responsible for handling service calls from guest code is not exactly in ideal shape. One particularly annoying issue from the early days of the emulator is a lock which prevents a service object from receiving concurrent requests from different sessions. Since the implementation is incorrect (the lock should not be present at all), but a lot of existing yuzu code depends on it, byte[] instead avoids locking only around calls to socket interfaces, avoiding a deadlock when Skyline’s TCP logger is active. More work remains to be done to remove this service lock once and for all.

With these changes, the Skyline framework is operational, but a bit more work was needed to get ARCropolis up and running, and the Smash modding community happy. Thankfully, byte[] didn’t stop there, and continued implementing the required changes.

ARCropolis used to incorrectly initiate the handshake when connecting to an SSL/TLS socket without first setting a hostname. This has been fixed in ARCropolis’s dependencies, but most users have not updated yet to the corrected releases, so yuzu has to support this behaviour.

And lastly, yuzu was missing support for HTML manual mods, so byte[] implemented support for that too.

The end result after these few fixes is that most mods for Super Smash Bros. Ultimate are now working!

Let the modding begin! (Super Smash Bros. Ultimate)

Bocchi-chan vs Melia, the fight of the century (Super Smash Bros. Ultimate)

Happy modding! Here’s a tutorial for those interested.

Project Terra?

Yep, byte[] asked for a rename. From now on, Project Terra will be the name of the effort to fix the current virtual file system emulation implementation while Project Gaia is in the works.

Why the rename? Because we have a lot of fixes to tell you about. To begin with, yuzu now supports sparse and compressed NCA games! This means a long list of titles whose eShop releases couldn’t previously boot are now either running or perfectly playable, and their RomFS can be fully dumped.

Here’s a nowhere-close-to-complete list of now-working eShop titles:

Splatoon 3
Bayonetta 3
Atelier Ryza 3: Alchemist of the End & the Secret Key
Double Dragon Gaiden: Rise of the Dragons
OneShot: World Machine Edition
Skullgirls: 2nd Encore
Everdream Valley
Magical Drop VI
Hatsune Miku - The Planet Of Wonder And Fragments Of Wishes
MLB The Show 23
Sports Story
Front Mission 1st: Remake
Cursed to Golf
Ruined King: A League of Legends Story
Mega Man Battle Network Legacy Collection
And many more!

Support for gamecard dumps with a prepended key area has been added too, thanks to byte[]. This allows using dumps with the option to dump the key area enabled.

Nice bike (Fuuraiki 4)

Installing updates and DLC for multi-program applications (such as a game launcher with several games inside) didn’t work properly on yuzu. This meant games like Super Mario 3D All-Stars would only launch the base game version no matter what the user did. The current virtual file system implementation can’t properly support this, which is one of the many areas Project Gaia is geared to fix. To bypass this limitation, byte[] creates synthetic update metadata inside yuzu, allowing the update/DLC to pass through and load correctly.

FearlessTobi fixed an old regression affecting how the game’s size is displayed on the game list when using games dumped with an outdated method. How old is the regression? Well, it’s 5 years old by now.

FearlessTobi also fixed a bug in how an error is handled when a game tries to rename a file to a name that already exists. This was causing GRID Autosport to crash on boot.

Running in the 90s (GRID Autosport)

Not stopping there, FearlessTobi also fixed yuzu’s command line arguments to properly load updates and DLC when booting a game — for example, when using a script.

Users reported that some RomFS dumps from games don’t always include all game assets, with one example being KLONOA Phantasy Reverie Series. byte[]’s investigation showed that several areas of the RomFS dump code were… of low quality. After a moderate rewrite, RomFS dumps of multi-title games should now include all assets.

Audio, input, and core changes

Let’s start with the sole input change of this progress report. german77 almost broke his streak!

Updating SDL to version 2.28.2 fixed issues affecting Xbox controller trigger motion events and their rumble while the program runs in the background. 8BitDo gamepad mapping while in XInput mode was fixed for Linux. And a controller lockup that happened when initialising some unofficial PS4 controllers is now fixed.

Some users’ machines have improperly configured audio devices, which can lead to games locking up on boot. This lovely behaviour forced Maide to work on a test to run early in the boot process to see which audio backend can properly start the audio device. If the device fails to initialise with both cubeb and SDL, the null backend is selected and the game continues to work, just without any audio output.

If you find that a game has no audio but is otherwise working, you should check your drivers, check any intermediate programs like equalisers, and check your OS settings for issues.

Opus is a lossy open-source and royalty-free (as it always should be) audio format used by several games. Like with the VP9 video format, its implementation in yuzu is not as simple as just playing the file. By implementing the OpenHardwareOpusDecoderForMultiStreamEx and DecodeInterleavedForMultiStream service methods (Opus multistream support), FearlessTobi ensured games like MLB The Show 22 are now playable.

Implementing the GetWorkBufferSizeExEx service method, on the other hand, allowed Sea of Stars to boot.

Nothing beats the look of a classic RPG (Sea of Stars)

If anyone experienced audio related crashes (specifically related to audio effects) in games like The Legend of Zelda: Tears of the Kingdom, SUPER MARIO ODYSSEY, and some others, well, with the help from ChiefGokhlayeh, Maide found the broken node Id index that caused the problem.

Still fighting the war of shutting down yuzu in a sensible manner, byte[] changed the shutdown timeout to more closely match the behaviour of the Switch. Most games now exit within one second.

Another area where shutting down has improved, this time related to the Skyline framework, is cancelling pending socket operations caused by the TCP logger. One of the operations can remain waiting for a host to be accepted. This will never complete once a shutdown event is triggered, so a swift termination is issued now.

Android augmentation

Besides all previously reported changes, Android got its share of specific bugfixes and UI changes too, courtesy of t895:

Miscellaneous settings tweaks, including displaying settings values in list view, reducing the opacity of non-editable settings, removing some unnecessary default buttons in slider dialogs, and a few other minor changes.

These settings can't be changed while running a game

Show associated values for home settings.
Changes to the initial setup, showing if a step was completed, and automatically moving to the next page on completion.

Easier setup!

Automatically rotate the screen between landscape and reverse-landscape.
Search for programs up to 3 subfolders deep.
Use appCategory to report yuzu as a game. This should improve game launcher detection, but surprisingly, it’s not enough to make Samsung’s Game Launcher detect yuzu.
A settings rework, including better material animations, hiding paired options, adding a settings search function, and improving restore states for dialogs properly.

Cleaner and more functional

Fixing some activity issues, like the surface appearing stretched when changing orientation, or starting a game in landscape mode and then switching to portrait.
Adding new loading and closing animations.

Showing the progress

Support intents to emulation activity, so users can launch games from other apps like Daijishō.

For those who prefer it

Adding the ability to create dynamic app shortcuts, so users can make per game icons.

A faster way to get in-game!

Fixing a bug in the game content installer that would lead to a crash when trying to install an update or DLC.
And more!

Also joining forces in the Android effort, byte[] fixed a virtual file system bug that made any game with updates installed fail to boot after merging his earlier changes to support compressed and sparse NCAs.

Desktop UI improvements

The desktop side of things also got its share of developer love.

Newcomer mdmrk brings us a very requested feature: per-game play time tracking! It’s shown in the game list as a new column. Thank you!

Power level reading

Since the introduction of the screenshot feature, yuzu has only saved captures in a 16:9 aspect ratio, regardless of the selected aspect ratio in graphics settings. Also, the resolution of the captures was always based on the chosen resolution multiplier value; if 2x was in use, any capture while playing in docked mode would be 3840x2160 in size.

With motivation from some recent mods that bypass our scaler and render games in 1x resolution directly at 4K, toastUnlimited added configuration options for screenshot resolution, along with considering the aspect ratio selected by the user. Now users can set the screenshot resolution in Emulation > Configure… > General > UI > Resolution. Auto will use the previous logic of using the resolution multiplier value, but many other resolution options can be picked. Additionally, what the user selects in Emulation > Configure… > Graphics > Aspect Ratio will determine the aspect ratio and resulting resolution of the screenshots. Feel free to experiment, and save your best gameplay moments!

A picture is worth a thousand words

Per-game settings are a great way to customise the settings and mods of each game. One option in a weird spot was Console mode — whether a game was played in docked or handheld mode. The old implementation relied on controller profiles: the user would set some controller mapping, the type of controller, the console mode, save all of this as a profile, and then set each game to use the preferred controller profile. The problem with this approach is that it forces users to save different controller profiles, when in most cases a single one is used, for example, a Pro Controller profile using a Sony Dual Sense. To simplify this particular situation, toastUnlimited added a Console Mode to the per-game system properties. Much easier, right?

For even more customisation

Hardware section

This section has been pretty calm lately. For the most part, drivers have been behaving and not introducing critical regressions recently, and the Mesa Turnip driver for the Adreno Android players has been progressing healthily. It’s not fully stable yet, but rendering and performance are in a good spot. There’s only one vendor to discuss this time, and it is…

AMD, and the D24 situation

We continue our investigations into how to deal with the lack of hardware support for the D24 depth format on Red Team hardware.

Some fun and totally-not-evil experiments (faking lack of support with an RTX 3060 Ti) proved that while the D24 glitches are easy to reproduce on compatible hardware by just commenting out some lines, we also confirmed that the vertex explosions affecting Xenoblade Chronicles 3 in its DLC, Future Redeemed, and in the Pentelas region of the main game are not caused by the lack of D24 on AMD cards. Any other GPU vendor with D24 support disabled renders those sections perfectly fine, leaving us again with no clue on what Radeon GPUs hate about this particular game.

On Windows, OpenGL continues to be the only alternative for Red Team users for the time being. Mesa, on the other hand, seems to have solved the issue (at least on Polaris hardware) with their latest version, so “just use Linux” seems to be a way to fix an AMD-specific problem once again.

But it’s not all bad news! A new Vulkan extension, VK_EXT_depth_bias_control, which is for now only available on the Linux Mesa RADV driver, allows yuzu to properly fake D24 support, fixing the rendering issues on games like Pokémon Sword & Shield, Super Smash Bros. Ultimate, and Mario Tennis Aces, among others.

Blinkhawk added a preliminary implementation supporting VK_EXT_depth_bias_control to yuzu for testing. We hope AMD adds support for it in their Windows drivers, as it is known they use the feature internally for OpenGL.

Hardware support for the right formats matters (Pokémon Sword)

As a small anecdote about Super Smash Bros. Ultimate, we had to hardcode a value to allow AMD cards to render this game not long after the introduction of our Vulkan API. The story with D24 has been with us since the very beginning.

Samsung Xclipse 920

Technically it is the same vendor, right?

Recent changes in which Vulkan extensions are mandatory and which are optional made this AMD RDNA2-based GPU work with the Android releases, adding another compatible vendor to the group of decent-enough SoC GPUs, along with Adreno and Mali. Exynos 2200 users can now enjoy their Switch games on their Android devices!

Future projects

Blinkhawk is back to proposing ideas which are so crazy, we could never properly explain them here. And both byte[] and Morph are cooking interesting projects for after they finish their current challenges.

That’s all folks! Thank you for taking the time to read until the end. We hope to see you next time!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report July 2023

CaptV0rt3x — Sun, 13 Aug 2023 06:45:00 +0530

Hey there, yuz-ers! Welcome back to our monthly report on all the improved features, performance gains, and bug fixes we’ve made. Let’s jump right in!

Aliens and ghosts are real… and they run on Unreal Engine!

The wait was long, but worth it. Another game in the charming Pikmin franchise has finally arrived on Earth, just in time to join the wave of UFO reports!

Imagine a crossover with Toy Story, it would explain The Claw! (Pikmin 4)

This time, Pikmin 4 decided to use Unreal Engine 4, which guarantees good performance and quality on the Switch. However, this engine also guarantees headaches for emulating its use of sparse textures, as well as guaranteeing instability for NVIDIA GPU users running Vulkan, as previous games have demonstrated.

byte[] identified and fixed a regression caused by a recent change to the texture cache which severely impacted stability on NVIDIA GPUs, causing constant device losses (the driver cutting off the GPU from rendering, resulting in an emulator crash).

Moss seems tired (Pikmin 4)

emufan found that hardcoding the total number of texture buffers to 16 was causing crashes in some Unreal Engine 4 games and bumped up the count to 32.

Good thing this game didn't cross paths with Pikmin (Master Detective Archives: RAIN CODE)

This change has not only helped Pikmin 4 but also Master Detective Archives: RAIN CODE, another recent release using this same engine.

Yeah, good name for a train, I'll board it in Dracula Station (Master Detective Archives: RAIN CODE)

Many things have improved, but there’s still a lot of work remaining to improve the compatibility of games using this popular game engine!

Per-game configurations - Reimagined!

If you’re experienced with yuzu, it is very likely that you’ve seen and used per-game configurations. But if you didn’t know, yuzu supports per-game configurations as an easy way to set game-specific settings, without having to change your global settings for every game you start. For the games which require GPU accuracy to be high instead of normal, or for games which work best with OpenGL over Vulkan, per-game configurations allow you to easily override settings like these.

So, what’s new, you ask? The brains behind this feature’s implementation and our trusty slice of toast, toastUnlimited, has started working towards a future where yuzu could select a game-specific configuration file curated by the community, and then apply those settings by default! The ultimate goal is for users to be able to apply the optimal settings for any game by default, without having to tinker with the many, many configuration options we have today.

Sounds exciting, right? Heck yeah! While toast was finalizing his designs, he quickly ran into a road-block of his own design: our current per-game configuration system. The existing system’s design made it difficult to programmatically define and override each setting in multiple places across yuzu’s backend and frontend systems.

toast decided to take the challenge head-on and rewrote the entire settings backend to improve it, all while making it programmatically easier to define and implement any setting. Thanks to these changes, developers now only need to write out the UI text for a setting and the system will do the rest (reading, writing, representing in the UI, resetting global state).

This also had the benefit of providing the perfect opportunity to rework several parts of the global settings UI! For example, System settings now includes Multicore CPU Emulation support, all three possible values for Memory Layout, and Limit Speed Percent.

Important changes to System settings

The Graphics section also got its fair share of changes. Besides reorganizing the different options, the new ASTC Decoding Method option now lists our 3 different alternatives for handling that pesky ASTC format: CPU, GPU, and asynchronous CPU decoding.

Graphics settings also got some love

There are plenty of changes here, but enough about the global settings! toast also changed how per-game configurations are updated. They will now show an X button on the right of each setting if they were modified from the global value, allowing you to quickly revert them if needed.

Graphics settings also got some love

Stay tuned for follow-up changes to our settings, building on top of this new foundation!

Graphics changes

Maide continued his efforts to improve performance through optimization and his latest changes further optimize one of his earlier optimizations. We heard you like optimizations, so we put optimizations in your optimizations so you can optimize while you optimize. While the original changes aimed to reduce memory allocations while copying data from the guest to the host (user’s PC), the latest changes remove data copying entirely, resulting in nearly 10% performance boost in parts of Super Mario Odyssey, such as the Metro Kingdom area. Xenoblade Chronicles: Definitive Edition also sees similar gains.

byte[]’s latest fix significantly improves the slowest shader compilation times in Splatoon 3, reducing it from 30 seconds to about 4 seconds. A recent change to our texture cache’s AccelerateDMA logic was identified to have been causing device losses and has been since been reverted.

She calls it Sasha (Splatoon 3)

Input Changes

german77 continued his reverse engineering of the Switch NFC service and improved yuzu’s code accuracy. He also fixed a bug, which would cause mice to stop working after some time, by avoiding an accidental division by zero.

Newcomer SuperSamus’s first contribution to yuzu was to remove a workaround on button mapping within yuzu which used to invert the face buttons mapping. With these changes, SDL properly uses the native A/B and X/Y mapping of Nintendo devices. Thank you!

Note: This change BREAKS controller configurations for those using Nintendo controllers without the direct driver.

Android changes

bunnei implemented changes to fix an issue where Turnip drivers would fail on certain Snapdragon devices and added checks for broken Qualcomm 7xx drivers. This means that any Snapdragon user should be able to run Turnip drivers now. Links are provided in the Hardware section later in this article.

t895 disabled the prompt to save user data when uninstalling yuzu. This feature often caused issues when users attempted to use different APK versions.

t895 also added some helpful error prompts to inform users why certain buttons were disabled on some devices. The most common case is Mali or Xclipse users trying to install custom drivers, a feature that is only available for Adreno users, at least for now.

Your Mesa driver is in another castle

Miscellaneous changes

Apart from the ones highlighted above, there have also been several smaller changes that don’t necessarily fit nicely into a single category. So let’s quickly discuss them below:

FearlessTobi added detection for compressed and sparse NCAs within yuzu’s filesystem. Instead of failing silently, yuzu will now log this info and abort the parsing.

toast added a new Linux build script which added the libraries required to enable Wayland support in our official AppImage releases.

Not stopping there, toast fixed a memory leak with the new timezone data generator. This would happen when games tried to ask for timezone information too many times. This was resolved by keeping track of the generated timezone binary instead of recreating it repeatedly.

toast also bypassed an MSVC build crash on Windows version 10 1809 LTSC from the new timezone binary changes by temporarily disabling it for MSVC until there is a solution from Microsoft. The reason, for those interested, is documented here.

byte[] implemented missing service functions, fixing a bug that caused Quake to fail to launch, and fixed a bug that resulted in Splatoon 3 having an endless loading screen when LAN was enabled.

byte[] also fixed an issue within yuzu’s filesystem which resulted in either corrupt save data or failing to save data.

A previous merge caused games with non-ASCII titles to crash on Linux due to DBus expecting a UTF8 string. This has now been fixed. Thanks zeltermann!

Morph fixed a bug that broke the game installation progress bar after the recent buffer size increase by refactoring the progress bar calculation code.

Morph also fixed a bug where yuzu would crash on systems with weak CPUs running at very low clock speeds due to yuzu’s strict requirements on CPU clock precision.

german77 eliminated almost 2GB of memory usage in some circumstances by fixing a memory leak within Discord presence code, presumed to be caused by cpp-httplib.

german77 also fixed a crash in yuzu’s gamelist that happened when you launched yuzu without keys.

yuzu newcomer and Citra expert, Steveice10, implemented a few improvements to Vulkan surface creation on macOS. comex submitted a few fixes and workarounds for macOS to resolve a few undefined behaviour errors. Thank you both! This doesn’t mean full MoltenVK support yet, but the gap is now smaller.

Hardware section

NVIDIA

The latest driver released at the time of writing, 536.99, is stable and also seems to have improved Vulkan performance a small but measurable amount, between 3% and 7%. Free performance is free performance.

AMD

It’s July and we have another new AMD GPU driver with yet another extension causing issues. If you recall from our June progress report, we reported that the latest AMD drivers had broken a Vulkan feature - extendedDynamicState3ColorBlendEquation, and we had to temporarily disable usage of it on AMD driver version 23.5.2 and above.

Fast-forward to July, and it’s still broken for some. Giving credit where due, AMD did fix this issue with driver version 23.7.2, but only for RDNA2 GPUs (RX 6000 series). GCN4, also known as Polaris (RX 400 and 500 series), are confirmed to still be broken. In light of this, and the fact that the fixed driver still reports the same Vulkan version, we reverted our revert of our original change from June and have currently disabled usage of this extension on all AMD official drivers until this is fixed and has a new version number.

Turnip

Mesa never slows down its progress, and K11MCH1’s AdrenoTools releases are a true blessing from the fairies.

For Adreno 600 users (Snapdragon ### series), progress is steady. But the best news is for A700 users (Snapdragon # Gen # series), which now see much improved rendering and performance on the Mesa Turnip drivers.

Some games still require the proprietary Adreno driver to be more stable or faster, but at this rate of progress, we’ll most likely see this change soon!

Future projects

Behind the counter, there has been great progress in some key projects. The last missing piece of Project Y.F.C., the Query Cache Rewrite, was released but we’ll talk about it next time. We’re sure Xenoblade and Luigi’s Mansion fans will love it! byte[] continues to improve the current file system emulation — maybe some particular games will start working soon? And Maide has some interesting ideas to implement in the shader cache code.

That’s all folks! Thank you for reading until the end. See ya next time!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report June 2023

GoldenX86 — Mon, 10 Jul 2023 12:00:00 -0300

Hello again, yuz-ers! Our devs, old and new, show no signs of slowing down. This month we have general performance and stability improvements, many graphics bug fixes, Android gets its first wave of improvements, and much more! Helmets on, let’s ride.

Before we dive into the report, we have some important news to share. We’ve received reports that some users have been experiencing crashes when trying to use Vulkan or change settings. The culprit is Overwolf, a mod manager/overlay that comes with a faulty and outdated Vulkan layer, messing up the GPU’s Vulkan driver. We strongly advise users to uninstall Overwolf until they have fixed their Vulkan layer.

Now that we’ve cleared that up, let’s get started.

Illusion of Time

While we implement many features of the Switch operating system, and can boot most games without a firmware dump, some games still require one. This is necessary for things like Mii models or to properly render foreign scripts and button fonts. The firmware files also include the resources needed for proper time zone support.

Thanks to the amazing work of toastUnlimited, yuzu now ships with virtually all time zone data that the Switch has by default!

In the past, yuzu would pretend that the system was in GMT, and then adjust the universal time by the local offset on the guest. While this usually worked, it’s not accurate to how the Switch reports times.

The default “Auto” time zone setting will now send a location-accurate time zone to the guest (instead of following the old GMT rule) using the synthesised time zone archive. The new system also sends a correct representation of the universal time, regardless of whether there is a firmware dump or not.

Now, while Linux had few issues with the new system (aside from a frustrating issue with Flatpak), Windows has some specific requirements. There are two important things to keep in mind:

When the changes were released, users needed to run at minimum a 2019 version of Windows 10, with 1809 no longer compatible. For LTSC users, this meant only the newest 2021 release would work. We later implemented a solution for this. If you’re running Windows LTSC 1809, or for some reason blocked Windows Update on a regular Windows version, remember to update to the latest yuzu version.
You need the latest Visual C++ 2022 redistributable. Download it from this link: https://aka.ms/vs/17/release/vc_redist.x64.exe

Don’t forget to set your clock correctly!

Graphics changes

This month has been full of GPU changes, so let’s start with a simple one.

There’s never rest for the wicked, so Blinkhawk makes good use of that extra time doing what he does best: pulling big changes out of thin air. In this case, he investigated what happens if a memory page is being used by the GPU and written by the CPU at the same time. Lovely little bugs that have been haunting us for half a decade, that’s what happens!

What Blinkhawk adds here is a mechanism to register small CPU writes that sneak through while the page is being accessed by the GPU, properly invalidating the page if needed. The following bugs have now been fixed as a result:

Fixes the vertex explosions affecting Pokemon Scarlet & Violet. Use High GPU accuracy.

Your browser doesn't support mp4 video. :(

No explosions near the Academy, Megumin! (Pokémon Scarlet)

Fixes the slow rain and snow particles in The Legend of Zelda: Breath of the Wild & The Legend of Zelda: Tears of the Kingdom.

Your browser doesn't support mp4 video. :(

It’s raining Chuchus out there (The Legend of Zelda: Tears of the Kingdom)

Fixes some particle corruption exclusive to Tears of the Kingdom seen, for example, while teleporting.

Your browser doesn't support mp4 video. :(

It’s not perfect yet, but it’s almost there (The Legend of Zelda: Tears of the Kingdom)

Fixes the erratic movement of some particles in SUPER MARIO ODYSSEY.

Your browser doesn't support mp4 video. :(

Even the particles dance in this game (SUPER MARIO ODYSSEY)

Fixes the hilariously wrong eyebrows affecting some characters in Xenoblade Chronicles 3, like Noah and Sena. Writer’s note: I will miss this one, it was fabulous.

Your browser doesn't support mp4 video. :(

Hey, Noah’s eyes are up here (Xenoblade Chronicles 3)

Fixes the corrupted save thumbnails in Xenoblade Chronicles: Definitive Edition.

That’s Dunban over there! (Xenoblade Chronicles: Definitive Edition)

And more!

Here’s some good news for the low-RAM folks!

Since native Switch game shaders can’t be run directly on the user’s GPU, yuzu has to recompile them into an intermediate representation (IR) which is a middle format that can be optimized and then converted to a shader that users’ GPU drivers can actually handle (SPIR-V/GLSL/GLASM). For performance reasons, a significant amount of memory is preallocated to store these blocks of IR, and the old implementation would use 34MB per thread, twice.

68MB per thread may not seem like a lot, right? But this allocation is made as many times as the total thread count of the CPU, SMT included. With some quick maffs, you can see that a Ryzen 3600 would gobble up 816 MB of system RAM, a Ryzen 7950X or an i9 13900 would need 2.2GB, and many phones with 8-threads SoCs would lose 544MB to these allocations. This is, of course, not much of a problem for users with 32GB of system memory, but for 16GB or lower, particularly 8GB RAM users, this is a very steep price to pay. It is not uncommon to see a laptop with only 8GB of RAM and a 12 thread-equipped Ryzen 5500U for example, or 8GB phones and tablets.

byte[] wasn’t happy with this behaviour, so he replaced it with a much more memory-friendly one. The current use per-thread is about 134KB now. That’s a whopping 99.6% reduction!

One of the ways to make games look better is by forcing higher values of anisotropic filtering, which makes textures at steep angles look much sharper. The old implementation had to skip nearest-neighbour samplers on mipmapped images to avoid rendering issues in games like Fire Emblem: Three Houses and ASTRAL CHAIN. This decision meant that many games like Metroid Prime Remastered would see no benefit from using higher values of anisotropic filtering, to the point that Wollnashorn would create mods to force the textures of Breath of the Wild and Tears of the Kingdom to trilinear filtering, allowing yuzu’s anisotropic filtering setting to do its job.

While that was a nice workaround, Wollnashorn wasn’t satisfied with this solution, so they improved the heuristics used to allow anisotropic filtering on any texture format without rendering issues, improving image quality, and as a bonus, even fixing an old rendering bug affecting Mario Kart 8 Deluxe too!

More accurate and better looking! (Mario Kart 8 Deluxe)

Now you can safely select 16x filtering and enjoy the results, which you can find in Emulation > Configure… > Graphics > Advanced > Anisotropic Filtering:

Anisotropic Filtering at 16x may affect performance on integrated GPUs, something to keep in mind

In another batch of old issues fixed by Blinkhawk, he managed to pinpoint the cause for Unreal Engine 4 games having broken textures and crashing when running with Vulkan, a problem that mostly affected NVIDIA cards.

Unreal Engine 4 is a big fan of sparse textures to the point of really pushing the limits of the texture cache code. A bug affecting how NVN virtual images were being remapped after sparse memory gets converted to regular mapped memory caused games like SHIN MEGAMI TENSEI V, Bravely Default, the Pikmin 4 Demo, and many others to display corrupted textures at random.

Optical camouflage gone wrong, clearly Protag-kun here is not as good as major Motoko (SHIN MEGAMI TENSEI V)

It's not a phase, mom! (BRAVELY DEFAULT II)

Fixing this regression allows games to render properly once again.

Speaking of the Pikmin 4 Demo, the game taught us that while you can do it, 3D textures really don’t need to be accelerated by DMA operations. In order to avoid crashes in Unreal Engine 4 games like this, the LLE slow code path will be used instead.

More proof that games don’t need high requirements to be fun (Pikmin 4 Demo)

This pull request introduced a regression that affected rendering in Metroid Prime Remastered. Thankfully, gidoly quickly solved it by merging both approaches, old and new.

Chozo Suite error 404: Texture not found (Metroid Prime Remastered)

While working on these crashes, byte[] changed the behaviour of the Vulkan memory manager to prefer (instead of require) using device local memory (VRAM) for image memory, which ends up allowing up to 50% of shared memory (system RAM) to be used by the GPU. This simple trick makes most Unreal Engine 4 games stable, but it is very likely it has the cost of making VRAM intensive games stutter more often once VRAM gets close to full, for example, when running The Legend of Zelda: Tears of the Kingdom on a GPU with 4GB of VRAM or less.

It’s a high price to pay considering Tears of the Kingdom is by far the most played game on yuzu, but we think the huge number of games that benefit from stable gameplay outweighs the latest Zelda stuttering a bit more on low-end GPUs with dedicated VRAM.

What better way to prove that statement than by continuing to write about The Legend of Zelda: Tears of the Kingdom! Ever since its release, the modding community has been working tirelessly to improve the rendering quality of the game. During their testing they discovered that any rendering resolution mod higher than 1008p would break ambient occlusion effects when scaled above 1x resolution.

byte[], with some help from Wollnashorn’s initial investigation, adjusted the rescale size thresholds, and now the game can be safely upscaled with mods to reach that glorious real 1080p rendering—and can then be scaled with yuzu’s internal resolution scaler to any desired resolution.

The ambient occlusion of this game may not be perfectly implemented, but it really helps with the ambiance of the scene (The Legend of Zelda: Tears of the Kingdom)

Now you can enjoy the game in all its splendour, without sacrificing any details.

While profiling the GPU code, Maide found a way to squeeze more performance out of the game. By combining vertex and transform feedback buffer bindings instead of binding them individually, thousands of API calls per frame can be avoided. This leads to a small 1-3% improvement in framerates in general, but it manages to boost Tears of the Kingdom by a whopping 17%. The tests were performed with a Ryzen 5 5600X, so it’s very likely that newer CPUs will see even bigger gains.

By adding some additional samples checks when finding the correct render target, vonchenplus fixed the device loss crashes that affected Fire Emblem Engage while playing in handheld mode, as well as the squished character portraits that affected some systems. This change also fixes incorrect colour and shadows in SpongeBob SquarePants: The Cosmic Shake.

That portrait wasn’t very engaging, your excellency (Fire Emblem Engage)

vonchenplus also fixed resolution scaling issues affecting Titan Quest and Crysis Remastered; glitchy picture-in-picture bug begone!

Yes, we can run Crysis, now at 4k (Crysis Remastered)

OpenGL also got some love once again thanks to efforts made by Epicboy.

In a surprising discovery (or as stated in the pull request description, “here’s a fun one”), Epicboy found out that NVIDIA’s OpenGL drivers get a significant performance boost in shaders using local memory if the previous shader that was executed uses a lot of local memory. This seems to be an OpenGL-specific quirk in the NVIDIA driver, as Vulkan is not affected.

This beautiful driver trick gives a 2-10% performance increase depending on the size of the GPU.

But the OpenGL gains didn’t stop there. Persistent Buffer Maps were already in use by the texture cache, but extending their use to the buffer cache more than doubles the performance of OpenGL on NVIDIA hardware!

Fermi and Kepler users rejoice (tested with an RTX 3070)

We expect a similar improvement when using Mesa drivers on Linux.

While most NVIDIA users are advised to stick to Vulkan now, as it is still faster and with WAY less shader stuttering, these changes should greatly help Fermi and Kepler (GTX 400 to GTX 700 series) users that, due to driver support reasons, must still use OpenGL. Or those who just like to live dangerously.

With the introduction of the resolution scaler, we added FXAA as a possible anti-aliasing filter, a preferred option over SMAA for games that already look too crisp, or simply for users that can’t afford the performance loss of SMAA. Its Vulkan implementation has had issues with colour banding since release. Not satisfied with that, byte[] solved the problem by using a higher colour bit depth. Sometimes, solutions don’t need to be complicated.

For those old enough to remember what it felt getting a GPU that could do 24-bit colour (SUPER MARIO ODYSSEY)

Many Switch games support dynamic framerates, or get mods that support dynamic framerates, meaning unlocking the framerate (by default by pressing Ctrl + U) is a great way to get a much better and smoother experience while emulating those games. By the way, here’s a list of such games for those curious.

One unwanted side effect with this is that video playback won’t be able to keep up with the increased framerate, often desynchronizing audio while still having to wait for the video to end. To mitigate this, byte[] added a toggle in Emulation > Configure… > Graphics > Advanced called “Sync to framerate of video playback” that, when enabled, will dynamically re-enable the framerate limit while a video cutscene is playing.

Totally not the same pic from earlier

While digging into the AccelerateDMA code, Epicboy found an incorrect check that affected buffer-to-texture copies. Fixing it increased performance by a whopping 1%, but as any avid gamer knows, average framerates are only half of the story. This change also improved frametime consistency, especially in sudden spikes, which are arguably the most noticeable during gameplay.

I have become frametime, the destroyer of gameplay

Users enjoy testing yuzu on a wide variety of devices; one particularly interesting example is the Tegra X1 product line from NVIDIA, the same architecture that powers the actual Nintendo Switch. Since there are drivers available for those devices, yuzu can be run in a Linux environment, but for some reason, those drivers don’t include the VK_EXT_robustness2 extension, which was mandatory up until now. Newcomer mrcmunir decided to change this and mark the extension as optional, making the most optimal ARM boards for Switch emulation able to enjoy gameplay with yuzu.

To close the graphics section, we saved the best for last: toastUnlimited removed the use of a Windows only external memory Vulkan extension. Why? To make yuzu compatible with Wine while using Vulkan! Why would someone run yuzu on Wine when a native and faster Linux version is available? We don’t know! But you can definitely do it now, given you build Wine from source yourself with support for Vulkan child windows. We only intend to use this for debugging MinGW releases—for end users, we won’t provide any support for running releases in Wine.

This is a fun case where all developers asked your writer to skip mentioning this change because it was considered redundant for this report. To them I say: YOLO.

Android additions

The new supported platform in town has a lot of improvements to boast of, but the most important one gets the honour of starting the section.

Thanks to the joint work of byte[] and GPUCode, and the help from bylaws who allowed us to use Skyline’s BCn texture decoder, yuzu can now properly advertise support for Mali GPUs!

Kept you waiting, huh.

This means users of Mediatek, old Samsung Exynos, and Google Tensor CPUs (among others) can run their games in yuzu as long as they have a G-series Mali GPU, for example the Mali-G710 on the Pixel 7 series.

SUPER MARIO ODYSSEY and Pokémon Mystery Dungeon Rescue Team DX (Running on a Pixel 7 Pro)

This theoretically doubles the compatibility of yuzu’s Android builds, as Mali is the most common GPU family in the Android ecosystem.

The Legend of Zelda: Skyward Sword HD, Advance Wars 1+2: Re-Boot Camp, and OCTOPATH TRAVELER (Running on a Pixel 7 Pro)

Further testing with Mali revealed that while the driver implemented support for the VK_EXT_extended_dynamic_state2 extension in older Mali drivers, the implementation for VK_EXT_extended_dynamic_state was not fully functional, and yuzu was not behaving correctly in this case. This is most likely the reason both extensions were removed by Google from Pixel drivers. To avoid users of affected drivers experiencing no rendering output at all, byte[] disabled the use of the extension on Mali hardware.

It should be noted that while the Mali drivers are much better at following the Vulkan specification than others, the physical hardware specifications are lacking. Only high-end devices will reach playable framerates at the moment. Lower-end Mali products will be too weak for Switch emulation, even if they meet the driver requirements to run the emulator. But hey, you’re welcome to try it out and see how it goes!

There’s also been a LOT of work put into the Android user interface.

To begin with, PabloG02 has given us a hand again, this time by storing the position of overlay controls as a percentage, so if there is a change in the dimensions of the window, for example by using a foldable device, or rotating the screen on a tablet, the overlay controls stay in approximately the same location.

Place your input anywhere you want!

To help users with transferring the required files to yuzu and with debugging, PabloG02 also added UI options to import firmware files, a requirement to run and properly display some games, and an option to quickly share the last log file, which can help our support members when trying to diagnose the reason for a crash. Thanks!

Select your firmware dump location

Users can be very particular about the configuration of overlay controls. Some may be fine with just using the Switch’s touch screen instead (depending on the game), and some have different preferences of opacity levels for buttons. For cases like these, t895 added a dialog to adjust the scale and opacity of the overlay controls.

Size and transparency

It’s also a great way to enjoy touch-only games (Witch on the Holy Night)

yuzu includes a notification to ensure the app isn’t closed by Android when switching apps. We need to do this to ensure users don’t lose their progress, but it can also be used to include some cool features.

One possibility is support for Picture-in-Picture when minimising the app. t895 did the preliminary work to allow changing the aspect ratio, and newcomer AbandonedCart did the actual magic.

That’s a spicy music player (Super Smash Bros. Ultimate)

Later, a button to mute/unmute was added to the Picture-in-Picture overlay.

Android doesn’t only run on phones and tablets. You can find people crazy enough to play yuzu on TVs too! For those madlads, newcomer qurious-pixel added support for an Android TV banner. Thank you!

NVIDIA SHIELD anyone?

Since release, users have reported games looking strangely blurry, and issues with the aspect ratio of the rendering window and the orientation of the overlay controls when flipping the device.

This is a bit of an embarrassing one: all those issues were caused by decoupling the rotation of the Vulkan surface with the frontend layer. This explains why aspect ratios were distorted and the overlay was inverted when the device was rotated, but the explanation for the blurriness issue deserves special mention. Games present to the screen in docked mode using a landscape form factor and resolution of 1920x1080, but phones typically have a portrait mode form factor. What happens if the window starts rendering at 1920x1080, then gets modified to 1080x1920 by the device and is stretched to fit the screen? Well, this:

Did we mention we’re new at this?

By keeping rotation in sync, both intentionally by the user and unintentionally by the device, all mentioned issues are solved. Oops!

Continuing the effort of reaching feature parity with the desktop builds, german77 added support for installing updates and DLCs to NAND, just like on PC.

Remember to hold to select multiple files!

AbandonedCart once again comes to the rescue by adding support to allow this option to install multiple files at once. It’s not fun having to constantly repeat the process to install every single thicc Atelier Ryza: Ever Darkness & the Secret Hideout DLC, but it’s so worth it.

Big Boss bunnei made some changes to the default graphics settings to improve the out-of-the-box experience, as well as add options required to solve rendering issues and/or improve performance.

Joining yuzu on Android from the desktop release is Reactive Flushing, an option that can significantly reduce performance in the name of rendering accuracy. To provide the best performance, the option is disabled by default, but if you want accurate shadows in Bayonetta games, or proper save thumbnails, remember to enable it.

Force maximum clocks is now disabled by default, since it’s not very relevant while the main bottleneck is on the CPU side of the emulation process. We’ll revisit this toggle once native code execution is implemented.

Feature parity with the PC releases, little by little

An often forgotten feature of the Nintendo Switch is touch support. While in handheld mode, some games allow you to play without controls, just with the screen. Support was present since release for the Android build, but it wasn’t accurate — the touch event would happen offset to the side of where the user would touch their finger. german77 fixed this touchy behaviour, making playing visual novels with no overlay buttons a joy.

One of the nice additions of Android 13 is the option to set per-app languages, so properly declaring the available language translations allows users to take advantage of this feature. Thanks flTobi!

Your phone knows more languages than you

Expanding the Debug section a bit, t895 added the option to disable CPU Fastmem. This will reduce performance, but is useful for debugging purposes.

Extremely recommended to leave at default values

Additionally, an option to select the audio backend was added too.

Volume controls

Because it is only supported on Qualcomm devices, t895 now hides the Install GPU driver option if the user is running a non-Qualcomm device. Since we don’t offer the option to run different drivers on these devices, there’s no reason to show it. Of course, if Mesa can deliver a good driver for Mali hardware in the future, we will support custom drivers for it then.

As a way to warn users with devices that may not be capable of stable emulation, AbandonedCart added a warning if it doesn’t have at least 8GB of RAM. Android versions prior to the upcoming 14 don’t let apps know the exact RAM amount of the device, so available free RAM is used instead.

Speaking of which, t895 added support for Android 14. Better to be ready beforehand! You never know when Google might surprise us.

Before we end this section, let us clarify something. The Android builds are not limited to the changes mentioned here, but also include any other core improvements mentioned in this article. For instance, the previously discussed GPU changes, and to be discussed memory and ARM optimizations are also included in the Android builds. These changes have boosted performance by 30-70% in the latest versions, for example, and none were Android specific.

We have also completed our release backups on GitHub! You can find them here. If you want to download a previous version, test experimental features, or avoid using the Google Play Store, feel free to grab the APK from there.

Making CPUs go the opposite of BRRR, AMD edition

Back in March, we explained why Windows is not accurate enough when very high precision timers are required, so in order to improve performance, power consumption, and temperatures on x86_64 CPUs, specific CPU instructions are needed to reduce the time the CPU spends improperly idling. We have a big mistake to correct here. We said only Intel offered such instructions starting with Alder Lake, and that AMD didn’t offer any.

Fortunately, we were wrong! AMD does indeed have its own implementation, the monitorx and mwaitx instructions pair, which have been out since 2015, predating Ryzen!

By performing his usual black magic, Morph implemented support for these instructions, providing the same benefit only Intel users previously enjoyed, namely performance and battery life improvements for power-limited products (laptops, handhelds) or CPUs with fewer core counts.

Since AMD CPUs running Windows can now properly idle for longer while waiting, power consumption and/or performance numbers are improved, depending on which limit is hit first: the power budget of the CPU or a framerate cap. Sadly, your writer (who got tasked with testing this change) doesn’t have access to an Asus Rog Ally handheld, or even a Ryzen laptop, to do proper benchmarks, so instead please accept the numbers collected with a desktop Ryzen 5 5600X. The results should be better with a proper mobile platform, but alas, we can only show what we tested.

Power consumption saw a 10-16% reduction, which translates with this particular CPU model to around a 10W reduction. While simulating a power limited scenario (capping the PPT to 40W), performance improved up to 60%, but on average a 20% gain is more often expected.

Now, we can guess what some of you may be thinking, “how much does this help the Steam Deck? That’s a power-limited system with only four cores!” It makes no difference on the Deck. Let us explain.

The Steam Deck by default runs a Linux distribution. Linux doesn’t benefit from these changes as its kernel, unlike Windows’, is actually decent and can run high-precision timer events without any problem or undocumented SDK usage. If there’s no need to spin the CPU at all, it gets to idle properly. So unless you installed Windows onto your Steam Deck, you already had the best performance it can offer.

ARM changes

The Android release taught us something very important: Using Dynarmic adds a lot of overhead on ARM CPUs. While this doesn’t pose any major obstacles on Apple Silicon M1 and M2 Macs, it’s a big problem for Android devices, which are constantly power-limited with virtually no room for waste.

To reduce the overhead here, we are planning to implement a feature from Skyline, native code execution, or NCE, letting the game’s code run directly on the processor untranslated. This will work for most 64-bit games, but 32-bit Switch games have some special requirements that complicate this.

NCE is a project that will take some time, but for now, byte[] already implemented a way to decouple Dynarmic from the ARM interface, allowing for a separate CPU backend in the future. Let’s see what the future brings.

We’re still calling it Project Nice, right? Right.

Regarding 32-bit games, it’s worth mentioning that behind the scenes, Merry constantly works on optimising and fixing bugs in Dynarmic. Recently, Merry was able to enable an optimization for ARM64 host hardware. Block linking allows blocks of guest code that directly jump to each other to directly jump to each other when recompiled as well. After enabling it, this resulted in a 60-70% performance boost for 32-bit games like Mario Kart 8 Deluxe on Android SoCs. This serves as yet another reminder that emulation is very CPU-focused.

Linux specific fix

Long gameplay sessions can sometimes feel like a gamble regarding stability. That’s a very common problem for emulators due to how they have to handle memory in unique ways to match two completely different systems. This was especially true for Linux users, who had to rely on increasing the size of the vm.max_map_count kernel parameter for certain games to avoid out-of-memory crashes. Since the emulator needs to create placeholder memory mappings to keep up with the virtual memory requirements of the game, it wasn’t hard to saturate the default value, resulting in a crash once the placeholder mappings outnumbered the max mapping count.

Enter newcomer kkoniuszy, who had a simple yet very effective idea. By keeping track of the creation of such placeholder mappings and using that information to create fewer larger ones instead of several smaller ones, the stress on vm.max_map_count is reduced and generally no longer needs to be modified. This results in stable game sessions when playing for hours. Thank you!

Input improvements

The work to make Amiibos and their Near-Field Communication (NFC) behave the same as on real Switch hardware continues. With the proper implementation finished last month, german77 has focused on the last items on the checklist.

First of all, backup support. On the Switch, Amiibo data is stored in the console every time data is loaded or saved. This is intended to help games restore corrupted Amiibo tags in case of errors. With this implementation, yuzu now can do the same with Joy-Cons and Pro Controllers. The backups will be stored in %appdata%\yuzu\amiibo\backup.

Our input dev added support for Foomiibos, blank but configurable Amiibo dumps with a signature included at the end, by adding their size as a valid input.

Activision releases NFC equipped toys (aka not-Amiibos) for the Skylanders games saga, and they are compatible with the Nintendo Switch, so of course, they must work on yuzu too! The implementation should be transparent; just connect and map a controller, and it’s ready to scan the toys.

And to finish up the NFC section, bugfixes and support for third-party controllers in a single pull request to rule them all.

Controllers sometimes fail to properly restore to a previous state when pairing. This could make yuzu lose input when the controller fails to use the NFC sensor. If the game stopped polling for Amiibos while one was in range, the Amiibo would be lost but not signaled. This pull request addressed this particular scenario.

Many third-party controllers don’t accept all commands. Reducing the number of attempts to obtain valid data and disabling most commands if errors occur will minimise the stuttering caused by the configuration process when setting up the NFC interface.

Lastly, if the controller properly reports support for NFC, but the user loads an amiibo from a binary dump, we would mistakenly show an error. This is now fixed.

Now, what about regular input changes? Well, we have a bit to talk about there too.

SDL, the external library used here to handle input (it can do much more than that), does get updates, and it doesn’t hurt to keep up with those from time to time, after validating they are stable, of course. Updating to version 2.28.0 improved the calibration profile used on official Switch controllers, added support for the new DualSense Edge controller from Sony, fixed some issues with Pro Controllers, and added other minor changes and fixes that benefit the emulator.

Mouse controls got more tuning love. This time there are some minor tweaks to its calibration. Returning to center will consider the assigned deadzones, and motion input has better sensitivity.

For those not in the know, if you set input to Keyboard/Mouse, or manually map a stick to the mouse, you can use the mouse for controlling movement. Ctrl + F9 is the default hotkey to take and release control of the mouse while playing.

Lastly, for the fitness enthusiasts, there are some improvements for the Ring-Con.

german77 improved Ring detection by adding timeouts to let the scanning process try again after a fixed time.

And newcomer kiri11 improved the wording of the help text to properly enable the Ring-Con, making it much less confusing. Thanks!

Fitness at 4K

Yet more Gaia-lite

Yes, there’s more progress by byte[] in fixing the current file system implementation while we wait for Project Gaia.

The previously reported “algorithmic complexity issue” when loading mods was working like a charm on Linux, but Windows always has to be difficult. A memory cache was added to fully realise the load time benefits on Microsoft’s OS too.

In another single-line-of-code revelation, byte[] discovered that increasing the size of the buffer when copying files can more than triple the installation speed of updates and DLCs. Hurray for simple fixes like this!

A common problem modders and users had to deal with is a hard limit on the number of files that can be loaded per session. Games like Fire Emblem Engage have so many files that it previously was not even possible to replace all of them with a mod. Of course, byte[] wasn’t happy with this, so by adding a file LRU cache to control the number of open files, he removed the file limit. Users can now run as many mods as they want on their games, and they can have as many files as they need too!

But the fun doesn’t stop there for byte[]. Yet again, Windows demands special attention… A couple of optimizations and Windows users can now properly benefit too.

An oversight in the code responsible for caching RomFS mods prevented any caching from taking effect at all, making yuzu take typically twice as long as it needed to when loading a game with them enabled. By fixing this oversight, byte[] further reduced game load times with mods.

Audio fixes

Linux users running the SDL audio backend reported having no audio out when using the JACK output. The problem, as newcomer zeltermann found out after some investigation, is in how SDL identifies the CPU characteristics of the user’s hardware.

SDL’s CPUInfo subsystem is called to report the specifications of the user’s CPU. SDL then uses that information to properly configure itself for the environment it will run on, setting optimizations and deciding which internal code paths to use. We thought CPUInfo shouldn’t be necessary just for audio output, so it was disabled in yuzu.

Well, under normal circumstances, it would have been fine, but SDL can’t decide if not having CPU information means there is or there isn’t a CPU present. SIMD support is reported as disabled, but SSE2 is assumed as enabled. This contradiction leads to the fallbacks intended to run in case SIMD support was disabled to fail, making some functions return null, completely destroying audio output.

This chain reaction of events is solved by giving SDL what it wants: a proper report by CPUInfo. Now Linux users can enjoy their games with audio when using the SDL output. Thank you!

Out-of-bounds, the silent killer of so many programs… yuzu is of course not immune to them, as Morph found out. An out-of-bounds write leads to corruption in an audio heap buffer, which leads to beeping noises, speaker rattling, and crashes in multiple games, including but not limited to Xenoblade Chronicles: Definitive Edition, Xenoblade Chronicles 2, Super Smash Bros. Ultimate, and more.

A few tweaks here and there in the audio core code, and the issues are gone.

UI changes

Switch games provide pretty game icons for the launcher. Needless to say, yuzu makes good use of them while rendering the game list. What wasn’t considered when using these icons for the user interface is that some games offer multiple alternatives for different languages. yuzu would just pick the first one available.

Enter newcomer keve1227 who coded in the logic required to properly pick the right image depending on the console language the user picks in Emulation > Configure… > System > Language. Thanks!

Gotta find ’em all

The OpenGL API has three available shader backends in yuzu, and since the only way to know which one is selected is from checking the option in Emulation > Configure… > Graphics, newcomer fastcall decided it was due time to add this info to the status bar. Thanks!

You won’t forget you left GLASM enabled any more!

Hardware section

Before starting with the driver rants, we want to share a possible way to save up to 2 GB of VRAM by taking advantage of Windows 11’s per-app graphics selector, assuming you have multiple GPUs available in your system. This has the potential of helping VRAM-intensive games like The Legend of Zelda: Tears of the Kingdom, and may also improve 1% lows on native PC games too.

For some reason, Windows uses around 1-2 GB of VRAM only for rendering the desktop. That’s a heavy blow for GPUs equipped with 8 GB or less, without even considering other programs running in the background.

The requisites are a desktop PC running an up-to-date Windows 11, either a motherboard with two full length PCI-Express slots or a CPU with an integrated GPU, and all GPUs being new enough to still get driver updates (a GT 710 won’t work with an RTX 4070 as they run different driver versions, and an Intel HD 620 won’t receive new driver updates). In this example we will use an RTX 3060 Ti and an RX 6600, a combination you might be familiar with from previous articles and charts. A lower-end GPU like a GTX 750 or the integrated GPU of an Intel 11th Gen. (and newer) or Ryzen CPU would also work perfectly fine for this purpose.

It should be noted that most laptop users already do this with no user intervention, as most laptops don’t include hardware mux switches and just pass the finished frames over the PCIe bus.

The main trick here is to connect the display or displays to the secondary card, in order to get Windows, your browser, Discord, etc., to spend VRAM exclusively on the secondary card, letting yuzu and other programs/games get full access to the entire VRAM of the main GPU. To do this, we will take advantage of some relatively recent additions to Windows 11.

The first step after setting up the GPUs (desktop PCs may need to enable integrated GPUs on the UEFI configuration/BIOS) is to select the high performance card in display settings:

On desktop PCs, Windows 10 fails here by not letting you select which card is which

While this is enough for yuzu after a reboot, you will also need to manually set up each game or program that requires using the high performance GPU:

Tech tip: Forza is faster if you run it with your main GPU

Like this, you get the benefits of more free VRAM on the high performance GPU, and if the secondary GPU is more efficient, a power consumption reduction overall when using the PC. More available VRAM results in improved minimum framerates (the 1% low for example).

The cons for using this method is that frame data is transferred over the PCIe interface, which can be saturated. This can result in slightly lower average framerates and more input lag. But hey, a free way to get a 4GB GPU to run The Legend of Zelda: Tears of the Kingdom with better frame pacing is worth a try, right?

NVIDIA, no sign of progress

The new (at the time of writing) 536.40 driver release that adds support for the RTX 4060 hasn’t introduced any regression for yuzu. So it’s safe to update, just not “safe to upgrade” from older hardware yet. Maybe the RTX 5000 series will be a more viable option.

And from an interesting report that just came in, it seems using the NVIDIA Control Panel’s “Prefer maximum performance” option while playing Xenoblade Chronicles 3 in conjunction with “Use asynchronous shader building” causes vertex explosions, most noticeably in cutscenes. yuzu’s own “Force maximum clocks” toggle, while less efficient, doesn’t reproduce this interesting behaviour. Something to keep in mind if you’re exploring Aionios with an NVIDIA GPU.

AMD

Since driver release 23.7.1, a mysterious older “23.10.01.41 for Additional Vulkan Extensions” version, and the beta driver only available to Windows Insider testers, AMD official Vulkan drivers introduced a regression in how the VK_EXT_extended_dynamic_state3 extension handles colour blending. Your writer blocked the affected bit while we monitor if future AMD driver releases manage to solve this problem.

Who gave Link the Batman’s Detective Mode? (The Legend of Zelda: Tears of the Kingdom)

The performance loss from this change is very small, so feel free to update to the latest drivers.

GPUCode has found a way to emulate D24 support on AMD GPUs by using the VK_EXT_depth_bias_control extension, which is currently only available on the RADV Mesa driver on Linux. In the near future, we’ll check if this method solves the remaining graphical issues specific to AMD hardware. If it works, it would also solve the issue on the AMD official drivers, once/if the extension is supported there too.

We know it’s not fun having to switch to OpenGL to be able to play some games, so we’re gearing up to combat even hardware limitations to defeat this foe.

Intel

Intel had its fair share of fixes this month too. First of all, as promised last month, byte[] added a translation for FP64 to FP32 when used in shaders. This was required because Generation 12 Intel graphics (UHD 700/Iris Xe/Arc A series) removed support on a hardware level for double precision operations. With this shader translation in place, games will no longer suddenly crash when trying to use these shaders, for example during the opening cutscene of Tears of the Kingdom after starting a new game.

The next issue is an interesting mix of unique behaviour by the Switch’s own graphics drivers, yuzu’s code at fault, and another case of lack of hardware support. Intel’s GPUs allow the use of control barriers as specified by SPIR-V, which requires all threads in a dispatch to execute the same barriers at the same times, and don’t allow any threads to exit early if another barrier will occur. But all other GPU vendors besides Intel, including mobile GPUs, do allow threads to exit early, and will free up barriers on the remaining threads as needed. This situation caused Intel GPUs to hit device losses, as guest compute shaders had barriers that ended up hitting this exact type of control flow.

By removing barriers after conditional control flow, Intel GPUs are free from their device loss crashes.

And lastly, one loose end remained, our toggle to disable the compute pipeline on Intel GPUs. This option was a stopgap solution until a driver update was released. But since Intel has finally published a driver update fixing the issues, it has now become irrelevant. toastUnlimited therefore modified the option to only show up in yuzu’s settings if an old driver known to be affected is still in use. The disable compute pipeline toggle is now a legendary drop option only available for the most unlucky Generation 12 users, as the option will also remain hidden for unaffected Generation 11 and older devices. Remember to update your drivers!

With all driver and yuzu stability-related issues fixed, we can finally recommend Intel hardware again, especially current-generation integrated GPUs like the Iris Xe. While the lower-end 80EU-equipped Iris Xe can bottleneck performance at docked 1X mode in the most intensive games, it makes up for that by having zero texture related stuttering thanks to being the last breed of Intel GPUs with native ASTC texture support. We don’t know if future iGPUs will keep supporting ASTC, but it’s a reality that Arc dedicated GPUs don’t offer it.

Still, we can finally focus on working on the few remaining quirks for the Generation 12 architecture. Right now, the Iris Xe can easily beat a Geforce MX450 in ASTC intensive games like The Legend of Zelda: Tears of the Kingdom, using less RAM and having no texture stuttering. Here, the E-cores are a blessing for shader building.

Hopefully future Intel products offer better FP16, higher performance, longer driver life support, don’t base their pricing on software gimmicks like their competition, and add a much-needed dedicated compute queue.

Android

With the release of the Android builds, the whole team is learning about the platform’s ecosystem, its features and limitations, quirks and advantages. There are fun times ahead for sure. This means we also learned about the depressing state of its GPU drivers…

Adreno, or just waiting for Mesa

Adreno hardware has great specifications, but their proprietary official drivers are incredibly bad! We’re starting to work on improving rendering on the official Adreno drivers used by default on Qualcomm equipped devices, but there’s only so much we can do. The real solution comes from, you guessed it, the team that manages to make good drivers with no access to confidential information: Mesa.

One has to wonder why Android vendors don’t just use Mesa to begin with. Nothing deemed “confidential” or “trade-secret” here is more important than providing good software support!

While the Adreno 600 series is well-supported and has great rendering with Mesa Turnip drivers, the 700 series is too new to enjoy the same benefits. There have been a few packaged releases by K11MCH1 using the currently-in-development a700 branch of Mesa Turnip, but it’s exactly what it says on the tin: currently in development. We can’t work on fixing regressions on a driver that is a work in progress; the only thing to do is to wait for it to mature.

Mali, good drivers, slow hardware, weird decisions

Mali is the complete opposite of Adreno. While there is no current Mesa support for it, we found their proprietary Vulkan driver to be in great shape once its initial quirks were addressed. The same can’t be said about their OpenGL ES driver as our friends at Citra will gladly tell you, but thankfully that’s not an issue here. The main problem is that the most common hardware the driver gets to run on is pretty subpar, at least for Switch emulation. Clearly, high-end devices won’t have much issue on the GPU front as they are not far behind Adreno in hardware specs, but the rest of the product stack will suffer from low framerates and GPU bottlenecks.

Unfortunately, due to an unstable kernel API, and the lack of a maintained Mesa driver for these devices, there isn’t currently any practical way to replace the running driver on a Mali device with a better one. If a device ships with an outdated driver too old for yuzu and the vendor doesn’t update it, chances are nothing can be done about it.

That’s either planned obsolescence at its finest, or sheer incompetence. We’ll let you be the judge of that.

Future projects

Fun stuff is cooking, we can’t announce the several yet-unnamed projects at the moment, but know this ship isn’t slowing down any time soon.

There’s work by Blinkhawk for faster GPU emulation, native code execution for ARM CPUs, MacOS gets a bit of much needed love, and more. We’ll be reporting progress on these projects in the future, so keep your eyes peeled.

toastUnlimited started a big UI rewrite for the per-game configurations.

Some changes that didn’t make it in time for the cut-off date of this article include fixing crashes affecting Unreal engine games running on NVIDIA GPUs. We’ll cover those next month.

That’s all folks! Thank you for reading until the end. We hope to see you next month!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report May 2023

GoldenX86 — Sat, 17 Jun 2023 12:00:00 -0300

What a month! GOAT releases, yuzu ventures onto new platforms, we get a taste of Project Gaia, full Amiibo support, further Project Y.F.C., and a lot more! Put on your safety belt and start playing some eurobeat, this will be a long ride.

The Legend of Zelda: Tears of the VRAM

Six years and the wait was worth it. No pay to win mechanics, no soul-draining microtransactions, no apology letter published after release. Just game, just good game.

Runs on a 2015 tablet. (The Legend of Zelda: Tears of the Kingdom)

Zelda is back, and once again teaches the gaming industry how to make a video game, while also making it fit inside a 15-year-old USB stick and run on an 8-year-old mobile SoC.

And it’s only 16GB! (The Legend of Zelda: Tears of the Kingdom)

The Legend of Zelda: Tears of the Kingdom not only made its predecessor (a game which already reinvented how open-world gameplay should be done) look like a tech demo, but it also turned out to be one massive heavyweight, punching way above its class in hardware requirements when emulated. The combination of a heavier physics engine, massive amounts of shaders, and the ludicrous use of enormous ASTC textures has brought emulators to their knees.

Let’s begin with the most complex problem the Princess introduced the project to. The old Switch-emulation-on-PC nemesis, now elevated to new heights: ASTC.

Deer. (The Legend of Zelda: Tears of the Kingdom)

As there isn’t a single dedicated desktop or laptop graphics card that supports the native decoding of ASTC textures (with the exception of Intel iGPUs), yuzu is forced to transcode them on the fly into a safe and lossless format that all GPUs support; in this case, the RGBA8 format.

This was perfectly fine until now (even on 2GB GPUs), since ASTRAL CHAIN was the only game that made “extensive” use of ASTC textures, shipping with 4K textures on a mobile device intended for 1080p and 720p screen resolutions. Our garbage collector, introduced two years ago with Project Hades, which our veteran users know as “the memory Reaper”, was tuned for this worst case scenario at the time.

But what happens if a game with many more textures and a teletransportation system that allows the player to reach different regions in-game (and, in turn, load a truckload of new, different textures) releases? What if this hypothetical game made use of dozens and dozens of huge ASTC textures?

The VRAM is on fire! (The Legend of Zelda: Tears of the Kingdom)

Well, suddenly the old and trusted garbage collector we developed is no longer capable of keeping even 8GB GPUs working. That’s right, the VRAM starvation affecting the PC gaming industry hurts yuzu too. Serious changes had to be made, and they had to allow 2GB GPUs to still be compatible somehow.

Your writer’s Tower of VRAM Testing. GTX 750 2GB, RX 550 2GB, and RX 6600 8GB. Not pictured, GTX 1650 4GB, GTX 1660 SUPER 6GB, and RTX 3060 Ti 8GB

The solution, which took many attempts, was split into several parts to ensure that no other games were negatively affected by the changes, and required the combined efforts of Maide, byte[] and Blinkhawk.

While investigating very low VRAM devices, byte[] found that yuzu used incompatible memory property flags when the Vulkan memory allocator was under pressure, causing low VRAM GPUs to crash when trying to actually use a recycled allocation.

Having more VRAM available certainly helps, but that’s not enough to avoid the game from biting off more than the GPU’s memory can chew under stressful conditions — for example, teleporting between different regions.

Previously, if VRAM was almost full, the memory manager would try to use shared memory, which is just a portion of system RAM, for new allocations. This caused massive slowdowns during gameplay, as the transfer operation of going over system RAM, CPU, PCIe, GPU, and finally VRAM is a slow process that introduces a high latency.

Collecting memory in VRAM is much faster than transferring data over to system RAM. So, instead of relying on the slow shared memory, the memory manager (Reaper) now keeps everything in dedicated memory (VRAM), leaving some free space to accommodate sudden spikes in VRAM usage when new assets are loaded. If you see 2GB or more of always-free VRAM in your system, know that its purpose is to keep gameplay smooth, even on 4GB GPUs. Don’t worry, we’re not wasting your precious VRAM. We’re just keeping it warm and cozy for when you need it. This also has the added benefit of saving on system RAM consumption, allowing 8GB RAM users to have more stable gameplay.

All of this is not enough to allow 4GB VRAM users or less to achieve stable gameplay, so it’s time to reveal the ace up yuzu’s sleeve. What if, instead of relying on the pixel-accurate but bigger RGBA8 texture format, the emulator recompressed to some other smaller formats?

Ladies and gentlemen, we present you ASTC recompression, a new option available in Emulation > Configure > Graphics > Advanced that intends to reduce VRAM consumption by turning those Ganon-cursed unsupported ASTC textures into something more suitable for low-VRAM GPUs.

We recommend avoiding BC1 if possible.

The principle is pretty simple, we just add one more step to the recompression process, from ASTC > RGBA8, to ASTC > RGBA8 > BC1 or BC3.

The default Uncompressed setting uses the old RGBA8 method, which preserves the original image quality, but also consumes the most VRAM. For users that wish to emulate Tears of the Kingdom, we recommend setting this option if their GPU has at least 10-12GB of VRAM. For other, more reasonable games, this option is suitable for users with cards with at least 4GB of VRAM.

The BC3 (medium quality) setting reduces the VRAM usage of ASTC textures by a factor of four, with a very minimal loss in quality, typically showing as marginally softer textures. This setting is recommended for emulating Tears of the Kingdom on 6GB and 8GB GPUs. For other games, this setting is good for GPUs with 3GB of VRAM.

Finally, the BC1 (low quality) setting cuts down the VRAM consumption by a factor of eight, but will also have a significant impact on texture quality, to the point where some assets will look completely different. We don’t recommend using this setting unless you really have to. It allows users with 4GB of VRAM to play Tears of the Kingdom without significant issues, and will make 2GB users have a smoother and more reliable experience in other games.

From first to last, BC1 vs BC3 vs ASTC (Fire Emblem Engage)

As you can see, BC1 destroys image quality in some games.

From first to last, BC1 vs BC3 vs ASTC (The Legend of Zelda: Tears of the Kingdom)

But in others, the difference is less noticeable. If you only have 2GB of VRAM and 8GB of RAM, the sacrifice may be worth it.

This is currently done using the CPU, but GPU acceleration is planned for the future. We also hope to add an option to use BC7 in the future to provide a higher quality experience.

Keep in mind that ASTC recompression only works on ASTC textures, so the actual VRAM usage reduction will depend on the game. Not every resource held in VRAM is ASTC. If your hardware can handle ASTC natively, this setting won’t do anything for you, as there’s no need for any recompression.

In addition, byte[] has also tuned the memory manager to be more ruthless. This change should help improve gameplay stability during long sessions on systems with less RAM. yuzu always aims to support a minimum of 8GB of RAM on systems with dedicated GPUs.

He also made sure that memory collection doesn’t happen during the configuration step, so that it doesn’t cause a device loss (i.e. the GPU driver shutting down).

By fixing the block depth adjustment on slices, Blinkhawk solved the rendering issues affecting the gloom textures on the terrain in Tears of the Kingdom, a bug that was especially frustrating on low VRAM hardware.

Let’s not make the gloom feel depressed… (The Legend of Zelda: Tears of the Kingdom)

And for integrated GPU users with 16GB of system RAM or less, such as the Steam Deck, newcomer scorpion81 has a treat for you. Setting a hard cap at 4GB allows Tears of the Kingdom to be playable without hitting the page file/swap too hard.

Your browser doesn't support mp4 video. :(

The difference made on a 2GB equipped GTX 750 (The Legend of Zelda: Tears of the Kingdom)

That wraps up the list of changes made to memory management to allow Tears of the Kingdom to be playable in at least the components listed in our hardware requirements.

These changes would not be necessary if GPUs just supported ASTC textures. Wouldn’t you like your games to be no bigger than 100GB instead of having software features that ruin image quality, such as frame generation? Native ASTC decoding support would make this possible.

An Intel Iris Xe iGPU can run the game at 30 FPS in handheld mode while using less memory than any other hardware combination, all thanks to being their last GPU capable of decoding ASTC. More on Intel’s driver support later.

We need to go deeper! (The Legend of Zelda: Tears of the Kingdom)

This was the worst part… up to this point. More work was needed to get the game to boot and render properly. Let’s dive into that.

One thing that both the Switch and Android devices have in common is the way they present to the screen. Google’s OS uses SurfaceFlinger (the only good Linux presentation method), and the Switch uses nvnflinger, which is a custom adaptation of SurfaceFlinger designed for the Switch’s firmware and operating system. While this gives us a good frame of reference for how nvnflinger should be emulated, sometimes bugs can still sneak in. These bugs are not always easy to spot, especially if no game had rendering problems until now.

byte[] realised that yuzu was serialising binder responses incorrectly (in a different way to how Android does it). Fixing this simple bug allowed for Tears of the Kingdom to boot.

Meanwhile, Maide implemented shader fixes, suggested by Kristijan1001, solving issues with cloud flickering and missing geometry in The Depths.

Your GPU is fine, it’s just software. (The Legend of Zelda: Tears of the Kingdom)

Next is a bug that only affected the base game. Following updates were unaffected, as they rendered in a different order.

Ganon likes to record Link… (The Legend of Zelda: Tears of the Kingdom)

This mysterious red dot on the right was caused by incorrectly tracking render target indexes when clearing. Thanks to some behaviour changes made by Maide, Link is no longer being spied on.

After the game was released, several users reported that the date in the game’s save files was always set to January 1st, 1970. After checking the behaviour of the Switch, byte[] implemented a few changes that solved the issue with an updated service implementation that allows for computing the time in nanoseconds, automatically adjusting for clock skew, and using the same clock source as the system’s steady clock.

There were also reports of graphical glitches when using the 2X resolution scaling factor: Link and terrain textures would become corrupted after switching weapons.

Scrambled textures. (The Legend of Zelda: Tears of the Kingdom)

Blinkhawk quickly found the cause of this problem: wrong clears were performed in the code responsible for synchronization in the buffer cache. Some tweaks, and the game can be safely played while scaled.

For the Linux AMD users, especially those not using the latest Mesa RADV Vulkan driver releases, byte[] found that one of the features of VK_EXT_extended_dynamic_state3, dynamic depth clamp, was implemented incorrectly in the driver, leading to vertex explosions in some expository moments in the game.

Oh, there goes the vertex… (The Legend of Zelda: Tears of the Kingdom)

Disabling the feature for the affected driver version and older solves this issue.

Another identified issue affected the light projection made by the Ultrahand ability, intended to help the player position objects. The green glow had a pixelated look, caused by missing barriers on attachment feedback loops.

Green Lantern hand. (The Legend of Zelda: Tears of the Kingdom)

Several keyboard strokes later, and byte[] went green with envy.

Next on the list of weird rendering issues is one that affected camera changes — for example, when talking to an NPC or aiming with the bow/throwing a weapon. Large areas in front of the player would turn black for a frame and then return to normal. Needless to say, it was very distracting.

Your browser doesn't support mp4 video. :(

A bow so cursed, it tries to take you to the Shadow Realm! (The Legend of Zelda: Tears of the Kingdom)

This bug was caused by the way the texture cache processed aliases and overlaps, which were in the wrong order and caused sync problems. After a few tries by Blinkhawk and byte[], the issue was finally fixed.

While investigating bugs related to Tears of the Kingdom, a copy-paste error hidden in the code for 3 years was also found. In the shader recompilation code, Rodrigo copied over the wrong value from one line to the next. This is another interesting case of the problem not being an issue until now, as no one noticed this bug until Zelda needed rescuing again… By changing a single character, byte[] solved the terrain gaps that could be spotted from a distance all over the map, but most noticeably in The Depths.

What’s deeper than The Depths? (The Legend of Zelda: Tears of the Kingdom)

In an interesting case where a UI setting is needed to improve a game’s rendering, byte[] added an option to clean the cache storage for a game, which can be accessed from the Remove menu when right clicking a game in yuzu’s game list.

It’s fun to watch the game reconstruct the images in real time.

This option is needed because using Asynchronous shader building in Emulation > Configure… > Graphics > Advanced will mess up fused weapon icons in the weapon selection menu, as well as autobuild history.

Not even close, baby! (The Legend of Zelda: Tears of the Kingdom)

Disabling Asynchronous shader building and clearing the cache storage lets the game properly rebuild the images of all your weaponized abominations.

That’s the progress so far with The Legend of Zelda: Tears of the Kingdom! You may have noticed there are no performance improvements mentioned here. We’re following one of the most important rules of coding, “Make it work. Make it right. Make it fast.”

As this is a particularly popular game (and for good reason), here are some recommendations that user reports and fixes have taught us.

This game is very demanding on hardware. What we list in yuzu’s recommended hardware requirements is the minimum needed to sustain 30 FPS in most areas. A 6-core desktop Zen 2/11th gen Core, 16GB of RAM, and a GPU with at least 6GB of VRAM are the baseline for now.
The latest CPUs (Zen 4/13th gen Core, always speaking of desktop products) provide massive improvements in IPC, RAM bandwidth, and cache sizes. Where a Ryzen 7 5800X3D barely manages 55 FPS, a Ryzen 5 7600 reaches 90 FPS.
Normal GPU accuracy can be used to improve performance safely.
Unsafe CPU accuracy can improve performance at the cost of small inaccuracies.
Enabling asynchronous presentation degrades performance a bit.
Don’t use Decode ASTC textures asynchronously for this game, it will cause crashes.
In some rare cases audio events can cause crashes, so be careful when using multi-arrow bows and bombs.
The Depths are particularly hungry for VRAM. Remember to use ASTC recompression if you are VRAM starved. We recommend at least 8GB of VRAM for 2X resolution scaling using BC3 compression.
The modding community has been providing amazing mods. Dynamic framerate, improved resolution and details, and much more are only a few clicks away. Here’s a collection with recommendations.
Old FPS mods compatible with the base version of the game (1.0.0) are unstable and will cause softlocks and crashes during certain actions like the Game Over screen. Update your game and use newer mods.
Remember to test the game without mods before reporting issues, as mods are still altering memory regions to work.
If you disabled Use Fast GPU Time due to recommendations from modders, do it only for Tears of the Kingdom, as you will be seriously affecting performance in other games. Right clicking a game in yuzu’s game list and selecting properties shows the per-game configuration. We strongly recommend keeping Use Fast GPU Time enabled in all scenarios.

Now go. Let the Legend come back to life.

Project Lime

Bet you didn’t expect this.

That’s right, with the blessing from Skyline’s bylaws, help from Dolphin’s t895 and Citra’s GPUCode, work from yuzu’s and Citra’s flTobi, bunnei, Merry, Flamboyant Ham, german77, and more, yuzu is now available for Android devices!

We recommend that you read the dedicated yuzu on Android article here. In this section, we will give you an overview of our future plans, some tips on settings and hardware requirements, and a realistic outlook on what you can expect from yuzu on Android right now.

The Android version of yuzu was not an easy feat. It took us almost eight months of hard work to make it happen. Right now, the core is essentially the same as the desktop version, with an Android UI and very few platform-specific tweaks. This means you can enjoy features like 32-bit game support, NVDEC video decoding support, motion, controller automapping, resolution scaling, and filters. On the other hand, features like mod and cheat management, LDN, and the controller configuration applet are still under development. Our goal is to gradually have the Android builds reach parity with the PC version.

In addition to the Google Play Store, we will soon be posting releases on our GitHub, and F-Droid is also on the horizon.

Don’t judge, it’s a light game and loads quickly, it was great for testing. (Sakura Neko Calculator)

One of the biggest lessons we learned from Project Lime is that, even after 8 years since the launch of the NVIDIA Tegra X1 (the SoC that powers the Nintendo Switch), Android SoC vendors still don’t know how to make GPU drivers.

They all started working on Vulkan drivers around the same time in 2016. And yet, none of them have managed to deliver a compliant and stable Vulkan Android driver, except for the rare few NVIDIA devices.

It is obvious that only 4 vendors have the expertise and the commitment to make Vulkan drivers work: NVIDIA, AMD, and Mesa, with a special mention for Intel, who recently stepped up their game.

Although not one of these 4, we decided that limiting support to Qualcomm SoCs was our only option for now if we didn’t want to spend several months further modifying our GPU code to accommodate all the quirks and broken extensions of Android phones and tablets. Not because their driver is decent — it’s bad. But it was just good enough to get some games to render, albeit incorrectly most of the time.

Qualcomm is the best option (and for now, the only one) because bylaws created AdrenoTools, which lets users load the vastly superior Mesa Turnip drivers on their Adreno 600 series GPUs, providing more accurate rendering, comparable to the quality expected of PC products. Any Qualcomm SoC with a name like “Snapdragon ###” from the 460 to the 888+ equipped with an Adreno 600 series GPU can choose to use either the proprietary Qualcomm driver or Mesa Turnip.

The performance gain you can expect from a device with a Snapdragon Gen 1 or Gen 2 is quite significant. But the problem is that, while the Adreno 700 series GPU that comes with it is very powerful hardware-wise, the proprietary Qualcomm driver for it is subpar at best, and Mesa has only just begun to work on adding support for Turnip. There’s an early driver release to test, but results are not great for now. It will take weeks, if not months, before we see proper support emerge. In the meantime, we intend to work on improving the rendering on the official Adreno drivers.

Try several, don’t marry the first one that works. Divorcing a shader cache isn’t fun.

The Adreno 500 series is too outdated for yuzu. Its proprietary Vulkan driver is missing many of the essential features required, and Turnip has no plans to support it either.

Mali is an example of good but weak hardware being limited by the quirks of its available drivers. Unlike Adreno, Mali has no viable Mesa alternative to rescue it, and the current proprietary Mali drivers are in bad shape for Switch emulation. Its current status is that it won’t boot any game on yuzu, but:

Internal dev build, work-in-progress in getting G series Mali running.

We’re working on solving all the quirks needed to get Mali rendering on yuzu as soon as possible. This is the most common GPU vendor on the platform after all. Mali support will happen, we just need some time. Expect news very soon!

The last case of hardware that should work, but doesn’t, is the AMD RDNA2-based Xclipse 920 from Samsung, used only in the latest Exynos 2200 SoC, and somehow completely skipped from the S23 series phones. Available information suggests that it may just be an old AMD Windows driver ported to Android, but for some reason the devices refuse to start rendering on yuzu. This is a GPU we want to get working, as there is no clear reason why it doesn’t work, while desktop AMD products work almost flawlessly. Unfortunately, we haven’t yet been able to get our hands on one, but we’ll update with more info once we do.

For all other vendors like PowerVR, Vivante, etc: don’t bother. These vendors offer such low quality drivers that support is impossible.

We’re working hard on improving GPU compatibility, adding the necessary changes needed to boot within the limitations set by the vendors.

CPU emulation still relies on the Dynarmic JIT, instead of native code execution. This allows us to run 32-bit games like Mario Kart 8 Deluxe, but is slow for 64-bit games. Expect “good” compatibility, similar to the desktop version thanks to this, but also low performance and high temperatures. Native code execution, or NCE (do I smell Project Nice?) is on our list of goals for the Android builds.

The CPU itself, while very crucial for performance and the main bottleneck for now, is less important than the GPU, for the reasons previously mentioned (the drivers). The same rules as on PC apply here: 6 cores or more is preferred, and the highest possible IPC is strongly recommended. A Snapdragon 8 Gen 2 can be twice as fast as a Snapdragon 865.

RAM use is both a blessing and a curse. A blessing because Android devices natively support ASTC textures — the format is designed for such devices. This allows the GPU to use very little RAM, just like on the Switch.

The curse is that, because Android is such a heavy OS, there is no guarantee that complex games will run on devices with 6GB of RAM. 8GB is the strong recommendation, which puts compatibility on the pricey side of the spectrum. A certain Zelda game we wrote a lot about currently requires at least 12GB of RAM to run.

There are ongoing efforts to reduce memory requirements, such as native code execution and UMA optimizations for the GPU code, but the reality is that emulation adds overhead and Android will only get fatter over time. We may be able to get light 2D games running on 4GB devices, but we don’t expect complex 3D games to run on less than 8GB any time soon, if ever.

We have set the minimum required operating system to Android 11. This decision was made to prevent installation on completely unsuitable hardware (like Adreno 500 series devices or older T series Mali GPUs), and to reduce installation on low-memory devices as much as possible. This is final, as there are no plans to support older Android versions.

Of course, it must be a 64-bit Android 11 or newer; just like on desktop, 32-bit devices will never be supported.

Users with capable hardware stuck on older Android versions can either build yuzu themselves and remove the code responsible for performing this check, or install custom ROMs such as LineageOS to get unofficial Android updates on their device.

Your writer will enjoy playing visual novels and simple platformers. (The Liar Princess and the Blind Prince)

Now that we have covered the harsh reality of Android software and hardware, let’s focus on the current experience.

We included a customisable input overlay with haptics, which can be disabled if you prefer to play with a Bluetooth Xbox controller, Sony Dualshock 4 or Dual Sense, or a Nintendo Pro Controller, and a framerate counter. You can access these settings in-game by dragging from the left side of the screen.

If you updated from a previous version, the overlay may be invisible. Just select Overlay Options > Reset Overlay to make it visible again.

Set as you see fit. (Cooking Mama: Cookstar)

While playing a game you can select Settings from the left menu, or select it from the main menu.

Expect this tab to expand in the coming months.

Here you will find setting and customization options. Most are self-explanatory, but if you want explanations for the options in Advanced settings, check our settings glossary here.

After the initial configuration is done, just tap a game and play. A search option is available for your convenience, along with a few search filters.

Choose your destiny.

One of the first improvements added by PabloG02 is a save manager that can be accessed from the Settings. This makes importing and exporting saves very simple. Thank you!

It’s dangerous to go alone, take this!

One important thing to remember: Android has the most… unusual file system permissions. We recommend creating a yuzu folder on your storage root to store your keys, as to avoid any permissions issues.

You can get different Adreno and Turnip driver versions to test from here. Keep in mind, this option will only change the driver for yuzu. It won’t (and can’t) replace anything on a system level.

At the time of writing, we recommend Turnip 23.2.0 (or 23.1.0 if you have Android 11) for Adreno 600, while Adreno 700 users can run the Qualcomm 676.22 driver to improve performance and compatibility somewhat.

There’s an early alpha Turnip release supporting Adreno 730 and 740 products (but not 725) here. It is also compatible with Adreno 600 series hardware, so it’s a simple global driver to test.

There have been reports of users not being able to load custom drivers — we are still investigating this, but there’s still a lot of work to do.

For those interested in playing with the source, we have a work-in-progress build guide here.

That’s all fo… What do you mean there’s still a whole article to write? Oh right, we have more to talk about!

Other graphical changes

Because this isn’t just a Zelda emulator after all.

Who wants more Project Y.F.C. goodies? Blinkhawk serves us Reactive Flushing, with fries.

In the early days of yuzu, if the CPU were to read an area modified by the GPU, full sync flushing between the host and guest GPU (emulated and system’s GPU) would trigger (let’s call it “old reactive flushing”). This was safe and rendered things properly, but was also slow. Blinkhawk replaced this system with predictive flushing some years ago, improving performance significantly but introducing several graphical regressions, such as broken shadows and lighting, wrong thumbnails on saves and photos, and even vertex explosions.

With this release of the yuzu fried chicken, Blinkhawk introduces the new Reactive Flushing, which has the following fixes:

Fixes old regressions such as Bayonetta 2’s shadows.
Fixes lighting in Xenoblade Chronicles games.
Improves performance in buffer-heavy games like Monster Hunter Rise.
Thumbnails and in-game photos in a bunch of games such as: saves in Xenoblade Chronicles Definitive Edition and Xenoblade Chronicles 3, camera photos in ASTRAL CHAIN, and partially fixes thumbnails in Luigi's Mansion 3.
Vertex explosions in Pokemon Violet/Scarlet and Yoshi’s Crafted World.
Make High GPU Accuracy fully use asynchronous buffers in Vulkan, improving performance.

From first to last: Bayonetta 2, ASTRAL CHAIN, Xenoblade Chronicles Definitive Edition, and Luigi’s Mansion 3

From first to last: Mario + Rabbids Kingdom Battle, Pokémon Scarlet, and Yoshi's Crafted World

The option still carries a performance cost, sometimes a considerable one. It’s enabled by default, but users can disable it from Emulation > Configure… > Graphics > Advanced > Enable Reactive Flushing. If you need the performance, and can tolerate the graphical regressions introduced by disabling it, the option is there.

If you have performance to spare, keep it enabled.

Users with AMD and Intel GPUs complained that high-framerate mods couldn’t push the framerate past the display’s refresh rate when using Vulkan. This was because the VSync toggle was assuming the best option for each hardware driver based on compatibility.

What used to be just VSync on, off, or triple buffer in the good old OpenGL days is now more complex with Vulkan, even if current games insist on mistakenly calling the setting “VSync on” for legacy reasons. In fact, nowadays there are 4 VSync options commonly supported by GPU drivers:

Immediate: No VSync. Tearing will happen, but no framerate restrictions will apply.
FIFO: Double buffering. This is equivalent to yuzu’s old VSync on. Tearing won’t happen, but input will have one frame of latency, and the refresh rate can’t exceed the display’s capabilities.
Relaxed FIFO: Identical to regular FIFO, but allows for tearing to happen if a desynchronisation happens. Can be considered similar to adaptive VSync. Useful for games with dynamic framerates.
Mailbox: Triple buffering, avoids tearing while allowing for framerates higher than the refresh rate of the display. Similar to what AMD calls Enhanced sync, and what NVIDIA calls Fast sync.

Mailbox is the obvious recommendation for most games, so of course only NVIDIA on Windows, Mesa on Linux, and Android drivers offer support for it.

Android has no tolerance for tearing.

Per your writer’s ~~begging~~ request, toastUnlimited updated the old VSync toggle in the Graphics menu to a proper drop list mentioning all available Vulkan options.

If it is an option, pick Mailbox.

If, for example, someone with an AMD or Intel GPU on Windows wants to play Super Smash Bros. Ultimate with a 120 FPS mod on a 60 Hz display, they now have the option to use Immediate mode, which is what the emulator switches to when the player unlocks the framerate with Ctrl + U. The rest can just enjoy Mailbox.

We recommend setting the driver’s control panel to Enhanced/Fast sync for the best results.

Press F to sync

Maide found an issue related to the size of the pipeline cache. yuzu used to return the size of the shader code in bytes, which was later used to resize the unsigned 64 bit integer array in charge of storing the cache, making the array 8 times larger than it was supposed to be. This is fixed by using the length of the array instead of the size in bytes.

A common complaint from users with 8GB of RAM is that games become unstable over time. This isn’t necessarily a memory leak — it’s likely just the system running out of RAM as new shaders are added to the pipeline cache. This change greatly benefits them. ~~But it’s 2023, you should seriously consider getting 16GB by now. Tears of the Kingdom is not Super Mario Odyssey.~~

ASTC continues to be in the news here — this time a problem with 3D ASTC textures, because it isn’t enough to deal with flat 2D ones. A bug in their implementation caused the level Frantic Fields in Donkey Kong Country: Tropical Freeze to render incorrectly. Some tweaks by the ‘hawk, and the Kong army is back in action.

No more quicksand! (Donkey Kong Country: Tropical Freeze)

yuzu’s buffer cache is responsible for storing most forms of arbitrary data for the GPU to process. Buffers can be modified by either the GPU or the CPU, so yuzu would track the buffer to one type of modification, then wait for the other type of modification to synchronize the data. But in reality, performing the synchronization before tracking the modification would make much more sense. Maide noticed this discrepancy and set out to correct it, streamlining the code.

Since the old code would track buffers globally, some draws would end up ignoring channel swaps, leading to leftover values from the wrong channel getting bound in uniform buffers. If instead we move buffer bindings to be channel specific, the issue is solved. This fix should affect more games using multiple 3D channels too.

Continuing with code optimisations, Maide found some incorrect behaviour in how render targets are selected.

The Render Target (The OG RT for rendering devs before RTX came to town) is a texture containing the image to be rendered during a draw or clear operation.

The emulator has to look at the format of the available render targets to determine which one to clear. For example, suppose there are 5 images bound as render targets, indexed from 0 to 4, and the game requests to clear the render target with index 2. The next step is to look at the format of render target[2] in the array. This is where the old code would work incorrectly and inefficiently, as it would iterate through all the render targets and pick the first one that returned a valid format corresponding to target[2]. This could very well be target[2] as expected, or an earlier render target such as target[0] or target[1], in which case the code would completely ignore the actual render target we wanted to clear.

In short, this process was both slower and potentially unsafe due to the risk of clearing the wrong render target. Not happy with this, Maide worked to sort it out, getting the correct render target cleared.

Time to introduce another term! Descriptor Sets are a feature of the Vulkan API. Their purpose is to allow the CPU to update input bindings, the list of resources used by a shader, in an efficient way.

Previously, yuzu would share the same descriptor set update queues between guest operations (operations directly translated from a game) and host operations (operations yuzu performs to emulate specific Switch GPU features which don’t exist in Vulkan). This could mistakenly end up with host operations overwriting the descriptor set updates of a guest pipeline during processing. At best, this would break the state of the guest pipeline, and at worst, it would take down the entire GPU driver. If you experienced random crashes in Xenoblade Chronicles games, Luigi’s Mansion 3, Bayonetta 3, among others, you might now know why.

So, how can this be solved? “Simple!” Let’s just give the host and guest compute pipelines their own queues. Having this information in separate queues fixes the data integrity issues, greatly improving stability.

Newcomer danilaml identified a missing bitflag in the header responsible for decoding H.264 videos. This fixes video rendering for Layton's Mystery Journey: Katrielle and the Millionaires' Conspiracy.

Games are boring without their cutscenes, right? (Layton's Mysterious Journey: Katrielle and the Millionaires)

Not stopping there, danilaml also added support for deinterlaced video playback by using the yadif filter included with FFmpeg, fixing the game’s video rendering. Thank you!

Intel’s Linux Mesa Vulkan driver, ANV, broke the VK_KHR_push_descriptor extension with version 22.3.0 and later, causing several games to fail to boot. toastUnlimited disabled the extension to ensure proper game compatibility, and then, after a quick response from the ANV developers fixing the issue, byte[] allowed the use of the extension on current Mesa versions. Mesa is an example of how GPU driver development should be done.

GPUCode improved overall performance when using Vulkan in a few percentage points by removing a wait semaphore. Every bit helps.

Epicboy continues his crusade to improve OpenGL. This time, he fixed the use of Accelerate ASTC texture decoding when ASTC recompression was set to Uncompressed.

And finally, to close this section, Maide fixed homebrew console apps crashing by skipping a section of the buffer cache that isn’t needed when an app doesn’t use graphics.

Project Gaia-lite

byte[] implemented some file system changes on his own, giving us a taste of what’s to come.

Here’s a fun one. Why does it take minutes to boot Fire Emblem Engage or Animal Crossing: New Horizons with mods? Because the old implementation became quadratically slower as the number of the files in the game increased!

Fixing the terrible time complexity reduces patch times during boot in Fire Emblem Engage from one and a half minutes to three seconds, and in Animal Crossing: New Horizons from about a minute to one and a half seconds. Wow!

That function wasn’t the only source of unnecessarily quadratic behavior. Reads also grew quadratically in time with file count, which has now been optimized, improving in-game load times as well as boot times.

Another source of slowdown we’ve identified comes from unnecessary copying and freeing of strings, and we plan to address this in Project Gaia in the future.

Finally, a savedata reader for cache storage needed to be stubbed to get Tears of the Kingdom to boot.

Input and Amiibo improvements

HD Rumble is one of the marketed features of the Switch, which is a cool way of saying the official Switch controllers have Linear Resonant Actuators in charge of rumble, instead of the good old rumble motors we were used to in the past.

Well, Sony’s DualSense controller also has linear resonant actuators, so in theory, it should be able to emulate HD Rumble. The problem is that SDL, the API we use to support non-Nintendo controllers on yuzu, currently doesn’t expose a way to take advantage of these fancy actuators.

Well, newcomer marius851000 improved this situation for DualSense owners, so they came up with the idea to change the rumble amplitude based on the frequency requested by the game, with 140-400 Hz operating as the low frequency, and 200-700 Hz as the high frequency. This way, some sense of “rumble audio”, and an overall better shaky-shaky experience, is achieved. Thank you!

To help you see if the motion controls are working, german77 has added a cute little cube to the controller preview. Feel free to play with it!

Warning, it’s addictive.

Stick drift is not the only fear for gamers using controllers, there’s also the rarer motion drift! This could happen naturally, or after some serious gaming moments, so an option for recalibration was needed. Thankfully german77 took care of it, adding the option if you right click the Motion # mapping in Emulation > Configure… > Controls. If you use it, remember to leave the controller/device on a flat surface for at least 5 seconds so the process can take place.

Stop shaking!

Now something for the ~~dirty cheaters~~ open-minded players out there. Games will block trying to use the same Amiibo more than once, so german77 added a way to randomly generate a new ID each time the Amiibo is used. The option can be enabled from Emulation > Configure.. > Controls > Advanced > Use random Amiibo ID.

Bottom right corner, can’t miss it.

Keep in mind games like Super Smash Bros. Ultimate will complain if the ID changes.

Scanning for Amiibos seems to be a very demanding task for the available Bluetooth bandwidth when using Joy-Cons. To mitigate this, german77 reduced the scan rate from once per frame (30 or 60 Hz) to 5 Hz, and reduced the number of attempts to get valid data to 1 down from 7. This should alleviate the right Joy-Con’s oversaturation of the available Bluetooth bandwidth, reducing stutters considerably.

But what if you want to enjoy some Amiibo scanning on your Pro Controller? Previously, support was only available for Joy-Cons. But now, Pro Controllers are also supported! As long as the controller is connected over Bluetooth and the custom Pro Controller driver is enabled in Emulation > Configure.. > Controls > Advanced > Enable direct Pro Controller driver [EXPERIMENTAL]. That EXPERIMENTAL label is in its last days now.

Not stopping there with the Amiibo changes, german77 also implemented full support for Amiibo writing when using a Joy-Con or Pro Controller! This enables the last missing piece for full Amiibo emulation, just as you would use them on the Switch itself.

Feel free to scan to your heart’s content! As long as you managed to grab one of the plastic things while they were in stock.

It’s worth mentioning that writing Amiibo data will require dumping the relevant keys. However, if all you want to do is load decrypted Amiibo dumps, german77 added support for using them without needing to dump the Amiibo keys.

At this point, the only thing left to complete Amiibo support is to add a manager!

Audio and miscellaneous changes

The war against properly shutting down yuzu rages on. This time Maide implements a fix in the DSP engine so it closes before a required system instance is terminated. This way a deadlock is avoided during shutdown, improving the situation slightly. Another battle won, but how many remain?

This next one left us wondering… ronikirla reported that Pokémon Mystery Dungeon Rescue Team DX would consistently crash due to a read access violation after two hours of gameplay.

That’s not a simple bug to track down and fix, yet someone in ronikirla’s Twitch chat identified the issue as a bad block check in the address space code and passed along a fix.

Love the art style! (Pokémon Mystery Dungeon Rescue Team DX)

The change seems to also fix Advance Wars 1+2: Re-Boot Camp.

Bond, yuzu Bond. (Advance Wars 1+2: Re-Boot Camp)

Recent changes made to audio emulation improved performance and solved crashes, but also had an interesting regression. Some sound effects played at a slower speed.

After doing some extensive reverse engineering, Maide reached the conclusion that due to how the DSP works, a 5 ms timeout is needed in the processing wait. With the timeout implemented, SUPER MARIO ODYSSEY and Kirby Star Allies, among others can now play back their audio at full speed.

danilaml continues to deliver the good stuff. This time, simply updating cubeb (one of our audio backends, and most of the time the default one) fixed a bug that muted the emulator after waking the PC from sleep. Feel free to close your lids and continue later!

Users noticed that after recent changes to fix the wire audio in SUPER MARIO ODYSSEY, audio in many games could desync and sound crackled or distorted. bylaws suggested allowing the audio buffer to wait indefinitely if a queue is too big, so Maide implemented this idea and et voilà, the problem is gone! (Pardon my French; Spanish is cooler).

UI improvements

If your yuzu is configured with multiple user profiles, and the Prompt for user on game boot option in Emulation > Configure > General option is enabled, you will have to click the profile you want to boot and then click OK. Well, for the newcomer Qigo42, this was unsatisfactory, so they allowed the profile selection pop-up to work with just a double click! Nothing beats quality-of-life changes. Thank you!

jbeich is back, fixing BSD support again! It’s always good to have more OS alternatives working.

Continuing the trend in quality-of-life changes, newcomer grimkor has a nice gift for us.

And now, for your convenience…

A context menu for the filter and antialiasing options! You no longer have to go through the entire list of options if you want to try a different one, simply right click and choose. Thank you!

If you double clicked a game in the game list, you could end up double clicking it again or pressing enter before the game list got unloaded, which would cause yuzu to try to load the game twice, and usually just crash. german77 fixed this up by immediately disabling the game list after a game has been launched.

Hardware section

We no longer only support the PC! In future articles, we will include any news for Android GPU vendors.

NVIDIA

We have some good news and a little disappointment for the Green Team. But first, we have some progress with the Maxwell and Pascal situation.

In the past, we used to recommend users to stick to older driver releases for the GTX 750/900/1000 series, as anything newer than the 470 driver series was unstable. Thanks to the work done with the garbage collector for Tears of the Kingdom, we now know that the problem with these cards is how the driver handles out-of-memory situations. We were even able to observe it on Turing cards with 4GB, so it wasn’t unique to older cards, we just didn’t have a game that used VRAM as much as Zelda.

We reported our findings to NVIDIA with a test case, so it’s in their hands now.

As the VRAM fills up, an AMD card will get slower and slower until it stops working and crashes yuzu, while an NVIDIA GPU would corrupt the entire desktop, taking all the displays with it, sometimes even forcibly rebooting the system.

Using the ASTC recompression option helps a lot to avoid this problem. But if it does happen, it can still cause a system lock or reboot, so we need a way to mitigate this while NVIDIA investigates the issue.

Now playable with only 2GB of VRAM! (The Legend of Zelda: Tears of the Kingdom)

Fortunately, we stumbled upon a stopgap measure that solves the problem, and we updated our recommended settings guide to include it. Just change Vulkan/OpenGL presentation method in the NVIDIA Control Panel to Prefer layered on DXGI Swapchain. The same setting used to get AutoHDR working helps contain the out-of-VRAM crashes. Using this in combination with BC1 ASTC recompression will make old 2GB cards run without crashes.

This interface is so old…

Switching to the the good side of news, HolographicWings made an amazing tutorial on how to use DLDSR in yuzu here. DLDSR is a way to use the Tensor cores available in RTX cards to upscale the image. You can consider it a mix of DLSS and FSR 1.0, as it works for any game, but uses deep learning instead of traditional filters. Needless to say, it’s a great way to improve image quality if you have the hardware to test it.

And in other good news, Special K now supports HDR in Vulkan and it works with yuzu! NVIDIA is still the only supported vendor, as this is only possible thanks to the magic Prefer layered on DXGI Swapchain option, but the quality and customization offered by Special K over AutoHDR is outstanding. That expensive OLED never looked so tempting.

Note that we have confirmed in testing that Prefer layered on DXGI Swapchain needs to be manually enabled for Special K to work properly. This also includes other NVIDIA-exclusive goodies such as input lag reduction thanks to NVIDIA Reflex. Feel free to experiment with the app, it’s amazing.

Here are some comparison pics in .jxr format, they can be opened with the default Photo app included with Windows 11, and an SDR control capture in .png format:

First the scene in SDR, the default experience.
Windows 11’s AutoHDR with the Cemu renaming trick.
SpecialK’s HDR with Perceptual Boost disabled.
SpecialK’s HDR with Perceptual Boost enabled.

Keep in mind, Special K needs to be tuned to the capabilities of the display, and my humble 350 nit Gigabyte G27Q is a disservice to what this change can do on actually good HDR displays. Expect better results if you have an OLED, or a display with dimming zones and a higher peak brightness.

Now, on to the disappointing news: the RTX 4060 Ti.

We don’t understand what kind of decisions NVIDIA took when deciding the Ada Lovelace GeForce product stack, but it has been nothing but mistakes. The RTX 4060 Ti 8GB with only a 128-bit wide memory bus and GDDR6 VRAM is a serious downgrade for emulation when compared to its predecessor, the 256-bit wide equipped RTX 3060 Ti. You will be getting slower performance in Switch emulation if you get the newer product. We have no choice but to advise users to stick to Ampere products if possible, or aim higher in the product stack if you have to get a 4000 series card for some reason (DLSS3 or AV1 encoding), which is clearly what NVIDIA is aiming for.

The argument in favour of Ada is the increased cache size, which RDNA2 confirmed in the past helps with performance substantially, but it also has a silent warning no review mentions: if you saturate the cache, you’re left with the performance of a 128-bit wide card, and it’s very easy to saturate the cache when using the resolution scaler — just 2X is enough to tank performance.

Spending 400 USD on a card that has terrible performance outside of 1X scaling is, in our opinion, a terrible investment, and should be avoided entirely. We hope the 16GB version at least comes equipped with GDDR6X VRAM, which would increase the available bandwidth and provide an actual improvement in performance for this kind of workload.

AMD

AMD has shown steady progress with each new driver release and, thanks to this, the experience on yuzu is in very good shape for Radeon owners, besides some documented hardware limitations causing graphical issues we’ve mentioned in the past.

The main exception is a rendering issue affecting Tears of the Kingdom, which only happens with RDNA3 hardware, the RX 7000 series.

Both the RX 7900 and RX 7600 series are affected. (The Legend of Zelda: Tears of the Kingdom)

As you can see, the textures get mangled in an interesting way. We couldn’t find any issue in the code, and older hardware is not affected, so we submitted a simple test case to AMD to demonstrate the extent of the problem. Affected users will have to wait to see if future driver updates solve this.

Intel

After the… peculiar discussion we had with Intel regarding their drivers and how they handle bug reports, we are happy to announce the latest public beta driver solves the SPIR-V issues we reported seven months ago! We strongly recommend Intel Windows users to update to this driver to improve stability with most games.

Sadly, fixing this issue showed us two areas where yuzu is at fault. But luckily both issues have fixes in testing in the latest Early Access release (at the time of writing). If everything goes according to plan, they should hit Mainline in a few days. Stay tuned.

The first problem is in yuzu’s code. Some compute shaders have barriers in places that result in generating invalid SPIR-V code, and while NVIDIA and AMD have no problem with it, Intel is following the Vulkan specification much more closely and doesn’t like the result, leading to crashes. While we test the solution, for now we recommend Mainline Intel users to keep the freshly added Enable Compute Pipelines (Intel Vulkan only) disabled in Emulation > Configure… > Graphics > Advanced.

This is just temporary (famous last words…)

The other issue is a hardware limitation. Intel decided to remove support for Float64 operations on their Generation 12 graphics products (UHD 700/Xe/Arc) without providing a driver fallback. Well, it turns out that, for unknown reasons, Tears of the Kingdom requires over the top precision in its cutscenes — precision that current Intel hardware physically lacks, causing us to crash when building the shader. We’re testing a Float64 to Float32 shader conversion to solve the problem. For now, Mainline Intel users will want to use a save that’s past the intro cutscene, or use OpenGL, as the OpenGL spec dictates that Float64 must be supported one way or another, even if it is via software emulation.

Currently, the game is playable at a mostly-consistent 30 FPS with an i5 1240P running an Iris Xe iGPU (if you stick to handheld rendering), and exhibits better performance than AMD’s Vega iGPUs.

For those interested in the experience with desktop products, here is footage captured with an Arc A770 16GB:

Your browser doesn't support mp4 video. :(

Arc is viable! (The Legend of Zelda: Tears of the Kingdom)

Future projects

We don’t have much to announce for now regarding ongoing projects — we were very busy with Tears of the Kingdom and the Android release!

GPUCode is working on a couple of cool things. One of them is implementing a way to have an equivalent to DXGI presentation working on Intel and AMD hardware; that way, AutoHDR can be used with any GPU vendor, not just NVIDIA.

That’s all folks! For real this time. If you’ve reached this point, thank you for your patience and for reading to the end. We hope you’ve enjoyed this mega-report! See you next month! ~~We all need some sleep…~~

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

New Platform Release - yuzu on Android

CaptV0rt3x — Tue, 30 May 2023 00:00:00 +0530

Hey there, yuz-ers! We are happy to announce that yuzu is available, today, for Android! There’s so much to discuss and show you, let’s get started!

Where do I get it?

If you’re too excited, you can jump in immediately by downloading yuzu from the Google Play Store!

Download yuzu for free, or support us and receive some fantastic benefits with Early Access.

The GitHub releases aren’t live yet, but we will edit this article with a link to download them once they are. This initial release won’t have parity with the feature-rich Desktop builds of yuzu, but we are looking forward to introducing all the features you love as we fine-tune them for Android.

⚠️ Update

Standalone GitHub releases are now available here.

Features such as multiplayer over LAN/LDN, Input Profiles, TAS, etc. are not yet available. For now, we want to focus on compatibility and performance as performing cutting-edge emulation on typical Android hardware has several challenges.

If you’re still reading, make sure to stick around for a little development history, expectations, and compatibility reports!

Breath of the Wild (Samsung Galaxy S20 FE, Mesa Turnip GPU driver Vs. Samsung Galaxy S23, Qualcomm proprietary GPU driver)

Why?

In the past year, we have made significant strides in improving both the accuracy and performance of yuzu. And with many more such improvements in progress, we understood that the longer we waited, the more challenging it would become for us to support an Android build.

With this public release, all future yuzu development activities will account for, and address, both feature and platform compatibility for Android. This is expected to help facilitate and streamline our development process to better achieve our goal of platform independence.

We hope to welcome Android developers interested in lending their expertise to a cutting-edge project and produce new yuzu features, optimizations, and other improvements!

You're finally awake! yuzu on Android launched! (Samsung Galaxy S20 FE, Mesa Turnip GPU driver)

State of things: Where are we? What can users expect?

Before we talk more about where we are and what users can expect, we would like to make a few things clear:

We’re committed to improving the feature parity, compatibility, and performance of our Android builds; most improvements for desktop platforms, like Windows and Linux, will also help improve our Android users’ experience.
yuzu Android is in rapid development and early builds should be considered akin to a beta.
Expect to see a variety of results regarding compatibility and performance on different devices, discussed in more detail later.

With that out of the way, let’s dive into the state of things for yuzu Android.

Some background

Like our sister project, Citra, yuzu has always been developed with multi-platform support in mind. We’ve supported major desktop operating systems, such as Windows and Linux, since the earliest builds of yuzu. yuzu’s core code has, by design, been kept modular and frontend agnostic to ensure any future efforts to expand supported platforms does not run into unwanted dependency issues.

Although we originally couldn’t support macOS due to Apple deprecating OpenGL support on it, there has been a recent rekindling of efforts to support macOS using MoltenVK — and it so happens that the new Macs are powered by 64-bit ARM-based Apple Silicon (M1/M2, at the time of writing) SoCs (System-on-Chip). But then we faced another hurdle — Dynarmic’s lack of host recompilation support for ARM64.

In case you weren’t aware, yuzu uses Dynarmic for its CPU emulation. Dynarmic works by recompiling (translating) the Nintendo Switch’s (guest) ARM CPU instructions to the user’s (host) CPU. And because Dynarmic didn’t yet support recompiling guest code for ARM64, yuzu’s CPU emulation couldn’t work on any of these host CPUs.

Thanks to the efforts of byte[] and merryhime, this hurdle didn’t stand in our way for too long. With ARM64 host support ready to go, byte[] set his sights on getting yuzu to work on macOS. But that’s a story for another day.

By the way, did you know that there are other platforms that use ARM64 SoCs extensively?

Bringing yuzu to Android

Knowing that Dynarmic support for ARM64 host recompilation was underway and that Vulkan support on Android would probably be better than macOS, we were optimistic about getting yuzu working on Android.

flTobi and bunnei quickly started putting things together, with the first goal to simply get yuzu building for Android. These early builds lacked a working renderer to display graphics, but progress was promising. After some fixes, they got a few 32-bit games such as Mario Kart 8 Deluxe and Captain Toad: Treasure Tracker booting with just the audio.

Once the Dynarmic ARM64 support was completed, byte[] joined them and the trio got working on getting the Vulkan renderer backend working on Android. While OpenGL ES didn’t pan out, bunnei was able to get yuzu to render basic homebrew on Android with Vulkan:

Snake, try to remember the basics of rendering

With our lead moderator Flamboyant Ham working on a new input overlay design and app themes, german77 started working with them on integrating the input backend to the touch-screen overlay. As a sudden surprise for us, developer t895, who’s been improving Dolphin’s Android app, accepted our request and joined the team to work on overhauling our app UI.

Peruse our settings and customize as you see fit!

Together, with Flamboyant Ham creating the designs and t895 working his dev magic, an onboarding process and search menu were added, helping users select their keys, games folder, and search for titles with ease!

Simple and straightforward - our favorite!

Special thanks to the Citra GPU dev, GPUCode, for taking their time away from Citra Android and Vulkan development to improve this release with their special sauce Async Presentation .

What to expect?

Android is a platform that boasts a huge userbase, but brings with it its fair share of problems. As there is a lot of hardware variation for Android devices, compatibility and performance will vary. So, to temper expectations, we would like to clarify our minimum requirements for the near future.

Hardware requirements

At the moment, yuzu requires devices powered by Qualcomm Snapdragon SoCs which have Adreno GPUs. Devices powered by SoCs like Exynos, Mediatek, etc. are expected to not work at all due to their “worse-than-Adreno” GPU drivers, at least for the near future.

⚠️ Update

yuzu now supports Xclipse based and Mali G-series based SoC GPUs.

Also, yuzu on Android has high RAM requirements, therefore fairly high-end devices provide the best experience (e.g. SD 865 and 8GB of RAM or better).

yuzu on Android ships with the ability to run custom GPU drivers, such as newer official Adreno drivers, or Turnip using libadrenotools to improve the performance on older generation Snapdragon SoCs. Apart from this, there are still many more Android-specific optimizations to be done. We have plenty of opportunity to improve performance, but this explains the current high minimum system requirements.

This initial release has been intentionally kept fairly minimal so that we can focus on improving performance and stability. As stated earlier, feature parity with our PC builds is something we’re committed to, but expect it to happen slowly and not immediately.

Performance and Compatibility

Regarding software requirements, yuzu requires Android 11 or newer and a myriad of mandatory Vulkan extensions that the Play Store will automatically check for. That being said, the Android GPU driver ecosystem is very inconsistent; not all devices will be the same. Being able to download and install yuzu doesn’t mean the performance or compatibility will be great. As expected, Qualcomm is (currently) king here.

All Qualcomm device users will have the option to test different Mesa Turnip driver versions, thanks to libadrenotools. We will link them in our Discord server. You can download any compatible drivers, and select them by going to Settings > Install GPU Driver > Install in yuzu.

Just tap on Install!

The latest is not always better, and specific games may prefer specific drivers.

Currently, the best compatibility is achieved using Adreno 600 series GPUs running the Mesa Turnip drivers. If you want games to start and render correctly, this is the way to go.

The best performance comes from Adreno 700 series hardware (Snapdragon 8 Gen 1 and newer), which won’t have Turnip support for a while. While performance is typically higher, you will experience rendering issues or some games refusing to start.

⚠️ Update

Current Turnip drivers provide good support for both Adreno 600 and 700 series hardware, but performance is still better with official Qualcomm drivers in the few games that render correctly with them.

With that said, take a look at some performance numbers from several games:

Not too shabby for a first release!

We think that devices with Exynos 2200 and newer SoCs running AMD RDNA2 GPUs could also work well, but we haven’t been able to test them out due to how hard they are to find.

⚠️ Update

Samsung's Xclipse 900 series GPUs are perfectly usable now.

Available information suggests they run some older form of the AMD proprietary driver, so support may be somewhat good knowing AMD’s track record.

Regardless of the device, disabling Docked mode and/or using lower resolution multipliers can help with performance in most games. However, your mileage will vary here. Some games may prefer docked mode, and some drivers don’t play well with resolution multipliers under 1x. You’ll have to test and see what works for you!

We're still figuring out what the best settings are for each game, so please experiment!

Cooling is an important factor of performance as well. We tested several devices with the Snapdragon 8 Gen 2 SoC, and while a gaming-oriented Redmagic 8 Pro had no problems keeping its clock speeds high (even locked to maximum) and temperatures low, a regular Samsung Galaxy S23, on the other hand, is a boiling machine, climbing to 90°C in seconds. This temperature won’t damage the device, as TjMax is at 100°C, but higher temperatures do lead to lower clock speeds.

Hand warmer included (Pokémon Sword)

Overheating leading to thermal throttling can result in a 30-50% performance loss over time, so this is one of the few times when gamer-gimmick marketing isn’t lying.

Regarding other specs, RAM is crucial. The recommended value is 8GB or more, big emphasis on more, and the absolute minimum is 6GB, but this will lead to many resource intensive games crashing. The Legend of Zelda: Tears of the Kingdom requires 12GB at the moment.

Storage is not a critical aspect, but keep in mind that Switch games are typically large — there are visual novels over 20GB, and that’s not counting updates and DLC.

Controller input support is in its early stages. The ability to configure multiple controllers and their button mappings is currently being worked on, but not yet ready. Xbox, PlayStation, and Switch Pro controllers are automatically mapped when they are paired over Bluetooth. Generic DirectInput controllers are supported, but until more development time is spent dedicated to them, you may see some mapping issues and potentially missing mappings for buttons. Joy-Cons are not supported for now, Android doesn’t allow access to them so they will have missing functionality.

An on-screen input overlay will always be available, and it can be hidden while playing. Swipe from the left side of the screen and toggle Input Overlay > Show Overlay if you want to disable it. The Button and Stick placements can be adjusted here as well.

Adjust to your liking

Setup guide

If you need help setting up yuzu, our Quickstart Guide will provide all the steps required to get up and running. All the same requirements apply, including having a PC and the mandatory hacked Nintendo Switch. The yuzu on Android onboarding process will have you select the location of your prod.keys file.

The only major difference is that the yuzu folder is located in Android/data/org.yuzu.yuzu_emu/files, which you will need access to in order to install Switch firmware files and any preferred mods. A quick-and-easy management interface for DLC, updates, mods, and saves will be added at a later date, so for those who dare, the process must be done manually for now (or copied from your PC installation of yuzu).

In recent Android versions, Google started blocking access to app folders in file managers, so it is recommended to instead use Android’s integrated file manager to access the yuzu folder. Here is a link to an app that allows users to have direct access to it.

Alternatively, you can always connect the phone/tablet to your PC via USB cable. No restrictions apply there.

Conclusion

And there you have it! We’re excited for the opportunity that Android provides us, to hear all of your feedback, and we hope you enjoy playing!

The Legend of Zelda: Tears of the Kingdom

We don’t have anything else to talk about for now, but please enjoy the below selection of screenshots taken from yuzu on Android!

Media

The Legend of Zelda: Tears of the Kingdom (Samsung Galaxy S20 FE, Qualcomm proprietary GPU driver)

Super Smash Bros. Ultimate (Samsung Galaxy S23, Qualcomm proprietary GPU driver)

Mario Kart 8 Deluxe (Samsung Galaxy S23, Qualcomm proprietary GPU driver)

Super Mario Odyssey (Samsung Galaxy S20 FE, Mesa Turnip GPU driver)

Animal Crossing: New Horizons (Samsung Galaxy S20 FE, Mesa Turnip GPU driver)

The Legend of Zelda: Link's Awakening (Samsum Galaxy S23, Qualcomm proprietary GPU driver)

The Legend of Zelda: Skyward Sword HD (Samsung Galaxy S20 FE, Mesa Turnip GPU driver)

Donkey Kong Country: Tropical Freeze (Samsung Galaxy S20 FE, Mesa Turnip GPU driver)

Fire Emblem Engage (Samsung Galaxy S23, Qualcomm proprietary GPU driver)

Metroid Dread (Samsung Galaxy S23, Qualcomm proprietary GPU driver)

Pokémon Sword (Samsung Galaxy S23, Qualcomm proprietary GPU driver)

Pokemon Legends: Arceus (Samsung Galaxy S20 FE, Turnip GPU driver)

Super Mario 3D World + Bowser's Fury (Samsung Galaxy S23, Qualcomm proprietary GPU driver)

Atelier Ryza: Ever Darkness & the Secret Hideout (Samsung Galaxy S23, Qualcomm proprietary GPU driver)

Diablo III: Eternal Collection (Samsung Galaxy S23, Qualcomm proprietary GPU driver)

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report April 2023

GoldenX86 — Wed, 10 May 2023 12:00:00 -0300

Hello yuz-ers! There were fewer individual changes this month, but the changes that were made are substantial! You won’t want to miss this.

Poor Melia up there.

Project Y.F.C. 1.90!

Blinkhawk showed up one weekend and asked, “Want to test a 50% performance boost and almost perfect rendering on Normal GPU accuracy?” And that’s exactly what we did.

A more accurate name for this change would be “a rewrite of the Buffer Cache Rewrite”, perhaps rBCR for short? Essentially, Blinkhawk rewrote most of the old buffer cache changes that Rodrigo introduced two years ago, taking into account the new demands of recent games and the issues found with the original BCR.

Part of the work also involves:

Allowing the verification of fencing and writing of asynchronous downloads in a separate thread
Restructuring how accuracy is managed by skipping host-guest fence synchronization and not downloading on host conditional rendering for normal GPU accuracy
Improving consistency for Query Cache asynchronous downloads

The results are amazing. Most games that used to need High GPU accuracy to render correctly can now run on Normal with no issues. Additionally, all this wizardry reduces bandwidth usage and boosts performance up to 87% for everyone (50% on average), from the low-end APUs to the high-end beasts.

Here’s an incomplete list of changes:

As noted previously, many games which required High GPU accuracy to be visually accurate now work with Normal GPU accuracy with minimal sacrifice.
Particles and character lighting/shading in Pokémon Sword & Shield have been fixed on Normal GPU accuracy. Performance has improved by up to 40% on Normal GPU accuracy.
Models (the BowWow, for example) and particle rendering are fixed on Normal GPU accuracy in The Legend of Zelda: Link's Awakening. Performance on Normal accuracy, with correct rendering, is now up to 70% higher than before.
Lighting in Diablo II: Resurrected has been fixed and will no longer flicker.
Lighting and shadows in Luigi's Mansion 3 will no longer randomly flicker.
Pokémon photograph detection and data of New Pokémon Snap has been fixed on Normal GPU accuracy. This results in up to a 50% increase in performance with working photograph detection.
Kirby and the Forgotten Land vertex explosions, lighting, and particles have been fixed on Normal GPU accuracy. This results in an up to 40% performance increase, with accurate rendering on Normal accuracy.
Red lights in some machines in Xenoblade Chronicles 2 have been fixed.
Fire Emblem Warriors has been accurately fixed and no longer requires a workaround.
MONSTER HUNTER RISE now accurately renders on Normal GPU accuracy, resulting in an up to 50% performance increase (note, however, that updates after 3.0.0 still have issues and require more work).
Vertex explosions in Persona 5 Royal no longer occur with Normal GPU accuracy, resulting in an up to 30% increase in performance.
Atelier Ryza series games now render correctly.
The pessimistic flushes option in advanced graphics settings is no longer needed in any of the affected games it benefitted and we have now removed it.
Mortal Kombat 11 no longer has any vertex explosions.
NieR:Automata The End of YoRHa Edition now renders correctly.
Bayonetta 3 no longer requires High GPU accuracy to render correctly.
Splatoon 2’s ink physics work correctly on AMD GPUs while using High GPU accuracy.
Particles in The Legend of Zelda: Breath of the Wild have been fixed, resulting in 40% higher performance and accurate rendering on Normal GPU accuracy.
Tree flickering in The Legend of Zelda: Breath of the Wild has been fixed on all GPU accuracy options.
And much, much more!

No option needs to be enabled to take advantage of all of this, just switch GPU accuracy to Normal if you haven’t already. What are you waiting for?

Here are some stats of some of the most popular games. We compared High GPU accuracy in Mainline 1407, and Normal GPU accuracy in Mainline 1421. All tests are done at 2X resolution scaling, and using mods to disable dynamic resolution when possible.

Hardware makers cry over this kind of free performance boost

And then we have these four, the high FPS squad. They’re reason enough to consider asking the modding community to start releasing 240 FPS mods!

When you gotta go so fast on a previous generation CPU that a second graph is required

Expect even higher numbers with a Zen 4 3D V-cache chip. For example, in the same testing spot of Breath of the Wild, a non-3D 7900X gets 90 FPS.

Your writer’s PC is feeling like a snail compared to the current monsters on sale…

Other graphical changes

Citra-legend GPUCode stepped up to give us a hand with presentation. Presentation is the final step of most graphics code — the process of getting the output to the screen.

GPUCode’s work moves swapchain operations to a separate thread in order to avoid stalling the main GPU thread. This improves performance in more demanding titles and on low-end hardware, and can make the difference between barely getting 60 and getting a smooth 60 frames per second in many cases.

However, it can also make the frametimes less consistent, therefore we’ve turned it off by default to allow for further testing. We need to determine which systems and games benefit the most. For those interested in trying it, the toggle is available in Emulation > Configure… > Graphics > Advanced > Enable asynchronous presentation (Vulkan only).

Share your experience with us!

vonchenplus continues to work on making the code match the information NVIDIA has made public in their latest documentation.

You may remember Wollnashorn from their role in overhauling the Vulkan pipeline cache. Now, Wollnashorn presents us with a technique to bypass hardware limitations in order to make The Legend of Zelda: Breath of the Wild render accurately on non-NVIDIA hardware.

Object edges, especially grass blades, had distinct black borders on AMD and Intel GPUs. The issue occurred regardless of the driver in use, so it was clearly a hardware limitation, and an incompatibility with what the game expects. The Legend of Zelda: Breath of the Wild uses a technique called deferred rendering–in this particular case, shadows render at half the resolution. Four pixels of the full resolution depth texture are sampled simultaneously with a textureGather call. textureGather has the characteristic of working with normalized floating-point coordinates for the texture, so each fragment is always at the boundary of the four selected pixels.

The four special pixels

Now, textureGather uses floating-point, and each GPU design will have a different rounding precision. Additionally, thanks to a blogspot by Nathan Reed, we know the integer coordinates of the pixel on the texture are calculated by the GPU after a conversion from a floating-point number to a fixed-point number.

With floating point conversions involved, you may be able to tell where this is going. If the user’s GPU is not using the same rounding precision as the Nintendo Switch, different pixels can be sampled. Ergo, only NVIDIA GPUs got the four correct pixels the game intended.

How did Wollnashorn solve this? With a clever little trick, of course. Adding a very tiny (1/512) subpixel offset to the sample coordinates is sufficient to fudge the rounding. Achieving that required modifying the code of the SPIR-V and GLSL backends, altering how the operation is handled only for AMD and Intel hardware for now, with the option to force it for any other future hardware that may require it, for example, a certain fruit company.

Here’s the final result:

Funny how we end up sharing the same problems Cemu faced (The Legend of Zelda: Breath of the Wild)

Something we have to mention is that this doesn’t fix a very similar-looking black line issue present when using anisotropic filtering values higher than Default with AMD and Intel GPUs. That’s a separate issue and we recommend Red and Blue Team users to at least set a per-game setting for The Legend of Zelda: Breath of the Wild to set it to Default only. The game doesn’t benefit from higher values anyway, since its terrain textures don’t seem to take advantage of it.

That’s a clean look all around (The Legend of Zelda: Breath of the Wild)

Linux got its well deserved share of love too thanks to byte[].

First up, he fixed up initialization of the Vulkan swapchain on Wayland, helping Linux NVIDIA users to be able to launch their games. As some of you may know, NVIDIA was historically very stubborn about their support of Wayland, and it doesn’t help that most Wayland compositors are very stubborn on their own too. The year of the Linux desktop, always around the corner…

Second, he fixed a crash that happened to Flatpak users trying to play Bayonetta 3. An out-of-bounds could occur in an array access intended for size estimations, leading to “nasty stuff”. A small adjustment, and the issue is no more. Nice pull request number there.

Speaking of out-of-bounds, Maide found an interesting case happening in corner sampling due to a previously added offset. Not accounting for this offset caused another out-of-bounds situation during 2D texture blitting.

Fixing this special case solved the depth-of-field rendering issues in Kirby Star Allies.

Poyo! (Kirby Star Allies)

Still on fire, and with more work to come, Blinkhawk hasn’t stopped. For something light, he decided to refactor a big part of Accelerate DMA to do texture downloads through the texture cache instead. The result is a return to the performance Pokémon Sword & Shield and Hyrule Warriors: Age of Calamity had before the old Y.F.C 1.75 changes. Add up the gains from Y.F.C 1.90, and you have a winner for low-end systems!

We have many more changes Blinkhawk implemented, but they didn’t make it in time for the deadline for the progress report, so we will be mentioning them next month.

General changes and settings glossary

The modding community requested us to allow for larger texture mods. The old 6GB limit was not enough, so byte[] expanded it to support a custom 8GB arrangement instead, giving almost all of it to the emulated program.

However, this had unforeseen consequences.

We discovered that users like to enable settings without knowing what they do. Shocking, right?

Having a much higher amount of memory available than the normal development console would has caused problems. For example, after getting several reports of Pokémon failing to respawn in Pokémon Scarlet & Violet after playing the game for a few minutes, we narrowed the changes down to users with this setting enabled.

However, this option is only meant for very large texture mods, and should not be enabled unless you are using such a mod. Unfortunately, it was on the first page of the yuzu settings when opening it, so it was a very visible setting. Additionally, we found some YouTube tutorials which incorrectly suggested it may improve performance and stability, and users followed that. This would have resulted in 4GB of extra RAM wasted for no benefit, and potentially caused issues in games.

To try to prevent this, we recommend reading our new settings glossary, which together with our recommended settings page, should help people understand what each setting does, and what’s recommended to change.

Moreover, to solve the problem for the users who don’t check our official channels, byte[] moved the setting to the bottom of the System tab, and renamed it, ensuring that no previous configuration file will enable it again without user intervention. If you have a real need for extended memory layout, make sure to manually enable it again. Or don’t, we won’t judge you… too much.

You have been relegated to System settings

Users reported that IGS Classic Arcade Collection wasn’t playable. vonchenplus investigated the cause and found the reason in our audio emulation. Apparently the game doesn’t do a very good job implementing its audio code on the Switch, and fails to initialize a new audio output session, which should return an error. Properly returning this error as a result is enough to get the game working.

Nothing beats the classics (IGS Classic Arcade Collection)

One of the options made available to our LDN users is the ability to create private rooms, providing hosts with several options to configure their servers as they want.

twitchax knows that for certain server hosts, such as fly.io, a custom bind address is needed. They implemented the functionality and now users can pass the --bind-address argument to the room’s configuration. Thanks!

Continuing his work on improving CPU timing accuracy, Morph fixed confusion between the raw CPU frequency and Counter-timer Frequency, or CNTFRQ. The difference between the two is that CNTFRQ reports the frequency of the system clock, instead of the CPU frequency. While fixing this, he also reduced the time it takes to measure timing information by about 60%.

What does this mean for the user? A sweet 1-7% performance boost.

Input changes

Also known as german77’s section.

How you interact with a game might just be more important than even graphics or audio. After all, it’s what differentiates it from a CG animated movie. As it is tradition by now, our dear Kraken has been working on further improving yuzu’s input emulation.

A big part of the work of writing an emulator involves reverse engineering, so he’s been working on making the NFC service match what the Switch does internally — in this case, implementing all the remaining missing interfaces, putting them on the same level as what the real console does.

This next change is a simple revelation that came from the work done on TAS. If you implement a virtual controller, it won’t need range and dead zone settings as it will be virtually perfect (sorry, not sorry).

But not all work was done by german77, v1993 caught a little nasty bug that slipped by. Motion emulation with mouse movement is handled by a 3D vector (x, y, z). Yes, surprise math lesson, deal with it. Anyway, yuzu was doing this:

(x, y, z) = (x, y, z) + (1, 2, z)

Which results in:

(x + 1, y + 2, 2z)

The z component was being doubled by mistake!

The solution is to instead do:

(x, y, z) = (x, y, z) + (1, 2, 0)

Which gives us:

(x + 1, y + 2, z)

And now all’s right with the world. This should improve the quality of mouse motion, for those that prefer an FPS experience with a keyboard and mouse. Or just like to torture themselves.

Hardware section

A recurring problem users face when running modern emulators that utilize Vulkan is the lack of a way to get helpful feedback if the program crashes. Vulkan is very picky. Any wrong step in the middle and it will refuse to start, and any Vulkan layer program can cause this. Anything from outdated screen recorders, to mod managers, performance overlays, and even the disaster code motherboard vendors call RGB software. Of particular nasty interest is the Epic Game Store’s overlay, which is reported to cause severe performance issues.

To some extent, yuzu can detect these problems and switch to OpenGL to avoid them, but that doesn’t tell the user where the problem is. We recently found out about a cute little program the RPCS3 community has been using for some time to diagnose these problems, VkDiag. You can find its latest version here.

What this program does is list all relevant components and layers affecting Vulkan rendering and warn about potential problems in any of them.

It's already been combat tested, both outdated drivers and broken layers are in its sights

We have started using it in our support channels with amazing success, and we recommend self-serving users to keep it in their toolkit. You never know when that OBS install you forgot to update can cause you problems, or when that RGB software decides to go rogue.

NVIDIA, enjoying Auto HDR

Here’s some great news for Windows 11 users rocking HDR displays. Some time ago, GitHub user svonolfen in our issue tracker found an interesting way to make Auto HDR work with NVIDIA GPUs. Here’s the link. By renaming yuzu to “Cemu” and performing additional steps, Auto HDR is suddenly functional.

Don’t mind the Spanish

Cemu gets privileges, indeed. This is only available for NVIDIA Windows drivers because, at least for now, only the NVIDIA Control Panel offers the option to force a DXGI swapchain — effectively making the Vulkan program present to screen as a Direct3D one. This has a few benefits: Auto HDR works, improving dynamic range considerably, borderless optimizations are applied to yuzu, improving input lag and frame synchronization, and the G-Sync/Freesync issue is solved. It has a downside worth mentioning, it can be up to 5% slower than regular Vulkan presentation.

Don’t forget to set up your NVIDIA control panel accordingly!

While this fun renaming works fine, we also heard from Windows Insider users that future versions of the Xbox Game Bar application will allow yuzu to work with Auto HDR without doing any renaming. This will most likely require newer NVIDIA drivers to work.

If you own an HDR-compatible monitor and want to compare the results, here’s a .jxr HDR capture that the default Windows 11 photo viewer can open, and a comparable .png native SDR capture. You will of course need HDR output enabled in both your display’s and Windows 11 settings. Notice the difference in the sky and lamps. The tonemapping isn’t perfect, but we will never get Switch games outputting native HDR anyway.

Your writer’s simple HDR400 display with no dimming zones is enough to notice the benefits, so here’s your excuse to convince your parents/wife to buy that OLED monitor you’ve been eyeing for weeks. Zelda. In HDR.

A Vulkan extension can be implemented in yuzu to get global support for any GPU. You can be sure I’ll be nagging our GPU devs until it gets added.

AMD, delivering on their promises

Last month, we mentioned that AMD introduced a regression that caused graphical corruption and crashes with some games.

We’re happy to announce that since driver version 23.4.2 and later the issue is resolved for Vega and newer, allowing Radeon Windows users to fully benefit from the new Vulkan extensions supported by the latest drivers, reducing shader building stuttering to a minimum. Just as AMD promised, except…

Polaris (RX 400/500 series) cards may still be unstable under some rare cases, but a fix shouldn’t take too long to appear. In the meantime, Polaris users should stick to driver 23.3.1, unless they want to face results like this:

Your whole desktop looks like this

On another topic, we reported to AMD what we suspect is the cause of the Pentelas Region vertex explosions in Xenoblade Chronicles 3, which also now affect the initial regions in its new expansion, Future Redeemed.

That’s the water performing the mother of all vertex explosions (Xenoblade Chronicles 3)

Since the issue affects both the official AMD and Mesa drivers indiscriminately, we suspect it’s a hardware limitation — possibly the lack of support for D24 depth formats, which many games utilize (Xenoblade games included), and both NVIDIA and Intel support.

That’s what a hardware limitation looks like

Intel…

As we’ve been previously reporting, Intel Windows Vulkan drivers are unstable. The SPIR-V compiler (the part that handles Vulkan pipeline shaders) can crash working on compute shaders and some specific shader instructions.

We found a case where the driver crashes when compiling a shader with more than 5 cases in a switch block, or more than 5 if-else blocks of the same condition. Maybe an optimization gone wrong?

If you uncomment out the last two cases, the driver crashes

We reported the crash to Intel six months ago, and their reply this month was:

Thank you for reporting this issue. Our priority is to target the most popular games and apps to focus our efforts on providing a high quality, stable experience for the broadest set of users. We will continue to improve our software performance and compatibility throughout 2023 and beyond.

So even after waiting six months with a test case provided, the reason explained, and even after pointing out where in the driver the crash happens, Intel can’t find the time to fix the issue. This is some kind of twisted joke. For comparison, when you do this with NVIDIA, they hire you.

We’re left with no option but to mitigate the crashes as much as we can. To do so, Morph disabled compute shaders entirely for Intel Windows drivers, ensuring games like The Legend of Zelda: Breath of the Wild can still boot ― even though they’ll have gameplay issues as a result.

This isn’t enough to solve all crashes. Some games like Xenoblade Chronicles 3 will still crash the shader compiler. We haven’t diagnosed this yet, but believe that it’s likely closely related to the same issue we have already reported.

Disabling compute shaders produces this lovely side effect on some games like Super Smash Bros. Ultimate:

That’s what happens when we’re forced to remove an entire pipeline stage, Intel (Super Smash Bros. Ultimate)

For those that prefer proper rendering on Intel Windows drivers, can tolerate the random crashes, and don’t want to just use the actually working Linux Mesa drivers, Mainline 1414 is currently the last version with support for compute shaders. We’re working to add a toggle that can be configured per game.

But wait, there’s more, the fun doesn’t stop there. Reddit users discovered that Intel 12th and 13th Gen CPUs running on Windows 11 have noticeably worse frametimes than the same hardware running on Windows 10.

What would EA say to this

So if you notice stutter while playing, the solution may be quite simple: perform a clean Windows 10 install!

Future projects

So releasing Project Y.F.C in parts paid off. Blinkhawk is working on the final part of it, which includes a restructuring of the GPU accuracy settings, and a few other surprises. Stay tuned.

You will also hear news about Project Lime very soon!

That’s all folks! Thank you for reading until the end, nothing makes us happier.

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report March 2023

GoldenX86 — Mon, 10 Apr 2023 12:00:00 -0300

Hi yuz-ers! We’ve been working hard as usual, and this March saw improvements in performance, graphics, audio, CPU precision, input, and much more!

Making CPUs go the opposite of BRRRR

One of the biggest changes this month is the set of improvements in CPU accuracy. This requires some backtracking so let’s rewind a little bit.

Back in July, we explained how CoreTiming operates in its current form, using a host timer. A thread called HostTiming is used to process HLE events such as input and audio. However, some of these events, like audio, require a high level of timer precision to behave the way games expect, more than Windows would usually allow.

By default, Windows only allows a precision of 1ms since the OS event loop runs at 1000Hz. This is not enough. However, devices running Linux, BSD, and MacOS don’t face this limitation and can achieve μs (microsecond) levels of precision.

If a game wants to run at a frametime of 16.67ms (60 FPS), you could wait for 17ms two-thirds of the time and 16ms for the remaining one-third, but this has already proved in the past to be terrible for audio accuracy. The alternative, and old method in use for Windows, is to wait for 16ms and do a busy wait for 0.67ms. During that 0.67ms, the CPU thread isn’t doing anything and consumes power without actually working.

Here comes the benefit of removing support for Windows 7 and 8/8.1. The Windows 10 SDK has new undocumented functions, NtSetTimerResolution and NtDelayExecution, which allow improving timer resolution down to 0.5ms. This allows yuzu to wait for 16.5ms and only spin the remaining 0.17ms, which is four times shorter than the previous default method.

By implementing these new functions, Morph reduced the time the CPU spends in a spinlock, resulting in reduced CPU usage for timing-heavy games like Kirby Forgor 💀… Kirby and the Forgotten Land, and Super Smash Bros. Ultimate. The new free resources mean better performance for low core count CPUs such as quad cores, and for systems with limited power budgets such as laptops and handhelds. With this change, we measured up to a 24% reduction in CPU use or power consumption, depending on the limiting factor.

Left: old 1ms precision; Right: current 0.5ms precision. The result comes from your writer’s laptop which runs a Single Language Windows installation, so don’t mind the Spanish. Note that there is a difference in CPU use between the two results

If you can perform more tasks in the same power envelope, you can improve performance without sacrificing battery life. Alternatively, a more common scenario for an emulator, if your ceiling is a fixed framerate, you can reduce temperatures.

This is why the lap in laptop is a lie, mind the package temperature (Xenoblade Chronicles 3)

Users reported that games have less audio stuttering thanks to the improved timer precision.

Another nice tool that the Windows 10 SDK adds is allowing us to set yuzu as a HighQoS process, hinting to the Windows scheduler that if there are higher performance cores available, they should take priority. This further improves performance for current Ryzen CPUs by suggesting to use the best cores of a CCX, and for Intel 12th Gen and newer, by prioritizing P-cores (“performance cores”, normal cores).

It’s heavily recommended to keep chipset drivers up to date to take the best advantage of your hardware.

If the CPU performs in a more efficient way, how do we go even further beyond? Well, Morph figured the next step is to improve how the CPU counts time itself!

On modern CPUs using the x86 architecture, the invariant timer is fetched with the the RDTSC instruction. The thing with RDTSC is that… it isn’t accurate over longer periods. It can’t be on multicore processors.

The small differences between what RDTSC provides as a best estimate and actual reality causes time drift in games like Super Smash Bros. Ultimate. You may notice this issue surfaces its ugly head as inaccurate match times. Intel 12th Gen, the most affected CPU architecture we measured (also all the way back in July), was as bad as a second off per minute.

Morph’s solution to this issue is to spawn an extra thread whose task is to take two measurements of the TSC for 10 seconds, then take that difference and apply it to know how many actual ticks have passed in those first 10 seconds. If you then divide the number of ticks by 10, you get the exact frequency the host RDTSC timer was running at.

Good thing we don’t have to use old stopwatches for this (Super Smash Bros. Ultimate)

The result is practically perfect timing on Ryzen and Intel 11th Gen and older systems, and almost perfect timing on 12th Gen Alder Lake systems. Having completely different cores counting time simultaneously inside the CPU is not pretty for this specific application. We can’t defeat the hybrid asymmetric nature of Intel’s design, but we managed to reduce the drift from a second per minute, to a second every 5 minutes or so.

“Okay, this is pretty good” said Morph, but how can you go even deeper? The only option left is to drop to assembly.

The optimization in question is currently only available for 12th Gen and newer Intel CPUs; AMD has not added support for it yet. We’re talking about TPAUSE (CPUID name WAITPKG), a new instruction from Team Blue which allows the CPU to enter a lower power state and idle until a precise amount of time has passed.

Some testing was required to specify the correct number of cycles for the wait period; a wrong value would reduce precision too much on one extreme, or not produce any benefit on the other. 100000 cycles was the magic number in Morph’s testing, which reduced CPU use/power consumption by up to 20%, on top of the previous benefits.

If only Intel GPU drivers worked, their Xe equipped laptops/handhelds would now be very viable yuzu gaming machines… Oh well, 12th/13th Gen users running actual working GPU drivers from NVIDIA or AMD will benefit greatly from all this work.

Graphical changes

Enough with the CPU improvements. What about graphics? Well, we have quite a bit to talk about.

Users reported interesting colour banding on STORY OF SEASONS: A Wonderful Life. Maide dug deep into the issue, and identified the culprit in S8_UINT colour formats, like D32_FLOAT_S8_UINT and S8_UINT_D24_UNORM. With some trial and error, and some big help from the great bylaws (from the Skyline emulator), Maide managed to sort out the issues, providing accurate colour rendering without breaking other games.

Now you can enjoy this farming simulator, with all its vibrant hues, without having to worry about colour banding. Isn’t that a-moo-sing? (STORY OF SEASONS: A Wonderful Life)

epicboy strikes again with his ninja updates. This time he gives some love to the still thriving OpenGL gang, bringing all the goodies of AccelerateDMA, which we discussed in the last report.

This means that OpenGL users, especially those with Fermi and Kepler GPUs, can enjoy the speed boost of this pseudo-Y.F.C. 2 change, making games such as Metroid Prime Remastered run much faster. No more waiting for Samus to load her arm cannon.

We strongly advise users of older hardware without good Vulkan support to upgrade to something newer, as support for OpenGL is soon nearing its End of Life. That being said, thanks to epicboy, those who can’t upgrade won’t suffer from terrible performance using the old but gold OpenGL API.

But that’s not all, epicboy also added an optimization for GL_SYNC_STATUS, boosting performance slightly. Your writer observes a 3-5% performance increase in The Legend of Zelda: Breath of the Wild, one of the few games that runs faster on OpenGL with NVIDIA hardware, if you ignore the shader stuttering.

From 54 to 57 FPS in one of the heaviest spots in the game, OpenGL still has life in it! For now… (The Legend of Zelda: Breath of the Wild)

bylaws came to the rescue again, pointing out that our old Vulkan scheduler implementation had some regressions back in October of last year, when byte[] worked on making homebrew apps work with Vulkan.

This meant that games and homebrew would have to wait for a frame to show up on screen before starting to render, which in some cases is a bad example of feedback looping at its worst.

By waiting in the background for the queue to be emptied without having to wait for the frame to be presented, byte[] fixed the regression. Thanks bylaws!

Remember that lovely game we talked about last month? The one for all ages! Totally safe to play with your family.

vonchenplus decided to make it playable, so ~~weebs~~ players around the world could enjoy the amazing gameplay of Moero Crystal H, by fixing some errors in how yuzu processed the inline index and draw texture commands.

Cultured gaming (Moero Crystal H)

A recent system update for the Steam Deck messed up the graphics in many games. The culprit? Some issue with VK_EXT_extended_dynamic_state3, one of the Vulkan extensions that helps reduce shader building stutter.

A combination of yuzu expecting NVIDIA driver behaviour, and a difference in the latest Mesa implementation on the Deck caused what you see next:

Looks like someone spilled some paint on the screen (The Legend of Zelda: Breath of the Wild)

byte[] disabled the feature that caused the problem for now, but we’ll reconsider turning it on again in the future as it’s very likely Mesa has already fixed the issues on their end.

Here’s a couple of important fixes for the Xenoblade fans, which Maide spent a lot of time working on.

Shaders were broken in-game due to issues with sRGB border colour conversions in the samplers. This is a process that converts colours from one colour space to another. This would cause inaccuracies that made some checks fail on affected shaders, resulting in discarding the wrong pixels as shadows.

We need more information to fully understand the issue, but for now, ignoring colourspace transformations on sRGB samplers allows for hardware-accurate rendering.

Rex knew what the future held for him, wink wink (Xenoblade Chronicles 2)

The other long-standing issue affecting the Xenoblade trilogy (well, Definitive Edition and 2 at least) has been plaguing yuzu since the legendary Texture Cache Rewrite. It was the random “rainbow mode” that could happen anytime during gameplay, or in a specific late-game cutscene in Xenoblade Chronicles 2 that I won’t spoil for new players. If you played it in yuzu, you know which one. It makes you wonder if you’re in Rapture.

Somewhere, beyond the (cloud) sea! (Xenoblade Chronicles 2)

Another observed problem was excessive lighting making the whole scene unreadable (especially at night with an HDR display, not a pleasant sudden flashbang).

My eyes! (Xenoblade Chronicles 2)

Maide found that the issue was caused by replacing fresh guest data with stale host data in the environment lighting cubemaps. The solution is to only copy data that has been marked as GPU-modified, following the behaviour of the Buffer Cache Rewrite.

This isn’t 2009, we don’t need this much bloom, thank you very much (Xenoblade Chronicles: Definitive Edition)

With these changes, few graphical issues remain affecting the Xenoblade Chronicles saga, making it a great choice to enjoy on yuzu from start to finish. Then you can join your writer in debating over which Queen is the best.

Since this issue only happens the first time the cutscene renders, I’ll cheat using bug report pics, bite me (Xenoblade Chronicles 2)

Newcomer rschlaikjer, I hope I pronounced that right, has been digging deep into the texture cache, trying to figure out why a simple visual novel like Tsukihime -A Piece of Blue Glass Moon- would stutter when changing scenes. Maybe it’s because the game is too emotional for the emulator to handle.

The culprit was a missing reference operator when capturing the GPU page table, which caused the table to be copied over and over again thousands of times per second. That would make anyone stutter, let alone an emulator. Converting the capture to a reference solved the issue, and it might also fix similar problems in other games.

We’re glad rschlaikjer caught this bug before it got out of hand. We don’t want to end up like that chair.

UI changes

Some issues are so elusive that they go unnoticed for years. Some issues are so complex that they require a deep understanding of all the layers involved to find the right solution. They frustrate many developers who give up, hoping someone else will have better luck.

And some issues are just plain silly. Like when a game crashes because the default user profile is damaged.

german77 found a simple fix for crashes in dozens of games: setting the default profile picture to a real 32x32 resolution instead of 0x0. That’s it.

Continuing to work on UI improvements, german77 also moved the last audio setting Mute audio when in background to the Audio section, where it belongs. No more wandering around in General for this option.

Good, proper order

This next one is a great improvement for UX (user experience), and a huge relief for me personally. Before, when using per-game controller profiles, if you forgot to change your input settings before starting a game, you would lose them when the game closes and have to set them up again next time.

epicboy fixed this annoying issue and german77 merged the changes. Thank you so much for this fix.

german77 is also working on making the profile selection applet better. The current changes are just the beginning, we will keep you updated on any progress in the future.

Input improvements

Let’s talk about input, where german77 continues to shine.

Not satisfied with the mouse and keyboard experience when playing Metroid Prime Remastered, german77 set the default mouse sensitivity to 50% and removed the smoothing filter, improving the performance on high DPI gaming mice after getting valuable feedback from Metroid fans. He also lowered the motion threshold, clamped the rotation speed, and accumulated all input until delivery, which fixed the delay and choppiness of the previous implementation.

Have you noticed how Samus lacks a lead indicator? Her suit couldn’t spare a tiny bit more processing power for that? (Metroid Prime Remastered)

Thanks to those changes, Metroid Prime Remastered showed that it could be a great PC game. If only Nintendo would let it out of its dungeon.

A common question we get is “will this third party Switch controller work?” The short answer is maybe, but the long answer is a bit more complicated.

According to Nintendo’s API, Joy-Cons have two modes: active and passive. Official Joy-Cons use active mode, but some third party controllers use passive mode, usually because they don’t follow the API properly and don’t support any configuration commands. They just run with the default settings, for better or worse.

That doesn’t mean passive controllers are useless. They still work on the Switch. But it does mean that they work differently. Active controllers update their status every 15 ms, while passive controllers only do it when something happens, such as a button press or release.

Well, it turns out yuzu didn’t support passive mode until now! So german77’s changes made a lot of third party controller users happy. That’s quite handy, considering how many unofficial controllers are out there.

The battle with vibration goes on! While doing his usual research, german77 found out that if you have more than one player using the same type of controller, or if you use a dual Joy-Con setup with a single controller, you can end up sending two vibration commands to the same controller in a row. This can be annoying, and it also takes up the limited bandwidth of Bluetooth connections.

The solution is simple: only take the latest element in the cool vibrations queue for each controller, check if the controller can handle the requested vibration, and ignore the rest.

We all love Quality of Life changes, right? Even if they are not very flashy.

Let’s talk about the Controller Applet, which is responsible for asking players to choose their input settings when the game requests it. Until now, the applet was unskippable; you had to give a valid answer to continue with your game. While this was passable, it’s bothersome and inaccurate. Some games go back to a previous menu instead of getting stuck in an endless loop if the players can’t or won’t confirm their input style.

You shall pass!

german77 solved this behaviour, and while at it also solved a bug where the player count wasn’t correct.

german77 implemented the… hold on, let me catch my breath first, SetNpadJoyAssignmentModeSingleWithDestination service call. He implemented it hoping to make Let’s Get Fit playable, but unfortunately there are more issues in the way.

Changing topics to Amiibo support, a lot has happened this month.

First of all, german77 managed to write the correct CRC, making Amiibo data written by yuzu compatible with the Switch; no more invalid info.

Next, if you tried to connect a controller while scanning an Amiibo, it would not be recognized. By accounting for this and initializing or finalizing the controller, he fixed the issue.

And last but not least, to wrap up the Amiibo saga, Herman the German Sherman added support for plain Amiibo files. Some Amiibos, like the ones themed after Super Smash Bros. Ultimate, can be edited without the need of keys. Now yuzu can read non-encrypted game data from your Amiibos correctly!

Audio fixes

Maide managed to spot a bug in how the reverb pre-delay line was being read, causing problems in the output. Solving it by correctly reading via input instead of output gives games like New Super Mario Bros. U Deluxe proper audio. Now you can enjoy Mario’s voice without any echo. Mama mia!

bylaws has been digging deep into audio synchronization, improving the codebase here and there, and managing to avoid stalls by linking the guest sample tracking to the host.

This change caused some regressions, as some games are very sensitive to audio scheduling requirements. Users reported popping sounds after the merge, so bylaws improved the situation by adding a constant 15 ms of latency to the sample count reporting.

Other code changes

Fire Emblem fans have been experiencing freezes in-game, and after some investigation, Morph found out that the culprit was the bounded threadsafe queue, introduced with a pull request from behunin.

The queue’s job is to pass events from an event producer (like the CPU cores) to an event consumer (like the GPU thread). The previous implementation, which behunin replaced, kept allocating and freeing memory, causing periodic latency spikes.

The way to solve this issue is to turn the queue into a bounded queue, meaning no memory allocation is needed as there is a fixed amount of resources available. And that’s what behunin did, but the new queue implementation seemed to be buggy. Morph added a simplified implementation, fixing the new gameplay freezes affecting Fire Emblem: Three Houses and Fire Emblem Engage.

Your writer re-enabled LTO for GCC builds, following the changes made for Windows last time, but only applying the optimizations to the core and video_core subprojects, providing Linux users a nice, free performance boost.

Hardware section

AMD 23.3.2 and newer drivers

One bad and two good pieces of news.

On the positive side, AMD has finally added support for the missing dynamic state extensions in their latest Windows driver release, which improves the shader build times and reduces the stuttering on Radeon GPUs, making them perform on par with NVIDIA.

However, on the negative side, this driver update also introduces a serious regression:

This can affect your entire desktop (Metroid Prime Remastered)

Some games, such as Metroid Prime Remastered and Pokémon Legends: Arceus, trigger what seems to be an out-of-bounds crash that causes desktop corruption and a driver crash. We advise users to stay on driver version 23.3.1 or older for now. Some older Radeon cards may also benefit from using 23.2.2.

We reported this issue to AMD and they promptly confirmed it, reproduced it, and informed us that they are working on a fix.

Now that’s how you do customer support.

Speaking of which…

Doing Intel’s job

While testing a crucial rendering fix for The Legend of Zelda: Breath of the Wild that we will discuss next month, Morph did some feature testing to investigate what makes Intel Windows drivers run so horribly.

His findings are both expected and disappointing. The main culprit for about 95% of the crashes is a faulty compute shader stage in the drivers. Disabling compute shaders like we used to do for older Intel hardware makes most games run, but not all. We still don’t know the cause of the crashes when opening the menu in Xenoblade Chronicles 3.

We’re now trying to figure out what triggers the compute shaders to crash the driver like this, but this also raises a dilemma. Should we patch the issue ourselves, making game rendering worse and letting Intel off the hook, or should we leave it broken so they have to fix it properly?

The solution while the investigation continues is to use ol’ reliable Linux, or avoid buying hardware that relies only on Intel GPUs. Sigh.

Future projects

We’re not even halfway through April and I’m already thrilled about what’s coming up in the next progress report. The devs are on fire and they’re not stopping anytime soon.

Maide is working on more improvements for the Xenoblade series, such as fixing the cloud flickering in Xenoblade Chronicles 2, the particle effects in Xenoblade Chronicles 3, and the texture flickering that affects the whole saga and some other games. However, these fixes come at a performance cost, so he needs some help from another GPU developer to optimize them. Maybe Blinkhawk could lend a hand?

Nintendo contributed in releasing the holy grail of Vulkan extensions, VK_EXT_shader_object. This extension promises to cut down the amount of work needed to build shaders significantly, as its dependencies suggest, requiring support for all previous dynamic state extensions.

Most likely Nintendo intends to use it for their internal emulators, maybe for “backwards compatibility.” Regardless of any of that, we have a lot of work ahead of us to add support for this extension.

But enough about that. Let’s talk about some exciting projects in the works.

Flute intensifies

Regarding Project Gaia: it is still in development.

Oh, and Project Lime is in release candidate status, under intense internal testing.

That’s all folks! Thank you for sticking around until the end of this progress report.

Thanks to Bing Chat for the terrible jokes.

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report February 2023

GoldenX86 — Sun, 12 Mar 2023 12:00:00 -0300

Hello yuz-ers! This month has seen changes across all aspects of yuzu. We have improvements in the GPU, Kernel, Services, Input, User Interface and Experience, Driver related rants, and more!

Project Y.F.C. 1.75?

Another month, another Project Y.F.C. addendum. Introducing one of the features that was missing from the previous 1.5 release.

Blinkhawk implemented host texture download acceleration for the Switch’s DMA engine (or Accelerate DMA for short).

DMA acceleration reduces a ton of overhead by letting the GPU handle texture downloads, improving performance considerably with games that aren’t CPU bottlenecked.

yuzu, in the past, ran everything via the host’s CPU and system memory, with the process of swizzling/unswizzling textures being a primary task. Now this process is done on the GPU and its VRAM, saving CPU cycles and avoiding having to transfer information back to system memory, and giving us access to the vastly superior bandwidth available in a modern GPU’s video memory.

When you find a game that benefits from faster texture downloads, the numbers speak for themselves:

Bottleneck busters!

Other GPU (and video) changes

Before going over the rendering changes in GPU emulation, let’s cover something we haven’t touched in a while: video decoding.

Firstly, vonchenplus improved the speed at which video frame data is copied. That is, as long as the compiler notices the optimization and makes use of it. When it works, this has the added benefit of reducing the time it takes to start playing videos.

Next, Maide disabled multi-frame decoding, which caused a frame of delay, giving Maide the option to also set the decoder to use all available CPU threads. While most people don’t have issues with video decoding performance, people running old GPUs, for example AMD Polaris series (RX 400/500 cards), will use their CPU for decoding VP9 videos, as these older cards lack the required hardware decoder.

Games such as The Legend of Zelda: Skyward Sword HD will provide much smoother video playback with these changes.

Okay, enough about pre-rendered 2D frames in sequence, what about real 3D stuff? Happily, we have a bit to talk about.

behunin is back, optimizing the gpu_thread code. The gpu_thread has one job and only one job, to consume its command queue. The problem is that it was also generating commands as well as consuming them. By getting rid of this undesired behaviour, the gpu_thread is back to only consuming commands, leaving the road open for more future fixes.

Even from the shadows, epicboy still gifts us a handful of new toys. A true Eminence in Shadow.

Avid readers may remember that MSAA image uploads hold a weird spot in Switch emulation. There’s a conflict between what the Switch can do with its native NVN API, and what our available graphics APIs (OpenGL and Vulkan) allow.

Both OpenGL and Vulkan are very restrictive regarding MSAA texture uploads and copies, leaving epicboy with the only remaining tool available. Yep, you’re right! Time to use a compute shader!

Your browser doesn't support mp4 video. :(

Breaking the rules to get proper rendering (Sonic Forces)

This way, rendering is accurate. Do keep in mind that this is an implementation only for OpenGL. Vulkan, as always, is much more work so it’s homework for later.

While working on fixing regressions in Blinkhawk’s cached writes pull request affecting Yoshi's Crafted World (the game would freeze when using Normal GPU accuracy), epicboy also fixed Pokémon Scarlet/Violet’s missing building geometry issues.

No more ghost town (Pokémon Scarlet)

Ahh, ASTC, most of you know the struggle by now. Mobile devices like phones, tablets, Macs, the Nintendo Switch, among others, have native support for this very compressed texture format, but laptop/desktop/server GPUs don’t. This leaves the Switch emulation community struggling with ways to mitigate the slow process of decoding these textures on hardware that is not designed for such a task.

Yes, even the weak and outdated Switch beats an RTX 4090 in this task. Bet your wallet isn’t happy about that fact.

yuzu’s weapons in this fight so far were multithreaded CPU decoding, and GPU decoding via compute shaders, which takes advantage of the huge parallelization power of modern GPUs. Both solutions have stuttering always present while the decoding takes place, especially in new games that overly use large ASTC textures, like Bayonetta 3 and Metroid Prime Remastered.

Well, epicboy adds a new weapon to our arsenal, and oh boy it can help. At a price. Introducing Asynchronous ASTC texture decoding!

For those that prefer zero ASTC related stuttering during their gameplay, this new toggle uses a background thread to decode ASTC textures while the game is being rendered. Such an approach will eliminate stuttering, but has the cost of introducing graphical glitches until the textures finish loading in.

Here’s a comparison of asynchronous decoding with a 16 threads Ryzen 7 5800X3D (so not even the king of the hill in thread count, what matters the most for CPU decoding), vs an RTX 4090, the biggest commercially available compute monster for consumers right now.

Your browser doesn't support mp4 video. :(

GPU compute shader decoding on the left, asynchronous CPU decoding on the right (ASTRAL CHAIN)

As you can see, while the process taking place is pretty obvious to the eye with asynchronous decoding, it’s significantly faster than the best GPU available right now. Even a 12-thread CPU would still win a drag race in the most intensive ASTC game ever, ASTRAL CHAIN. Users with lower thread count CPUs (like quad cores with 8 threads or lower) may need to time their results.

You can find the option in Emulation > Configure… > Graphics > Advanced > Decode ASTC textures asynchronously (Hack). Enabling it will also override the setting Accelerate ASTC texture decoding in the Graphics tab. This setting makes yuzu use the GPU, but enabling Decode ASTC textures asynchronously (Hack) will force yuzu to always use CPU decoding. So remember to disable asynchronous ASTC decode if you want to use GPU compute decoding instead.

We recommend low CPU thread users to stick to GPU decoding

According to epicboy, while an asynchronous GPU compute method is possible, the rules and limitations of compute shaders hinder its potential, most likely making it barely any better than regular GPU decoding with the compute units.

Life would be so much easier if GPU vendors properly added native ASTC support to their GPUs… Your reporter would gladly take it over useless stuff like RGB, ugly plastic shrouds, or driver DVDs.

NVIDIA, AMD, please consider adding native ASTC support. It’s certainly more useful than generating fake frames with disgusting artifacting. Intel, you had great ASTC support in your iGPUs. Consider adding it back to future versions of Arc graphics.

Maide has been working on trying to solve the overlapping textures glitches that can be spotted in games like The Legend of Zelda: Breath of the Wild and Xenoblade Chronicles 3. While it isn’t a perfect solution, re-adding the (accidentally) removed invalidate_texture_data_cache register helps mitigate the issue at almost any camera angle except the most oblique ones.

We present you: New crack sealer! Move the camera and the cracks are gone! (The Legend of Zelda: Breath of the Wild)

Depending on the shape of the terrain, or the camera angle, the issue can surface again. But as a temporary solution, this change makes playing affected games much more tolerable. Work continues!

CPU, kernel, services, and optimizations

Merry updated dynarmic , our JIT, to version 6.4.5, solving some issues and improving compilation times. One game that benefited from this is Taiko Risshiden V DX, which got its load times reduced considerably.

Take your time (Taiko Risshiden V DX)

byte[] has also been going deep into the kernel code. One of his changes improves the SVC wrappers. But what are the wrappers? Well, games and homebrew need to talk to the kernel, and to do so they use SVC instructions, which act as an interface with the kernel.

The return of mspaint

The work of the wrapper is to translate a request from the game into a C++ call into the kernel, and then get the result from the kernel back into the game. In the past, yuzu used manually written wrappers that were very error-prone. With this change, byte[] instead automatically generates the needed wrappers. This code is far more accurate, so if you find games that no longer crash or soft-lock, here’s the new code responsible for it. One such example is Moero Crystal H which starts booting for the first time.

Don’t judge, it’s part of the Switch’s library (Moero Crystal H)

This game requires more work to get proper video and gameplay rendering.

Keeping the pursuit for accuracy, byte[] also implemented HLE multiprocess for services. Now instead of pushing the game’s requests to the services, the services wait for the requests to arrive. All this processing is done, for the most part, in what would be the emulated core 3 of the Switch, instead of all over the place with one thread per service. Games usually only have access to cores 0 to 2, so we’re now dedicating the last core for system service processing, just as the actual Switch operating system does!

This part of CPU emulation is one of the main reasons we recommend at least 6 cores in our hardware requirements, 4 for uninterrupted emulation of the Switch’s CPU, and extras for other processes and tasks. Just a 4 core CPU will be usually overburdened. HT/SMT may help, but that will always depend on the workload at any given moment. A SMT/HT thread can’t improve performance in a significant way if the core is already saturated.

bunnei chimed in too, fixing a mistake in memory mapping. We erroneously used the (bear with me, it’s not a redundancy) system’s system resource tracking, instead of relying on the application’s resource tracking when loading programs into memory. Most games were tolerant to this, but FINAL FANTASY CRYSTAL CHRONICLES Remastered Edition didn’t like it, getting stuck every time the user tried to load a save. A tweak here and there and the regression is now gone!

Feel free to progress the game now (FINAL FANTASY CRYSTAL CHRONICLES Remastered Edition)

New Pokémon game update, new things to fix. Once again, Pokémon Scarlet/Violet is giving us a headache.

This time, the recently released update 1.2.0 wouldn’t boot on yuzu. After investigating for a bit, german77 found out that the cause was that some Bluetooth functions weren’t properly implemented, causing the game to crash when attempting to start with the latest update installed.

Mandatory protagonist seat (Pokémon Scarlet)

Some code changes later, and german77 fixed the issue! Now anyone can enjoy the reduced NPC count and lower draw distance.

Even your writer tried to give a hand (emphasis on tried). As reported in the past, we applied Link-time Optimization to all of yuzu’s subprojects. This meant that every section like audio, input, UI, etc. used LTO at build time, trying to squeeze out every possible bit of performance. This caused an unexpected problem: RAM consumption while building increased enough to cause our buildbot to cry for help, causing builds on our Azure DevOps CI to randomly run out of memory.

byte[] suggested that I instead profile which subprojects would provide the most performance boosts, and to only apply LTO to those. A few rounds of toasting a CPU by building yuzu later, and it was determined that the two most obvious candidates, core and video_core, were the responsible ones for the performance boost provided by enabling LTO.

Partially applying LTO to only the core and video_core projects not only reduced compiler RAM use, but also provided a very minor but still consistently measured performance increase. For example, The Legend of Zelda: Link’s Awakening increased from 257 FPS to 260 FPS. Nothing groundbreaking, but it’s a free bonus from a change that was only intended to reduce RAM use!

Morph later added a small but very critical fix to get all this actually working. I’m a disaster, sorry.

Input improvements

Metroid Prime Remastered introduced a serious dilemma: People want to play the game as an FPS with mouse and keyboard.

This game is gorgeous, like Samus (Metroid Prime Remastered)

The problem is that the game uses motion on top of stick input to aim, making it an interesting case for how to handle non-controller input.

This was incentive enough to get german77 interested in giving it a try:

First off, he fixed an issue where motion would be constantly getting recalibrated.
Next, german77 tweaked the mouse scaling for users running a DPI scaling higher than 100% (1.0x).
Following up, the mapping for mouse input was improved. By default a mouse to stick is considered a joystick, which includes assuming deadzone and ranges that aren’t zero by default. This pull request includes some other miscellaneous changes, like fixing some UI elements not working.
And finally, to address Metroid Prime Remastered’s “Dual Stick mode”, support for dedicated motion using the mouse was added. Since the game only uses two axes, this can be directly mapped 1:1 to mouse movement, making aiming a breeze!

To use this feature, go to Emulation > Configure… > Controls, click on Motion 1, then click again to set the mouse to motion. Then in the Advanced tab, enable mouse panning. After that map the keys manually as if to configure an FPS.

GitHub user SixelAlexiS90 provides an input profile. To use it, on yuzu go to File > Open yuzu folder and place this input profile inside the config\input folder (make a new “input” folder if there isn’t one). All that’s left to do after that is to select the profile in yuzu’s control settings.

The user can adjust the sensitivity of mouse motion with the same setting used for mouse panning in Emulation > Configure… > Controls > Advanced

Remember to set sensitivity to your liking

But did german77 focus on nothing but Metroid Prime Remastered? No. Continuing the work started in December of 2022, support for Pro Controllers within the new custom “Joy-Con” driver. Since the option is experimental, it only works properly on official Switch Pro Controllers and not with third party controllers, so it’s disabled by default. Owners of real Pro Controllers are encouraged to enable this option, as it will provide much improved motion and HD Rumble support.

Not the same screenshot as the previous one, I swear

Previous limitations, like being unable to use a Pro Controller for Amiibo detection, still exist as there’s still work to be done.

Audio improvements

There are some interesting changes in audio emulation that many users will be happy about, let’s go one by one.

A crash was fixed by german77 when initializing cubeb, our default audio library. Guess having fewer crashes is always good, right?

Merry made an attempt at fixing a rounding issue in the bi-quad filter.

While the intention of this change is to partially improve the audio quality in several games, most notably Metroid Prime Remastered (the game of the month), it didn’t quite hit the mark. This wasn’t enough to solve the random noise issues affecting the game, so Maide set out to investigate and found out that the audio emulation codebase was incorrectly saving the state of all different audio channels in the same address!

As you can imagine, if the left audio channel stores some samples, the right channel does the same (overwriting what the left channel stored), and then the left channel fetches back something unexpected, the result can sound… interesting. Users described this problem in Metroid as “if someone shot a gun right by your ears”.

Now each audio channel stores its information in different memory regions, avoiding any issues with overlapping access. Not only Metroid Prime Remastered benefits from this; both Fire Emblem games have shown improvements as well.

Clown Swimsuit (Fire Emblem Engage)

Another issue Maide found was a missed check causing an array index to read negative values, which is, in simple terms, “very wrong”. This was causing the audio engine to grab random chunks of memory as information for mixing, crashing the audio engine, and yuzu with it.

Solving this oopsie resolves crashes happening while playing Metroid Prime Remastered, and most likely others too.

UI changes

The LDN lobby window got some love from newcomer unfamiliarplace, adding the option to hide empty rooms. Nothing beats quality of life changes like this, thanks!

Only the dankest rooms, please

For Discord gamers, SoRadGaming implemented proper game images for your Discord Status! The images are grabbed from our compatibility wiki, which is under a rewrite, so expect some games to be missing for now.

Make your friends envy you with this simple trick!

A small mistake caused the web applet to lose the ability to redraw and zoom its content when resizing the yuzu web applet window. Re-adding the setZoomFactor call fixes the scaling, allowing players to fit their Mario Manual to their needs.

Per-game settings are very useful, but also very tricky to get right codewise. m-HD greets us by adding a few missing graphical settings to the list, solving conflicting issues when setting the fullscreen mode, resolution scaling, filter, and antialiasing values in the per-game configuration window.

german77 then properly implemented per-game configuration support for the Force maximum clocks setting AMD GPUs benefit so much from.

While we are constantly working to improve the user experience, yuzu sometimes does crash. That’s expected of any first generation emulator, but what shouldn’t happen is not saving changes made to the configuration settings after a crash or a force close. The problem was in our Qt UI, and german77 worked to properly tell Qt to save and sync the configuration to file, avoiding any configuration change loss after a force close.

General fixes

MonsterDruide1 continues to do wonders with the LDN code. This time, proper error handling. One of the possible errors when handling TCP connections is ECONNRESET, which happens when the other end closes the connection abruptly. Old-school gamers call this “rage quitting”.

Jokes aside, when a sudden disconnection like this happens, the error used to get caught by yuzu instead of the game, causing the game to never get the notification of the client disconnection. Properly passing the error through to the game allows it to handle the issue its own way instead of crashing the yuzu LDN session.

Some improvements were done to yuzu-cmd, the command-line alternative to the default Qt UI.

german77 added support for touch inputs from mouse clicks and SDL controller input support, and two parameters: -g for specifying a game file location and -u for specifying a user profile.

Your writer also showed up, updating the graphical filters and resolution multiplier options that were recently added to the Mainline yuzu.

Hardware section

NVIDIA driver 531.18, it’s a good one

This latest (at the time of writing) release of the NVIDIA driver, 531.18, includes support for VK_EXT_extended_dynamic_state3, a Vulkan extension previous readers will be familiar with. Having this extension supported means fewer shaders need to be built, resulting in a smoother experience thanks to reduced shader stuttering, and lower RAM use.

We recommend at least Turing and newer (GTX 1600, RTX 2000-4000) users to update, as we expect this release to not fix the issues affecting Pascal and Maxwell hardware (GTX 1000 and older).

AMD Ryzen 7000X3D series, and the importance of Game Mode

AMD recently released their Zen 4 CPUs with 3D V-Cache technology, and in an effort to copy Intel in weirdness, they decided to release a top of the line asymmetric design with the 7950X3D.

Only one of this gaming-beast CPU’s two CCDs (modules containing 8 cores each) has access to the expanded L3 V-Cache, and the decision on which one to use is up to Windows Game Bar. To our dismay, there is no hardware scheduler here. The chipset driver and a Windows toggle decide which mode is better.

Since yuzu, and basically any other emulator, are not registered as games by Windows, the user will have to manually intervene and enable Game Mode in order to let the chipset driver profile performance and decide which CCD will perform the best.

Doing this should also benefit every user, not just 7000X3D ones, as Windows uses the toggle to allocate resources (RAM, threads) to the affected program, so it’s not a bad practice at all!

Here are the steps:

With yuzu or any other emulator/program of choice open, press Windows + G, and go to the Settings cogwheel.

Bet you didn’t know about this extra bloat in Windows

Then enable Remember this is a game.

And just like that, better performance!

That’s it!

Now Windows will allocate resources in a smarter way, and Ryzen 7000X3D users will get the best performance out of their shiny new CPU. Testing also shows that this helps improve performance with proper P-Core and E-Core allocation on current Intel CPUs too. For older Ryzen users, the latest chipset update that enables the performance profiling for the 3D Zen4 products reportedly also improves performance slightly.

Who can say no to free performance after two clicks, right?

Intel, please fix your Vulkan support

We’re waiting for Intel to fix their SPIR-V compiler crashes on the Windows drivers. In its current state, any game can crash at any moment if you use Vulkan, and unlike AMD who solved most of their OpenGL issues with a rewrite, Intel doesn’t get a fallback option with the old graphics API, which in its current state renders almost everything in black.

This crash can happen at any moment

Frustratingly, this isn’t a problem with the Mesa Linux drivers, or the old Gen9/9.5/11 iGPUs and its discontinued Windows drivers, so it’s a proper critical regression affecting the new driver branch that will have to wait until AAA native PC games are running well enough to give the developers time to focus on the “less important stuff”, like professional programs, and console emulators.

Future projects

I’ve been kidnapped by our devs, so no leaks this time. I promise more for next month!

There is one thing I’m allowed to mention, recent core timing changes have reduced CPU use by 5-20% across the board on Windows depending on the total thread count. This means better performance and reduced power consumption, especially benefiting mobile devices like laptops and handhelds. This change is already in both Mainline and Early Access, but we’ll talk more about it and other nice things next month.

That’s all folks!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report January 2023

GoldenX86 — Sat, 11 Feb 2023 12:00:00 -0300

New year, more work to do! 2023 started with a plethora of graphical changes, audio and input improvements, TAS and LAN/LDN fixes, and more! Stay tuned yuz-ers, this is just the start of what’s to come this year!

New challenger approaching!

During the time it took to merge last month’s Project Y.F.C. 1.5, several other GPU related changes had to be delayed. One change that slipped by, made by a new contributor, improved the Vulkan experience so dramatically, it almost feels like cheating… The change is simple: instead of relying on the GPU driver to store and validate the pipeline cache (a.k.a. the shaders), and having the usual suspects like the Windows AMD driver fail to store 95% of them because of some arbitrary low size limitation, Wollnashorn decided that doing it with the official Vulkan API is better.

By storing the entire pipeline cache in a custom file among yuzu’s folders, AMD GPUs running on Windows can now properly load large caches in mere seconds, as it should be. This has saved me literal hours of time while playing Xenoblade Chronicles 3 with an RX 6600, as the game has the lovely perk of many heavy shaders. Booting the game with 25000 shaders used to take close to 15 minutes, with the driver only providing the first 3000 shaders or so, and the rest always being recompiled. The process now takes mere seconds.

Your browser doesn't support mp4 video. :(

NVIDIA and Intel are faster at shader building than AMD

But this isn’t just another fix for AMD Windows users. While the objective was accomplished, the benefits didn’t stop there. As it turns out, locally stored files are much quicker to save compared to relying on the GPU driver. Possibly due to fewer checks being performed? All GPU vendors see reduced stuttering when facing new shaders!

The usual limitations apply: the cache still asks the driver for validation, so updating it to a newer or older version will require a recompilation, and since the cache is vendor-specific, you won’t get to keep the cache if you switch to a new GPU from another vendor. (And we’re glad there are more than two options now.)

While Wollnashorn intended this feature to be optional at first, we consider it fully stable, so it’s now enabled by default. Anyone interested in testing disabling it will find the new option in Emulation > Configure… > Graphics > Advanced > Use Vulkan pipeline cache.

Vulkan only, OpenGL is not this flexible with compute work

Wollnashorn, delivering another amazing entry for the new year, implemented support for AMD’s FidelityFX Super Resolution (FSR) in the OpenGL backend. While AMD only really intended this adapting filter to be used with Vulkan and Direct3D 12, it is actually portable to OpenGL, and provides generally superior results compared to other filters. Thanks!

Fermi users rejoice

Fire Emblem Unity

A new entry in the series, and, some core changes aside, a good one at that! The best part of this release is in the technical aspect. Gone is the clunky and slow Koei Tecmo engine. Fire Emblem Engage uses the much more flexible and optimized Unity engine instead.

For us emulation fans, this means 60 FPS is achievable on very low-end hardware, and the game can be reasonably played with the framerate unlocked too. Only some animations and 2D elements experience issues with the higher framerates, something we hope the modding community can solve. We expect to see 120 and even 240 FPS mods working fine on reasonably powerful hardware.

Another point, and maybe even more important, is shader stuttering. Koei’s engine is notoriously infamous for having bloated shaders that, without tons of work from our side, can make any GPU driver crash on timeouts. Unity, on the other hand, has much lighter shaders, allowing Vulkan’s parallel building to shine, and asynchronous shader building provides extra help, if your CPU doesn’t have enough threads to hide what little stutter remains.

Still, new game release, new issues, and new fixes for them. So let’s list what has been done so far.

byte[], who may or may not have just discovered the Fire Emblem series, noticed an issue with the shader compiler: the only place where multisampled (MSAA) textures were actually being intentionally processed in shaders was in the GLASM shader backend, albeit incorrectly. In the GLSL backend, it was completely ignored, and in the SPIR-V backend, it produced an invalid combination of arguments to a SPIR-V instruction, which caused Mesa to abort when processing our shader. Passing through multisample information fixed the crash, but left more work to do…

…which epicboy, one of the original authors of the shader compiler, took notice of, and came back with a rapid-fire series of fixes to address. His first fix was to continue what byte[] had started and fully implement multisampled texture fetches in the GLSL and GLASM backends, cleaning up rendering of the game with those backends.

From Stealth to Tactical RPG (Fire Emblem Engage)

He then implemented two more changes: preventing translations of the TXQ instruction from producing another invalid combination of arguments, and then implementing full support for multisampled images with the TXQ instruction, with only a few minor loose ends to tidy up – which will require another cache invalidation. We preemptively apologize to all Smash players (even though it hasn’t happened yet).

Now your favorite characters won't be half-way in the Shadow Realm (Fire Emblem Engage)

This fixed menu rendering in other games, such as Dokapon UP! and Pokémon Mystery Dungeon: Rescue Team DX.

Fight fire with fire (Pokémon Mystery Dungeon: Rescue Team DX)

As any NVIDIA Pokémon Brilliant Diamond/Shining Pearl player will tell you, Unity engine games are more stable on OpenGL, one of the rare cases where the old API is preferred. We’re working to fix this issue, but for now, if you are experiencing crashes when using Vulkan with an NVIDIA GPU, try using OpenGL instead, and as an alternative, see if disabling Accelerate ASTC texture decoding helps. As always, both options can be found in Emulation > Configure… > Graphics.

Turbo mode

If you followed previous progress reports, you may have noticed a certain pattern. Your writer has a stupid idea, and byte[] is the one that ends up listening to my rambling and makes that idea a reality. This routine worked successfully with SMAA for Vulkan, unsuccessfully with increasing the staging buffer size to take advantage of ReBAR, sadly, and this time, it almost worked with Turbo mode, or its official/boring name, Force maximum clocks.

You might be able to see where this is going. A year ago, Patreon funding got your writer access to an RX 6500 to help with testing and debugging. That card died a horrible, premature death (and no one misses it), but before kicking the bucket, it allowed us to learn that RDNA and RDNA2 hardware from AMD suffer from serious downclocking issues if you’re not constantly shoving work to the GPU. Thankfully, due to the cryptomining crash, an RX 6600 took its place for no extra cost. In your face, miners.

Ehem, back on topic. The card will try to idle as much as possible to save power, so if the workload is not constant, it switches to a lower clock speed, and raising the clocks again takes time. This results in lower performance. While the issue affects all GPU vendors in one way or another, only AMD suffers from up to 70% performance losses, with both Windows and Linux drivers. Yes, even RADV.

Since asking the users to apply external workarounds like encoding video in the background to keep VRAM usage high or overclocking the minimum clock speed are not easy to communicate, or can count as voiding your warranty, your writer was going insane trying to find ways to cleanly solve this issue, as it seems AMD isn’t very interested in it.

The solution came from an overclocking background again. memtestCL is a tool to test stability of video memory: you set a size, how many iterations to run, and the compute load will compare results, informing you of any errors. Running yuzu and memtestCL at the same time completely fixed the downclocking issues of AMD cards!

Some small discussions and prototyping later, and a solution was starting to take shape. Creating and running an OpenCL/CUDA process in parallel was deemed to be too much work, and could be sent to the background by the scheduler, nullifying any gain. Instead, we decided to use Vulkan’s own compute capabilities. A useless dummy load will constantly run on the GPU, forcing it to always keep its clocks as high as possible, and with it, the power consumption.

Four of the most GPU intensive games. Lower end cards like the infamous RX 6500 XT can see jumps as high as 70%

While this is a simple solution, it has a few drawbacks that forced us to sadly not enable this option by default:

First, not all users want to or can run their GPUs at maximum performance. On mobile devices, it results in terrible battery life, or hitting power limits on AMD and Intel APUs, like the Steam Deck for example, with its small 15W default TDP.

Second, low constant loads like an old game running at very high framerates, or an emulator performing dummy cycles, produce a noise known as coil whine, an electrical “purring” that varies in intensity with each GPU. Some are barely audible, others can scare their users, even if the card is under no harm.

And third, while this is a safe option for AMD dedicated GPUs, on NVIDIA and Intel, the results are much more variable. Weaker NVIDIA cards (anything weaker than an RTX 3060) will most likely lose considerable performance with Turbo mode, while the powerful, expensive cards will see performance gains similar to AMD. The RTX 4090 in particular performs better with Turbo than even NVIDIA’s own “Prefer maximum performance” setting in their control panel.

Left is default performance with an RTX 4090, middle is using the driver's 'Prefer maximum performance', right is yuzu's Turbo mode (Pokémon Scarlet)

Intel is, as always, a special case. While Turbo mode certainly helps desktop Arc GPUs, integrated Xe graphics and older can only run a single queue. This means that, by design, these iGPUs can’t render and run compute tasks at the same time. While the scheduler seems to do a fantastic job, not causing any performance loss with Turbo, you still get all the drawbacks and no benefit while using Intel iGPUs.

We have worked to resolve as many limitations as we could, but since the results are so variable between different vendors and cards, the option will remain disabled by default. We strongly recommend that everyone tests it. If it produces a performance gain in a game, it should be consistent across the board. At least all desktop AMD users, Big Chungus NVIDIA owners, and the 5 people with an Arc will benefit greatly from it. The option can be found in Emulation > Configure… > Graphics > Advanced > Force maximum clocks. …I still prefer calling it Turbo mode…

Let's reuse the same pic, no one will notice it

Yet more GPU changes

Starting off the new year with a bang, bylaws of Skyline fame returned with another round of fixes for our shader compiler project. Geometry shader passthrough is an NVIDIA hardware feature available on the Switch which is primarily used to select a viewport or layer without needing an actual geometry shader, and it is available to and used by yuzu with desktop NVIDIA cards. However, AMD, Intel, and other vendors don’t support this extension, and require emulation using geometry shaders. bylaws added support for geometry shader passthrough emulation, which fixed rendering issues in NieR:Automata The End of YoRHa Edition, Marvel Ultimate Alliance 3: The Black Order, Pokémon: Legends Arceus, and likely many other games.

Robot shoot is pretty funny (NieR:Automata The End of YoRHa Edition)

vonchenplus implemented the draw texture method, another NVIDIA-exclusive feature, with both native and emulated versions. It’s like the Switch used some sort of NVIDIA GPU, hmm.

Generally, graphics APIs like OpenGL and Vulkan require shaders and some geometry (at minimum, a triangle) defined to render a texture to the framebuffer, but the draw texture method bypasses this requirement and draws an axis-aligned texture to the screen with only the coordinates of the bounding rectangle. When using OpenGL on NVIDIA hardware, yuzu will try to use the host’s draw texture function, and it will be emulated with shaders on Vulkan or other platforms. This fixes the rendering of the title screen on Titan Quest.

And people ask why we 'make' games run faster on NVIDIA hardware (Titan Quest)

byte[] corrected a mistake in the way yuzu treated swap intervals. One method for limiting framerate on the Switch is to set a number controlling how many times a frame will be presented, where presentation happens 60 times per second. A program could limit itself to 30 frames per second by setting this number to 2, 20 frames per second by setting this value to 3, and so on. yuzu mistakenly treated the swap interval as being based on powers of two, so the values of 1 and 2, corresponding to 60 and 30 frames per second, worked correctly, but a value of 3 incorrectly presented at 15 frames per second. While fixing this mistake, byte[] also added support for mod developers to use negative values as multiples of 60 frames per second. Let the (high-framerate) games begin!

epicboy also fixed a longstanding issue with asynchronous shader building on OpenGL, forcing shaders to be fully flushed and available to the main rendering context before signalling availability. This should alleviate any persistent graphical errors exclusive to asynchronous shaders in the old API.

Blinkhawk returns with another significant performance improvement for the world’s seemingly-least optimized Pokémon games. This allows them to render in our much faster, but lower-accuracy, GPU Normal mode, and implements a few related optimizations along the way. Have fun shiny hunting!

If you ask why all pics are in the same area, it's one of the best benchmarking spots. Normal accuracy on the left, High accuracy on the right (Pokémon Scarlet)

Keep in mind that Normal GPU accuracy will produce vertex explosions for a frame, but only last just as long. Permanent vertex explosions be gone! High GPU accuracy will be cleaner, but slower, so pick your side.

As one final note for the GPU section, your writer implemented a feature which had been requested for quite a while since the resolution scaler was released, but nobody had really bothered to look at until now – additional resolution options.

Now you can select from the additional options of 1.5x scaling, or 7x and 8x (if you have a death wish for your graphics card). User reports confirm that the RTX 4090 can play some games at 8x, and the RX 6950 XT doesn’t have many problems with 7x. The odd one, 1.5x, was added because our metrics show that the most used non-iGPU cards are strong enough to have surplus performance at 1x, but are not powerful enough to handle 2x. A middle ground is ideal to get crisper graphics while keeping the 30/60FPS target, or if the user has a 1440p display. We think this should be reasonably future proof for now.

Warning, don't click this image on weak devices: 16K resolution (SUPER MARIO ODYSSEY)

Small warning, AMD and Intel hardware don’t support textures as big as NVIDIA, so it’s possible to hit this limit in some games and make the driver crash. If you have performance and VRAM to spare and you hit a crash, lower the multiplier.

macOS progress

Since we have been providing little snippets of a possible return for macOS support for the past few months, know that the progress is slow for now, but we have some significant results to report.

Baby Mario steps (SUPER MARIO ODYSSEY)

byte[] implemented a fallback for the absence of nullDescriptor support in MoltenVK, avoiding a crash when attempting to bind buffer slots on MoltenVK.

Then, he implemented a substantial refactor of how yuzu performs Vulkan feature testing, making it both more streamlined and able to cope with the absence of features which yuzu currently still requires as mandatory – such as the aforementioned nullDescriptor feature.

Finally, PCSX2 and Dolphin contributor TellowKrinkle helped us discover a bug in MoltenVK where the number of bindings it reports as available doesn’t correspond to the number we can actually use, and suggested a workaround, which byte[] committed, allowing trivial homebrew examples to finally begin rendering correctly. We are also able to render some simpler games, but be aware: most things don’t work yet. Baby steps!

It's hard to describe, has the performance, but lacks the features, but has modern features

General changes

byte[] triggered the scheduled mandatory Dynarmic update, blessing us with fastmem and page table support for ARM64 devices, boosting performance considerably. Anyone with an ARM64 device running a “normal” GPU (not mobile-tier hardware) interested in testing yuzu, feel free to install our official Flatpak.

german77 stumbled upon an issue which was causing input threads to randomly crash yuzu for seemingly no reason, but only on shutdown. byte[] found that CoreTiming had the same logic issue that he fixed last month in the kernel code when adding KHardwareTimer: callbacks could be removed while in-progress, which could cause the input threads to continue using memory after it had been freed. With this code changed to wait until any in-progress callbacks are finished before removal, this issue should be solved for good.

After the merge of german77’s impressive Joy-Con driver release last month, Morph noticed that yuzu was often taking a significantly longer amount of time to shutdown, sometimes more than 5 seconds longer than it should have been allowed to. He discovered that this was due to sleep calls in the Joy-Con driver to poll for new devices that weren’t being cancelled on shutdown, and with help from byte[], he implemented a proper fix so that they would immediately stop waiting when shutdown was signalled.

More battles won for the Shutdown Wars, with seemingly no end in sight! It’s starting to almost feel like a Worms game.

An interesting report from a user pointed byte[] to the visual novel うみねこのなく頃に咲～猫箱と夢想の交響曲～ (Umineko no Naku Koro ni Saku - Nekobako to Musou no Koukyoukyoku), which seemed to reliably crash in fast-forward mode, but only when audio was enabled. He quickly identified that the issue was happening at the same time the audio system was temporarily stalling the game (in order to avoid dropping any samples). He had previously implemented stalling in the kernel in a way that seemed superficially reasonable, but actually completely broke the scheduler when just the right conditions were met! byte[] then reimplemented stalling more carefully, avoiding breaking the conditions required by the scheduler, and preventing a deadlock due to incorrect behaviour around suspension.

Without love, it cannot be seen (Umineko no Naku Koro ni Saku - Nekobako to Musou no Koukyoukyoku)

Users reported a regression when trying to play Mario Kart 8 Deluxe over LAN mode. The game would refuse to access the mode and return to the main menu. german77 updated the implementation to match the latest reverse engineering efforts and poof, back to launching blue shells at all your friends!

Hot take, only Gran Turismo gets close to this series in music quality (Mario Kart 8 Deluxe)

MonsterDruide1 is back with the good fixes. This time? LDN. Game mods that add network connectivity sometimes use sockets with a timeout in order to keep the game responsive while waiting for more packets. yuzu used to hate this behaviour, spamming errors in the log, and generally just having a bad time. Changing this unnecessarily cautious behaviour allows network gameplay mods to work properly, for example, smo-practice.

SoRadGaming suddenly showed up one day and implemented IPv6 and hostname support for LDN. Thanks! Now more players can enjoy their online matches, and we’re ready for the eventual death of IPv4, which is expected to happen someday in this geological era. Or maybe the next one.

Remember when domain names were free?

Merry, taking a break from Dynarmic to play with some areas of yuzu, implemented a set of fixes to the audio codebase, focusing on upsampling. An off-by-one error fix should translate to in-game music not cutting off as much, and improved audio fidelity.

Input and TAS improvements

TAS got its fair share of improvements, all thanks to MonsterDruide1 and german77. The first fix is properly recording sanitized inputs, instead of the raw inputs from the player. By sanitized, we mean input adjusted by range and dead zone settings. There isn’t much use for a TAS script if what you record doesn’t correspond to what the game received originally.

Next, yuzu, by design, can support multiple controllers per player, which can lead to multiple stick inputs overlapping (“flapping”) each other. yuzu would ignore switching to any stick input that didn’t reach full tilt. To avoid this behaviour causing problems with TAS, MonsterDruide1 overrules this safety threshold value for TAS-based stick input, so every movement gets registered, even the most minuscule ones right from the start. This change also adds the extra logic of returning to regular input if the TAS stick reaches a value of 0 in both axes.

And to end the TAS changes, MonsterDruide1 also now shows the progress of multiple scripts when several controllers are running their own records, for example, TAS state: Running 35/100, 20, 0, 40. Now all players in local multiplayer matches can get their corresponding information.

On the topic of regular input, german77 has been busy improving it, and he has implemented a couple of changes that we think many will like.

For our keyboard and mouse fans, there’s now support for mapping the mouse wheel to any button. Sounds like a simple way to switch gear in The Legend of Zelda: Breath of the Wild to me, for example.

german77 has been gluing his eyes to some unit tests lately trying to find out why EARTH DEFENSE FORCE: WORLD BROTHERS would outright ignore input in some cases. After several back and forths between yuzu and the real Switch, he found out that the stick range didn’t seem to have minimum value of -32768, the usual value expected from a 16-bit signed integer (a range of -32768 to 32767), and instead seemed to have a minimum of -32766.

Unpatched Switch consoles are invaluable for us

Okay, Nintendo is as Nintendo does, have it your way, we will just fix the minimum stick range in our code. Problem solved, right?

No.

As it turns out, this is a game bug. You can get the Switch to reach -32767 under certain conditions, and EARTH DEFENSE FORCE: WORLD BROTHERS will also refuse to accept input on the real hardware. So what do we do then? german77 decided that the best solution is to apply a 0.99996x multiplier to the received input from the sticks, just to avoid weird games from behaving incorrectly.

People have been complaining about poor Joy-Con reception since, well, ever, and honestly, there’s a limit to how much we can do, only Nintendo knows what Bluetooth black magic they use to get good range on the Switch. Thankfully, the new custom Joy-Con driver allows us to have more freedom on the parameters of the Bluetooth connection, and german77 discovered that disabling low power mode, one of the available parameters, after establishing a connection is closer to what the console does, and should help improve range to some extent.

Our general recommendations still apply: if you’re using an Intel WiFI + BT combo chipset, turn off WiFi, and make sure to have your phone away from the BT chipset and the Joy-Cons. It’s known that off-brand generic USB dongles provide better range than WiFi + BT combo chips.

Now for players interested in bending the game engines to their limit, or just wanting to have some extra fun (us boomers like to call this “cheating”), german77 has a gift for you. Turbo button support! Also known as rapidfire, this allows you to, as the name implies, repeatedly auto-press a button as fast as the game can register it.

For some reason, Mega Man comes to mind

Enjoy finding new ways to break your games with this!

UI changes

This one has been cooking for over 2 years now, sheesh. Morph originally started working on improving high-DPI support in yuzu all the way back in November of 2020. Now it’s ready, and the results are great. Users that run displays at DPI values over 100% can now see proper UI element scaling, particularly noticeable in the Controls setting window.

4K display users rejoice

Nothing is safe from bugs in the user interface code, and Wollnashorn found an interesting one affecting LDN. The Direct Connect window asks the user for an IP and nickname.

We believe in recycling here, that includes pics

Those settings got lost every time a game was booted. Well, the issue was that those settings were being saved on the per-game configuration files for no reason. It doesn’t make sense to include a fundamentally global setting in the per-game settings, so removing them solved the issue.

byte[] solved an issue where accessing fullscreen would cause yuzu to crash. Adjusting the behaviour of yuzu’s bootmanager was enough to stop the CRASH!!

Newcomer SaiKai implements one of those Quality of Life changes that you can’t live without and you can’t believe it wasn’t a thing before. Pressing and holding the hotkey assigned to lowering or raising volume will now auto-repeat, making it much easier to control. Thanks!

Per-game configuration returns to mess with us, now with the language selection. The language ComboBox index gets altered in per-game configuration, so setting the region to Korea or Taiwan would result in a crash. german77 fixes this discrepancy and solves the issue.

Hardware section

Let’s revive this section for a bit, there’s some information I’d like to discuss.

NVIDIA, forgetting about their old cards.

We previously mentioned that the 527.XX release of drivers solved issues we previously had with Pascal and newer cards. While this was true for most issues, Pascal is still hitting some of the old problems, like crashes with ASTC texture decoding enabled. We recommend Pascal users to either disable ASTC texture decoding, or revert back to 512.95 drivers. We hope NVIDIA backports the fixes Turing and newer cards got to the old guard too.

AMD, custom drivers are not good

The recently released RX 7000 series, or RDNA3, are not particularly compatible with emulators right now, with yuzu not being an exception. Broken rendering and crashes were reported by early adopters.

Sadly, we can’t focus on these products while they run a custom driver branch. Until AMD merges the RDNA3 driver with the regular Polaris to RDNA2 one we’re all used to, it’s impossible to focus efforts on trying to solve any particular issues of this new release. Sorry early adopters, you will have to wait.

Having access to hardware that doesn’t cost NVIDIA-stupid levels would also help. AMD, please don’t take a year to release the mid and low end.

Now, regarding unofficial custom drivers, we received reports that Amermine Zone drivers break rendering in many games. Regular drivers are perfectly fine, so just stick to official AMD releases.

Intel, artificial limitations capping good hardware

Your writer recently had to replace an old i3-5005U laptop because its WiFi died, but HP only allows a very limited selection of cards as replacements, and said parts are no longer in production. I’m never buying HP ever again.

Sorry, back on topic. This was a great opportunity to get an Iris Xe GPU, so an i5-1240P was acquired. ASUS this time. As this was first hand experience for a tester with a Gen 12 Intel GPU, we now have both good and bad information to discuss.

Let’s start with the bad, and this is something that affects many users, as it is the default configuration of most laptops.

Intel, in their infinite wisdom, decided that single channel memory configurations should artificially limit the integrated GPU to the slower UHD Graphics spec, reducing its EU (execution unit) count. Basically, running the GPU with half its cylinders.

Unless the user pays the premium for a dual channel configuration, or has the option to manually add the extra SO-DIMM stick later, performance on Intel Xe devices, or “UHD Graphics”, is terrible. Most 3D games can’t run at playable framerates even at 0.5x handheld scaling.

To top it out, it’s very clear that Vulkan drivers are still a weak spot with Intel hardware. It’s a lottery with each game. They may perform correctly, similar to their AMD and NVIDIA counterparts, or may have glaring issues. Some shaders, for example, outright crash the driver. We will report these issues to Intel as we find them.

Sadly, the usual solution of just running Linux is not a fix this time. Mesa support for Gen 12 Intel graphics hardware (Xe, Arc, etc) is still in very early stages, and the performance is usually in the sub-10 FPS territory. We can’t wait to see Mesa once again show the Windows driver team how their job is done. Windows users, make sure to periodically update your drivers, as each release introduces major changes, so it’s critical to keep up. Intel is finally caring about their GPU division with the release of Arc. And finally, as a side note, Xe graphics are sensitive to the use of FSR. They lose a considerable amount of performance, so we strongly recommend using Scaleforce instead.

Now the good parts. Getting a proper dual channel configuration not only doubles the available bandwidth, which is the most critical point of iGPU performance, but also raises the EU count to the proper Iris Xe spec you originally paid for.

Benchmarking shows that under these conditions, Xe graphics manage to surpass Vega iGPUs in yuzu, as long as the Intel Vulkan drivers cooperate. It also shows that Xe graphics are more tolerant to SMAA than, for example, NVIDIA Pascal GPUs, being an almost free setting, performance wise. This, coupled with the better IPC of Intel CPUs, should provide an edge on budget laptops. At least, until AMD remembers that not everyone wants to pay a fortune for an RDNA2 integrated GPU and releases a refreshed low end lineup. I got tired of waiting.

As an extra juicy bonus, unlike Arc, the Intel iGPUs still have their amazing native ASTC texture decoder. This means no delays in ASTC heavy games like Luigi’s Mansion 3, Bayonetta 3, or Astral Chain. The almighty RTX 4090 can’t do that.

A small note regarding the ASTC support of Intel iGPUs. Not all texture formats used by Switch games are supported by Intel, some will still need to be specially decoded. Since these GPUs only have a single queue, Xe users should disable ASTC texture decoding from yuzu’s graphics settings. Most of the time the Xe GPU will be the bottleneck, and making it constantly switch between decoding textures and rendering the game will incur a performance loss. Letting the CPU carry this work will help graphical performance. Finally some good use for those E-Cores.

For those that don’t fear noise or heat, tweaking the sliders in XTU is an easy way to get an extra GHz out of their CPUs while plugged in. This can help double the performance in yuzu.

Unfortunately, Intel’s EoL status regarding Windows drivers is starting to affect compatibility with recent games, so we officially consider Gen 9/9.5/11 Intel GPUs to be out of support on yuzu. This covers Gen 6 to 11 CPUs, Skylake to Ice Lake. We will provide support and log issues for them only if they run on Linux. Or, well, macOS, once MoltenVK is fully working.

Future projects

I’m still under a sort of “NDA” with the developers, so I’m not allowed to tell you what’s cooking yet, or else.

Our spies still managed to pass along a bit of information before going dark, Project Lime, a co-development between bunnei, Tobi, german77, and byte[]. Stay tuned for its official announcement.

Project Gaia continues to progress slowly, growing closer to the internal beta testing phase. Some of its standalone features have already been tested:

This was a performance test to see how long it takes to load a game list

A bit of sad news for outdated hardware users: we have discussed plans to discontinue OpenGL. Fixes and improvements that are critical for Vulkan are becoming a chore to port to OpenGL, and, as you’ve seen with the progress on MoltenVK support, we have to worry about new devices that depend exclusively on Vulkan. It won’t be very soon, but it’s time to consider getting a GPU with Vulkan support, you know, something made within the last 11 years.

That’s all folks!

Thank you for reading to the end. And very special thanks to Mysterious Writer B, without their help, this article would have been seriously delayed.

Out of the night, when the full moon is bright, comes a horseman known as B…

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report December 2022

Honghoa — Tue, 10 Jan 2023 12:00:00 -0300

Hello yuz-ers. What a year! We ended 2022 with more yuzu Fried Chicken, Vulkan changes, a new input driver, an exorbitant amount of kernel work, more performance, better visuals, and much more!

Project Y.F.C. part… 1.5, and a cache invalidation

Blinkhawk has also been working hard on his beloved project, releasing Y.F.C. Part 1.5. Basically an abridged version of what is expected for the full “Part 2” release. The changes in this pull request include a rework of the MacroHLE implementation to include various new macros for indirect draws and configurations.

As discussed in previous articles, macros are small GPU programs that implement features like indirect and instanced draws. They must be emulated. MacroHLE (High-Level Emulation) is the process of avoiding executing a requested macro and instead translating it directly to the code that it would have generated (like an instanced or indirect draw). This works in contrast and in parallel with MacroJIT, which works by actually emulating the loops and control flow contained in macro programs in a just-in-time fashion.

Now, why keep both? Well, each one performs their own specialized task. MacroHLE’s advantage compared to MacroJIT has to do with the emulation of indirect calls. An indirect call, such as a draw, uses data generated somewhere in the GPU through some shader in order to establish the draw parameters and its draw count. Traditionally with MacroJIT we had to sync the Host GPU and Guest GPU to obtain the indirect data in order to execute the macro correctly. With MacroHLE, we create an indirect draw command in the host GPU that points to the translated address of where the GPU generated data should be. Thus skipping the syncing.

Thanks to these improvements, yuzu now is able to more efficiently execute macros, considerably reducing CPU overhead, and without having to change any setting. What we internally like to call a “passive skill”.

As a result of these changes, performance has been improved in several titles, including those developed by Koei Tecmo, Pokémon Scarlet and Violet, Bayonetta 3, and Monster Hunter Rise (with the exception of version 12.0.0, which still requires further fixes) to name a few. The crashes in Fire Emblem: Warriors have also been fixed. We measured a 5-20% performance boost in select titles, but the improvement may be higher on CPUs with a lot of cache. From our testing, the 5800X3D can reach over 30% in some games. The performance cost of rendering at higher resolutions was also greatly reduced.

R5 5600X - 2x16GB 3933MHz CL18 - RX 6600

But the goodies don’t end here! Blinkhawk also added support for the VK_EXT_extended_dynamic_state2 and VK_EXT_extended_dynamic_state3 Vulkan extensions, reducing the amount and size of shaders needed to be built during gameplay.

This relatively “new” pair, along with the already implemented VK_EXT_extended_dynamic_state and VK_EXT_vertex_input_dynamic_state, are the four extensions responsible for considerably reducing shader building stuttering. But as it always goes, support for these extensions in consumer GPUs is spotty at best, and a mess to support at worst. State3 in particular is only supported by the NVIDIA Vulkan Beta drivers, version 527.86 at the time of writing, and recent (late 2021 and newer) RADV Mesa drivers. We recommend anyone interested in testing how a fresh shader cache performs to give these drivers a go.

With no alternative, implementing these extensions forced us to perform another dreaded cache invalidation.

Proof that the best GPUs for yuzu continue to be NVIDIA for either OS, or AMD on Linux

Most drivers cover at least 3 of the 4 extensions without issue, one way or another, with one glaring exception, AMD Windows drivers. The price of this is higher stuttering during gameplay when new shaders are being processed compared to running the same card on Linux with RADV, or using any other brand.

A small side-note, Linux RADV users should update their Mesa version to the latest (or use a more recent distro version if needed), as support for state2 was broken in versions before 21.2.

As a last second change, Blinkhawk tested removing the 16-bit floating point (FP16) blacklist enforced on NVIDIA Ampere and newer GPUs (RTX 3000 series and higher). If it worked, it would have allowed them to work similarly to Turing and AMD Radeon offerings in this aspect. However, NVIDIA redesigned how their FP32 and FP16 units operate on Ampere and newer, with both providing identical performance. Unfortunately, even if it were faster, it’d be irrelevant in the end, as FP16 on Ampere and Ada is still bugged in the drivers, producing graphical issues in many games.

The only remaining architecture that could benefit from enabling blacklisted FP16 support is Intel on Windows, but their drivers are a dumpster fire regarding FP16. So they continue to emulate 16-bit precision with 32-bit the same way as Ampere and Ada, in this case with its always present performance loss. Of course the weakest architecture that could benefit the most from this change is the only one that remains broken…

Another extra benefit of this iteration of Y.F.C. is that Normal GPU accuracy is much safer to use. Particles will continue to be better in High, but games like Pokémon Scarlet/Violet, Bayonetta 3, and many others can be played with Normal accuracy without glitches much more regularly with the big performance benefit this provides (Bayonetta 3 in particular still needs High for its title screen, but gameplay is safe on Normal).

Other awesome GPU changes, and yet more cache invalidations

The month doesn’t stop there, there has been a plethora of changes worth mentioning too in our GPU codebase.

Oh boy, byte[] sure has been busy this month.

To start off, he is responsible for implementing the SMAA anti-aliasing filter for our Vulkan and OpenGL backends. But that’s not the whole story, so let’s elaborate further.

SMAA, or enhanced subpixel morphological antialiasing, is an improvement over MLAA developed by the Spanish Universidad de Zaragoza and video game studio Crytek, of Crysis fame.

BreadFish implemented the original OpenGL version, intending to release it as part of the resolution scaler. As it turns out, implementing SMAA for Vulkan is no joke, and after being nagged by your writer, byte[] had to work 2 weeks to get it in shape.

SMAA, being based on MLAA, intends to be a post-processing (aka shader-based) option focused on quality over performance by analyzing adjacent pixels, unlike FXAA which just blurs the entire screen. The SMAA filter is implemented using render passes and it produces its best results when combined with FSR filtering. AMD recommends properly anti-aliasing the image in their official Overview Integration Guide. The results speak for themselves:

Here you can see an ideal test case for SMAA, the simple triangle of death

Ropes and power lines, the classic example for anti-aliasing testing (Pokémon Scarlet)

Sprite elements in 3D games benefit from it (Xenoblade Chronicles 3)

For those interested, we used the ULTRA preset, testing showed a low performance loss even with a GT 1030, so we preferred to focus on quality. Only users with old integrated GPUs should avoid SMAA. For the rest, it’s a safe option to turn on and forget. You can find the feature in Emulation > Configure > Graphics > Anti-Aliasing Method.

SMAA doesn’t suffer from the horrible colour banding of FXAA (The Legend of Zelda: Breath of the Wild)

And it's a great help for users running low resolution multipliers. This example is 0.5x Bilinear alone Vs 0.5x FSR + SMAA (Pokémon Scarlet)

A close-up to finish (Xenoblade Chronicles 3)

As a side note, NVIDIA’s version of FSR, NIS, was also tested, but the result is so ugly and over-sharpened, that we decided to keep the best option of the two, FSR.

byte[] has also fixed a problem with anisotropic filtering. If users ran the RADV driver on Linux, anisotropic filtering values other than Default would cause a distinct “acne-like” rendering issue in Super Mario Odyssey. The issue persists at other anisotropic filtering and resolution multiplier values., but byte[] continues to work on the issue.

The so called RADV acne (Super Mario Odyssey)

The change also addresses an issue with the buggy water rendering in Super Mario Sunshine with automatic anisotropic filtering on Lavapipe (Mesa, Linux), although the error still occurs at other anisotropic filtering values.

Kind of makes it look even older (Super Mario Sunshine)

byte[] also corrected the semantics of data cache management operations in the memory.

Previously, when the guest requested a cache invalidation, the implementation would simply invalidate the cache on the hardware, rather than making the memory visible to the GPU as intended.

On the side, he also promoted various Vulkan Extensions to use core methods. In the Vulkan API, vendor extensions are optional features provided by specific hardware vendors or drivers that may not be available on all systems. In contrast, core methods are a fundamental part of the Vulkan specification and are guaranteed to be available on all systems that support the API. Thus, promoting extensions to use core methods can improve their reliability and portability.

byte[] made further initialization tweaks to the Vulkan API. These changes included the restoration of VK_KHR_timeline_semaphore and VK_EXT_host_query_reset, which were mistakenly removed in a previous PR. He also added the flag VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR to the VkInstanceCreateInfo structure for MoltenVK to allow MoltenVK to be detected as an available Vulkan device.

Keep in mind that a lot more work is needed in order to get yuzu rendering on macOS devices. This is only early preliminary work.

vonchenplus has implemented the draw manager for Maxwell3D with the aim of eliminating workarounds and reorganising the drawing process to more accurately enumerate the drawing behaviour. As a result of these changes, the issue in Dragon Quest Builders where some 3D models were not rendering properly has been fixed.

No more missing stuff! (Dragon Quest Builders)

No armour is best armour (DARK SOULS)

Following these changes, vonchenplus also improved the code for the topology update logic so that the implementation is more accurate. This change was necessary in order to implement special topologies with Vulkan.

This includes support for quad strips, which require the use of triangles to simulate them, and the ability to simulate indexed and non-indexed modes. In non-indexed mode, a fixed mapping table is used to connect the vertices, while in indexed mode, a compute shader is used to dynamically map the original drawing indices. vonchenplus has also implemented support for line loops, which require the use of triangle lists to simulate them, and for polygons, which require the use of triangle fans.

These changes fixed the Hero’s path in Legend of Zelda: Breath of the Wild, as well as the Status Summary graphic in Pokémon Scarlet and Violet, and they also gave us another shader cache invalidation, yay!

Don’t mess with the stats! Can’t do breeding without the stats! (Pokémon Scarlet)

When the Sheika GPS signal returns (The Legend of Zelda: Breath of the Wild)

Blinkhawk has added alpha to coverage and alpha to one to our Vulkan backend.

Alpha to coverage is a multisampling technique that is used to improve the quality of transparent or partially transparent pixels. It works by blending the alpha values of multiple samples taken from the same pixel to produce a single, more accurate result. This can help to reduce aliasing and other rendering artifacts that can occur when rendering transparent pixels.

Alpha to one, on the other hand, is a technique that is used to improve the quality of partially transparent pixels by setting the alpha value of each pixel to a maximum of 1.0. This can help to reduce the amount of alpha blending that needs to be performed, which can improve the performance of the rendering pipeline.

These changes have fixed the shading of trees and grass problems when viewed up close or from a distance in Pokémon Scarlet and Violet.

The camera isn’t more interested in that tree, you should learn from this, Dark Souls (Pokémon Scarlet)

vonchenplus has corrected errors caused by yuzu’s faulty detection of draw types. In the past, yuzu would set every vertex and index count register to zero after each draw to determine if the next draw would be a regular or indexed draw. Xenoblade Chronicles 3 proves to us that these registers initiate some draw calls based on previous values. Changing this behaviour partially fixes the particles present in Xenoblade Chronicles 3. You can now more easily perform your off-seer duties.

Your browser doesn't support mp4 video. :(

Meat is on the menu! (Xenoblade Chronicles 3)

CPU requirement changes, with free performance

We don’t usually cover compilation changes here, but this time we had to do it because it affects compatibility.

Your writer (or co-writer in this progress report, my partner did most of the work this time) has been playing with compilation flags in order to get more free performance, following previous work done by Blinkhawk some time ago.

Microsoft Visual C++ (MSVC, Visual Studio) is simple enough (we’ll talk about Linux later). You enable full program optimizations, optimize for performance instead of size, a bit here, a bit there, and you gain a nice 3%, but I wanted more. Last month, epicboy improved the build process, saving both time and memory. This created a “gap” big enough to enable the Big One, Link-Time Optimizations (LTO), an optimization that in the past had to be discarded for eating all the available RAM of our buildbots.

Windows testing went well and in some cases the performance uplift reached up to 12%. The problem was Linux. LTO is aggressive by nature, and there’s no guarantee that all parts of the project will react nicely to it. In this case, the problem was Qt, the UI looked completely garbled. So LTO had to go, but in its place, we now require what Dynarmic already did for a while, x86-64-v2 hardware.

GCC and Clang builds will now compile assuming the features of CPUs are compatible with the instruction sets that form part of x86-64-v2, the highest one being SSE4.2. This means the minimum CPU required for yuzu to work without crashing, in both Windows and Linux, is now the first generation of Core i-series (500-900 series), which are almost 15 years old, and the FX and APU series from AMD, which are almost 12 years old. The performance boost on GCC and Clang is up to 7%.

First system runs i7-12700H - 2x16GB 4800MHz CL40 - RTX 3080 Mobile 16GB 175W, second system runs R7 5800X3D - 2x16GB 3600MHz CL16 - RTX 4090

We originally wanted to enforce x86-64-v3 to get an even bigger performance boost, as well as to ensure a minimum level of performance, as any CPU lacking AVX, AVX2, and in particular, FMA, will be very slow, no matter its clock speed or core count.

Yes, that means the 8 core Ivy Bridge Xeon you bought for 20 bucks is not fast enough for this task.

The problem, however, is that doing so would leave close to 9% of the user base out of support, according to our telemetry. That many users is a considerable number, so we’ve decided to wait until more users adopt more modern CPUs before implementing this change. We’ll re-evaluate enforcing x86-64-v3 in the future once OpenGL eventually ends up on the chopping block as well.

While this change would also apply for Windows, MSVC is not flexible enough to let us build for x86-64-v2, it either supports SSE2, or jumps straight to the first AVX. Dynarmic already manually uses x86-64-v2 extensions, so any CPU lacking SSE4.2 is considered unstable regardless of the OS in use.

x86-64-v4 will not be an option for many years, mainly because Intel can’t decide if AVX-512, made by themselves, is something that their users should be allowed to actually use.

If an old-school user is so strongly set on running yuzu on decades old CPUs, the Flatpak builds are still generic, or there’s always the option of building yuzu manually, allowing you to configure any requirements.

New Joy-Con driver and other input improvements

german77 has done it again, giving us an amazing Christmas gift, a new input driver for Joy-Cons This is an in-house development that doesn’t rely on SDL, so it gives us much more freedom to add features that weren’t previously available.

The basics are covered. Single and Dual Joy-Con modes are available, button, stick, motion mapping works the same as before. But that’s not exciting, here’s all the new stuff that was added:

When launching yuzu, the controller player LEDs will show a blinking pattern to signal that the emulator has taken control. Once you’re in game, the LEDs will reflect the player number.
HD Rumble is fully implemented now, complete parity to pairing natively.
The emulator can now automatically select between automatic and custom calibration profiles, avoiding stick drift (as much as the Joy-Con can physically do, we can’t fix Nintendo’s problems) and providing much more accurate motion.
Colour reading is added, now the actual colour of the controller is reflected in the UI and in games, just like on Switch.
Amiibos can now be loaded with the Joy-Con just like you do on the Switch.
The Ring Controller is now fully supported, no need for external programs.
Preliminary support for the IR camera is done, games like Night Vision, Game Builder Garage, and Nintendo Labo can make use of this neat feature at the base of the right Joy-Con.

All this extra accuracy highlights a problem we didn’t often face before: PC Bluetooth connections are very easy to saturate. Cheaper/Intel bluetooth chipsets or areas with tons of interference are especially prone to this. For this reason, HD Rumble can potentially cause lag depending on the user’s specific circumstances. We recommend unmapping/disabling rumble in those cases.

Speaking of saturation, the IR camera may be slow in some games. The reason being that we currently implement only the image transfer mode, which saves 320x240 pictures. Some games prefer faster framerates at the cost of resolution, going as low as 40x30. Once all modes are added in, the choppy framerate will disappear.

Amiibo data writing is a work in progress.

german77’s desire for incredible input improvements doesn’t end there.

german77 implemented the mifare service, allowing games read and write plain mifare tags. Games like Skylanders Imaginators make use of this feature. The only feature lacking is support for encrypted read and writes.

Tagging! (Skylanders Imaginators)

Speaking of SDL, a recent update broke the way it handled the GUID, the identifier of several controllers, including the one integrated into the Steam Deck, causing many annoyances for Deck users. So, with no alternative on hand, german77 had to implement a custom filter to solve the issue.

And lastly, as a very important quality of life change, german77 made the input device list refresh automatically, ensuring that yuzu detects controllers without the need for manual intervention. Goodbye tiny refresh button!

To close the section, MonsterDruide1 increased the accuracy of analog sticks for TAS by hardcoding the range and deadzones of the user input.

Kernel, building, and core changes

With an update for Dynarmic and SDL2, byte[] enabled support for ARM64 compilation. This means all Switch titles can be tested on Linux ARM64 devices with compatible Vulkan drivers.

As part of this effort, we started implementing Flatpak support for ARM64 Linux devices. This required making OpenGL optional for the build process, as Flatpak’s Qt build only supports OpenGL ES, not the full fledged OpenGL 4.6 compatibility profile we require.

Part of these changes fixed compilation for macOS, but the situation remains the same, without MoltenVK support, nothing will be rendered.

epicboy implemented a series of changes with the goal of minimizing the overhead of dynamic memory allocation, a task which involves requesting memory from the operating system, and can slow-down performance in some circumstances.

The texture cache, in particular, was a significant contributor to this issue, as it constantly allocated and then deallocated memory when transferring textures to and from the GPU. To address this problem, epicboy optimized the texture cache to pre-allocate a buffer to store swizzle data and reuse it whenever possible, rather than performing a dynamic memory allocation every time this was done. This change should result in reduced stuttering, as memory will now only be requested from the operating system if the buffer is not large enough to hold the data.

epicboy also made similar changes to optimise the ReadBuffer function , which likewise takes a similar approach: instead of allocating and deallocating memory, a buffer is created once to hold data in the memory, and it only reallocates whenever it needs to grow.

Additionally, he introduced a ScratchBuffer class to act as a wrapper around a heap-allocated buffer of memory.

The advantage of this class lies with the fact that it eliminates the need to initialize the stored values, and the need to copy the data when the buffer needs to grow. Thus, it would help to speed up things by minimizing the amount of time spent on memory management tasks.

german77 implemented the FreeThreadCount info type, which is needed by titles such as Just Dance 2023 Edition (although that game requires additional changes in order to work).

Saalvage noticed an error in yuzu’s kernel implementation and made the necessary changes to unlock thread mutex before destruction, as not doing so incurs an undefined behaviour. “Here be Dragons” and all that.

byte[] submitted a change that improves the handling of system startup failure, in order to prevent deadlocks and crashes when/if the GPU initialization fails.

He also added KHardwareTimer. This component is designed to fix an issue with incorrect event unregistration when threads request a timeout for certain operations.

Without the fix, the threads would return successfully from the operation but fail to cancel the timeout, which would cause the timer to mistakenly fire on the thread and cancel a random unrelated operation.

This change fixes the random hangs that have been plaguing us for months in The Legend of Zelda: Breath of the Wild, as well as Persona 5 Royal.

The soundtrack that steals your heart (Persona 5 Royal)

byte[] also introduced a workaround for crashes caused due to unallocated memory after noticing that yuzu always used memory blocks without marking them as allocated, causing it to overlap memory used by the game. He fixed the bug by making sure we now allocate the memory before using it. This is meant to alleviate the situation while other parts of the kernel are being ironed out.

This is more related to error handling, but counts nonetheless. byte[] added an option to force the emulator to break when an invalid memory access happens. This means that if/when a game explodes in the background, the emulator will crash instead of slowly eating all the available system RAM. Problems like these can be caused by emulation issues, damaged game dumps, or even some wonky mods, so it’s always a better option to avoid crashing the entire emulator, and if the user has little enough RAM, making the OS suffer.

Along with endless silent changes that don’t get mentioned here, lioncash made some changes to the input code to reduce memory use ever so slightly.

User interface and audio changes

We’ve had some interesting user interface quality of life changes implemented! lioncash made the SPIR-V shader backend element translatable, so it doesn’t always show in English for everyone. The community effort working on translation can now take the label and update it accordingly.

We still don’t recommend using it over GLSL, but Mesa users report they enjoy it

Some months ago, with the core timing changes, we allowed users to boot games with their framerate unlocked after continuous requests from the community. As it turns out, nothing changed. Several games hate booting with unlocked framerates, and the support channels get their fair share of people asking why their game doesn’t want to boot. So, simple fix, unlocked framerate at boot rights denied. The hotkey to toggle unlocked framerate is Ctrl + U by default, only a small nuisance.

Users reported that they couldn’t record or stream their yuzu window while in windowed mode. byte[] found the cause was setting the WA_DontCreateNativeAncestors Qt property for all platforms, instead of just for wayland. Issue down, streamers rejoice.

Discord user piplup reported that yuzu didn’t save the device name (what you would call the console) after accessing a game’s custom configuration window. german77 fixed the issue (this particular setting lacked a custom configuration equivalent), and also fixed Qt 6 build issues while at it.

Another very nice quality of life improvement made by german77 is making yuzu remember the last selected directory for Install files to NAND…. If you keep your dumps in the same folder, updating your games is going to take fewer clicks now.

byte[] managed an amazing victory in the war against crashes when closing/stopping games. He worked on making shutdown not visibly freeze yuzu, avoiding crashing the emulator while the game quits, and showing a nice pop-up message while at it too!

We take longer than the Switch, but some games really love to take their time on console

Morph helped make this possible by hiding button dialog boxes, allowing for the creation of the dialog overlay byte[] added.

Another battle fought on this front is related to homebrew apps. byte[] is responsible for making them quit properly now too.

ChrisOboe suddenly shows up with a glorious quality of life fix for the terminal-based yuzu-cmd build. Marking the build as a “Windows” application instead of a “Console” one ensures that no empty command line window pops up needlessly. This can help streaming programs set up to run specific games with yuzu-cmd, as this prevents the sudden empty black box from appearing in front of other windows.

For our single audio change of this month, Maide properly signals a buffer event on audio stops, fixing an early softlock that affected the Pokémon Brilliant Diamond/Shining Pearl games.

Future projects

We’re only a few days into 2023 and we already want to publish the next progress report. So much has happened in such a short time!

Also, Blinkhaw, bunnei, and byte[] are up to something, and we can’t wait to tell you more. And yes, there will be yet more cache invalidations. All in the name of progress.

That’s all folks! Expect a few but very critical Vulkan improvements next time, hope to see you then!

⭐⭐⭐ Grande Messi

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report November 2022

GoldenX86 — Sat, 10 Dec 2022 12:00:00 -0300

As a dear friend likes to say, meowdy yuwu-zers! This month is special: a report detailing the uphill battle for the release of new titles in the goliath franchise that is Pokémon, adventures on new architecture lands, and a list of fixes and improvements that were made along the way. Fasten your seat-belts, here we go!

PSA for NVIDIA users (almost a flawless victory)

Before we move on to what everyone wants to hear about (just a new Pokémon game, nothing special 😉), we have very exciting news to announce! NVIDIA driver version 527.37 finally solves all known driver related regressions on Pascal and newer hardware! And to make it better, it affects all cards actively supported by NVIDIA. From the GT 1010 to the RTX 4090, there are no more driver related graphical issues (it’s only our fault for now… until NVIDIA strikes again), exactly how the cards used to perform with driver version 472.12 all the way back in September 2021.

Sadly, Maxwell users (900 series and older) will have to remain on version 512.95 to avoid frequent device loss errors when using Vulkan, but for those with GPUs newer than 8 years, there’s no longer a need to stick to old driver versions. Feel free to update to the latest release!

Here are links for the desktop and laptop GPUs respectively.

Guess who’s back

It’s finally here. ~~For better or worse.~~

Adopting some of the new gameplay elements introduced with Pokémon Legends: Arceus, Pokémon Scarlet/Violet has been unleashed upon the world! This time with ultra-realistic tree textures, and NPCs walking at 5 FPS.

Fun new gameplay aside, this release has been quite the challenge for yuzu. It doesn’t help that the game has problems running natively on the Switch to begin with. Low performance, storage related stuttering, and memory leaks being some of them. However, while exposing several issues in yuzu, their corresponding fixes have helped other games in unexpected ways!

When the game first released, it didn’t render anything in yuzu at all, which is not good. Something needed to be done. vonchenplus was the first to answer, and identified that this was due the game’s use of gl_Layer, and added support for it in the shader compiler. You will hear more about this gl_Layer “character” later.

One thing is for sure, the graphics have definitely improved (Pokémon Scarlet)

With this change, the game starts to render and the team can focus on finding, documenting, and fixing any other bugs that show up.

A limitation was quickly found by the community, gl_Layer depends on having driver support for the GL_ARB_shader_viewport_layer_array extension in OpenGL, or the Vulkan equivalent, VK_EXT_shader_viewport_index_layer.

While most GPU drivers do indeed support these extensions, the NVIDIA drivers don’t for Maxwell V1 and older cards. This means users trying to run Pokémon Scarlet/Violet on GPUs older than the 900 series wouldn’t get the game to display anything on screen, in either graphics API and any shader backend. Must be part of the promised package that included Vulkan support for Fermi, pure smoke.

The way byte[] solved this limitation is by translating the gl_Layer assignments with geometry shaders, basically a brute-forced hardware accelerated way to replicate the missing extensions on older hardware. This results in proper rendering for the decade-old Geforce Fermi, Kepler, and Maxwell V1 series GPUs, in either OpenGL and Vulkan. Now an extra 6% of users can play the game.

The test subject, anyone can cook

Old but gold! (Pokémon Scarlet)

Let’s switch for a second to CPU related issues. There were reports that certain moves like Tail Whip could cause the opposing Pokémon to outright vanish, or that changing directions very quickly could cause a soft-lock. Even simple map traversal could cause crashes.

What do you do when all issues seem totally unrelated and random? You blame the CPU precision, of course!

More, ahem, precisely, in what optimizations are enabled by default. The offending option turned out to be Inaccurate NaN handling, an optimization made to improve the performance of some rooms in Luigi’s Mansion 3. Blinkhawk updated the Auto setting for CPU accuracy to skip this optimization.

For anyone wishing to restore the performance for Luigi’s Mansion 3, we recommend using the per-game settings feature. Right click the game, go to Properties, CPU tab, set CPU accuracy to Unsafe, and make sure Inaccurate NaN handling is enabled, as shown in the example below:

The per-game settings window is a pathway to knowledge many consider... Unnatural

We strongly recommend using a global setting of Auto CPU accuracy, and only implement custom/unsafe settings on a per game basis, never globally. Games WILL break with unsafe settings.

Now going back to GPU related issues, AMD has its own share of problems, as it always does. Users were quick to point out that the game looked as though the director of Breaking Bad produced it, seemingly rendering like a yellow/orange filter was applied. This issue is for the history books, as both the official AMD drivers (the Windows driver, amdvlk, and AMDGPU-PRO) and mesa (RADV) share the same behaviour.

Let’s provide some context. The default shader backend of Vulkan, SPIR-V, describes the special properties variable decorations have. Usually, a fragment shader’s input variables are set as smooth, interpolating the values between each vertex. But sometimes you end up with a value that is constant across all vertices in a triangle. There’s no need to waste computational power smoothing anything in a case like this, so you can set the variable as flat instead. Both the official AMD and RADV drivers think that the previously mentioned gl_Layer input in the fragment shader needs to be decorated as flat, or they treat it as a constant zero across the triangle, instead of the value set in the vertex shader. Jury is out on this, we reported the issue to AMD.

A normal Vulkan program would never find itself in this situation because the GLSL compiler always decorates gl_Layer as flat. The NVIDIA driver doesn’t make this assumption and doesn’t treat gl_Layer as a constant zero, regardless of the presence of the decoration.

Wasn't this game based in Spain? (Pokémon Scarlet)

By adding the missing flat decoration, byte[] allows Radeon users to view the proper beautiful blue skies, in both Windows and Linux.

Ping-ponging back to CPU bugs: Even with all the work so far, Pokémon Scarlet/Violet could periodically crash. This gave us a sense of dread we haven’t felt since the release of Pokémon Sword/Shield. Thankfully, our fear was unfounded, as only Windows users reported this issue. Linux users, for example Steam Deck users, didn’t crash at all. This gave us the needed hook to reel the line of the cause, which ended up being a problem in dynarmic, a stack misalignment in one of the memory accessors. A quick call to Merry over the red phone, and the crashing is no more.

Back to the GPU, and this one was really annoying. Your writer had to do an all-nighter running tests with bunnei to figure it out.

NPCs and characters could encounter vertex explosions at random, and while using High GPU accuracy would mitigate the problem to a certain extent, it was still very common in cities, particularly in the academy. To make it even uglier, those vertex explosions were permanent at specific camera angles.

After a few dozen rounds of regression testing, the root cause was found in one of the changes introduced by Project Y.F.C., so Blinkhawk took over and implemented the proper changes, fixing some buffer cache and engine upload issues.

It's like our personal curse, seems to happen with every release (Pokémon Scarlet & Violet)

While the NPC vertex explosions are fixed, some geometry pop-up issues remain. Homework for later. Now any vertex related glitch only lasts one frame and should go away once the relevant shader gets cached. Also, as a bonus, Pokémon Legends: Arceus can now be played at Normal GPU accuracy without encountering vertex explosions, making good on our promise to fix it! This can greatly increase performance on the older Pokémon title. One more thing to scratch off the list. That buffer cache rewrite is still needed though.

CPU’s turn again, or rather memory in this case. byte[] fixed a silly mistake in the cheat engine that caused it to crash when using speedhack cheats.

Quick, back to the GPU! Or more precisely, a change to the user defaults.

As you may know from previous reports, Vulkan has a tendency to break when the user installs outdated screen recorders, overlays, or bloatware that messes with the Vulkan layers. This leads people to still use the OpenGL API, which is not only considerably slower for Pokémon Scarlet/Violet (over three times slower in some cases), but also run the GLASM shader backend, an NVIDIA exclusive feature which is not particularly good with recent game releases, Scarlet/Violet not being an exception.

yuzu used to default to GLASM so NVIDIA users could enjoy lower shader compilation related stuttering, as OpenGL’s default shader backend, GLSL, is irritatingly slow in this aspect. The problem with this approach is that the GLASM backend (assembly shaders) was developed as an experiment, and its two primary maintainers have moved on from the project, with one literally “turning green with envy.” No one on the team is taking the time to maintain a backend that has decades old and difficult-to-parse documentation, no debug tools, only partially helps a single GPU vendor, and has its advantages negated by a superior alternative, Vulkan.

Lavender Town? (Pokémon Violet)

Assembly shaders were a useful alternative while Vulkan was in early development, but now it’s just dead weight taking precious development time that could be used to improve Vulkan instead.

This problem is far more common than your writer would like, so for those NVIDIA users with the special superpower to always break Vulkan, OpenGL will default to GLSL now. The option to use GLASM will remain available, as Fermi users love it due to their chronic lack of Vulkan support.

To finish the changes implemented this month regarding this flawed best-seller, bunnei fixed an assert spam in the audio suspend process. This change not only cleans up logs, it has the potential to improve performance to a degree.

That’s all for this November’s list of Pokémon fixes and improvements. More work is in development, as there is still stuff to fix, so while we wait let’s end this section with some recommendations we found to get the best experience while playing:

NVIDIA, Intel, and AMD users must run the latest driver versions.
High GPU accuracy ensures proper rendering of vegetation and buildings. Missing graphics? Switch to High.
Handheld mode improves performance considerably over Docked.
Gym trials may require switching to Handheld mode for stability, this could be a game issue as it is known to have memory leaks on console. Later game updates seem to solve this.
4 core/8 thread users seem to improve performance by a good margin by disabling SMT/HT.
Installing the latest game update improves performance and stability over long gameplay sessions.

Graphical fixes

Back to the usual agenda, games in general.

vonchenplus found an issue in how yuzu handles tessellation shaders which causes black backgrounds in The Legend of Heroes: Trails from Zero.

Why would you want to use tessellation shaders for 2D content in an RPG?

A tessellated 2D background, in all its glory (The Legend of Heroes: Trails from Zero)

Immediately after implementing the change, we noticed that games didn’t render correctly, and it wasn’t the fix’s fault. In cases like this, a cache invalidation is not only recommended, but needed. gidoly updated the cache version number, invalidating all previous caches, and causing a large disturbance in the Net, as if thousands of Smash players suddenly cried out in terror and were suddenly silenced.

One of the important changes that didn’t make it in time for the first part of Project Y.F.C., Blinkhawk’s series of GPU related changes and fixes, is improving the handling of ASTC texture mipmap uploads.

The original implementation rendered the ASTC mipmaps directly. What actually happens on the Switch is that the NVIDIA driver uploads to its 2D engine first. The incorrect implementation caused severe texture corruption in many cases, most commonly in games running Unreal Engine 4.

Fluffy (Yoshi's Crafted World)

The list is long, so here’s a selection of games that were improved with this change:

Blue Fire
A Hat in Time
The Witcher 3: Wild Hunt Complete Edition
Darksiders III
Diablo II Resurrected (character hair)
DRAGON QUEST XI S: Echoes of an Elusive Age – Definitive Edition
Life is Strange: True Colors
Yoshi's Crafted World
F.I.S.T.: Forged In Shadow Torch
Digimon Story Cyber Sleuth: Complete Edition
Grand Theft Auto: The Trilogy – The Definitive Edition

Working on improving OpenGL stability, vonchenplus reimplemented the inline index buffer binding, making the OpenGL implementation match the Vulkan one. This solves certain cases where OpenGL would crash when using non-unified memory mode.

Here’s an interesting one. If a game had bad performance on a specific system and produced too low of framerates at boot, it could hang due to a lost wakeup. Since the “secret project” byte[] was working on was a platform slower than a normal gaming PC (more on this in the next section), byte[] blasted this limitation to the Dark World, allowing everyone to be able to boot their game dumps.

A problem we reported a couple of times already, and AMD confirmed to be working on, was crashes happening in Xenoblade Chronicles 3 with Vulkan, thanks to improving the precision of our MacroJIT code. Since it became clear that more time was needed to solve this issue on the driver side, byte[] managed to implement a workaround, an HLE multi-layer clear mechanism which bypasses this driver-level limitation. This way, the game remains playable in Vulkan for AMD on Windows.

Always has great title screen music (Xenoblade Chronicles 3)

Here’s an interesting find from one of our old testers. If you run The Legend of Zelda: Breath of the Wild in its base 1.0.0 version, recent changes caused distant trees to have a black flicker. This behaviour was not present in an updated game, but a glitch is a glitch, and it deserves attention.

Your browser doesn't support mp4 video. :(

The old result (left) has been reduced to 10 FPS to avoid triggering sensitive readers (The Legend of Zelda: Breath of the Wild)

vonchenplus found out that the order of the drawing commands was wrong in this case, and implemented a more conservative drawing trigger mechanism. No other game is known to be affected by this change, but if there is, it’s fixed!

Your writer has been trying to slowly learn the ropes and decided to take on some small projects. Too bad he’s also an idiot…

The result of too many hours of suffering is the addition of a sharpening slider for the FSR filter. Also known by its long name, AMD FidelityFX Super Resolution 1.0.2. However, it prefers being called FSR between friends.

Emulation > Configure > Graphics

This allows the user to pick how much they want to sharpen a specific game. Personal preference applies here, for example, The Legend of Zelda: Breath of the Wild may look great at 100% sharpening, but that same value may be too much for Pokémon Scarlet.

Seems to help with distant objects (The Legend of Zelda: Breath of the Wild)

Test it to your preference and use the per-game profiles to make the most out of it. Thank you toastUnlimited for helping me with the per-game support.

Right-click > Properties > Graphics

Our own Poyo enjoyer, Morph, with help from byte[], worked on improving the usage bits Vulkan demands of the device’s supported formats, while at it also adding a new format to the list, R16_SINT. One of the “improved” games from this change is Xenoblade Chronicles: Definitive Edition. While the game complained about missing a texture format, graphics don’t seem to have changed.

CPU, kernel, and debugger changes

Let’s address the elephant in the room, which byte[] has been feeding tons of peanuts lately. yuzu now supports being built and run on ARM64 devices!

Of course, hardware requirements remain the same: at least 8GB of RAM and an OpenGL 4.6 compatibility profile/Vulkan 1.2 plus specific extensions GPU driver is required. This means that yuzu can run on, for example, Asahi Linux on an M1 Apple MacBook Air, but by using Lavapipe, Mesa’s CPU rendering Vulkan driver, which of course results in very slow performance.

This is what's possible right now (Mario Kart 8 Deluxe & Super Mario Galaxy)

This initial implementation adds support for 32-bit games only. As for 64-bit games (the most common), an update needs to be merged to Dynarmic. Once it’s out, there will be no restrictions on which games can be executed.

This is what will be possible in the near future (Super Mario 3D World + Bowser's Fury, Super Mario 3D All-Stars, & Super Mario Odyssey)

Further improvements by byte[] includes corrections on atomic store ordering to improve stability, implement data cache management operations, and the most fun one, fix compilation for Apple Clang, allowing yuzu to run directly on macOS!

If only Apple wasn't a reptilian company and offered Vulkan support

We have a very long road ahead to fully support macOS, but a journey of a thousand miles begins with a single step, says the old man.

Outside of venturing into new architecture seas, byte[] also contributed a few general changes too.

Switch games can be weird. For example, MONSTER HUNTER RISE has some fundamental love for opening services. After a recent refactor, our kernel emulation incorrectly used a process per session, and this could lead to running out of slab heap, resulting in a hard crash. As a workaround while byte[] refactors services to have a process tree accurate to the Switch, the extraneous processes have been removed, keeping stability in check.

The fight for proper kernel emulation rages on, and bunnei raises the bar by implementing most of the Switch’s firmware 15.X.X features. This brings memory management improvements (must resist making a boomerang joke), which should result in improved stability and slightly better resource usage. While no game seems to specifically improve with this change, future games targeting the latest firmware versions will certainly benefit. Nothing better than avoiding future headaches!

Services, input, and audio changes

On the last day of the month, when we cut the list of pull requests that will make it into this article, Morph contacts your writer asking for one last addition. And it was one important addition. Morph improved the stubs for the Submit, GetRequestState, and GetResult service functions, allowing Splatoon 3 to boot while a network connection was configured for LAN/LDN play.

While now you can join rooms, the game is not stable yet (Splatoon 3)

A lot more work is required to make this game fully playable, but fixing boot related issues is always a great start.

jbeich is back in action, ensuring that yuzu is compatible with BSD systems! This change adds support for previous additions and fixes that were only considering Linux at the time. A separate pull request deals with making BSD compatible with the changes required to run the LDN services.

As part of byte[]’s efforts to get yuzu running on macOS, he and toastUnlimited had to make some changes to fit the platform’s special needs. First, byte[] assigned the menuRole property for actions to improve Cocoa support, and then toastUnlimited changed the Vulkan check on other platforms to behave closer to how the check for Windows works, improving the compatibility with the macOS file manager. german77 joins the fun, making changes to ensure reading SDL events doesn’t crash on macOS.

Regarding input in general, german77 went to infinity and beyond with yuzu’s multitouch detection, raising the 16-finger limit to, well, infinite! As part of this change, he also tuned the response speed of touches, which were a little bit too fast, resulting in missing input. As a result Mini Motorways is far more playable now!

C'mon, touch it! (Mini Motorways)

Amiibos also got some love from german77. The first example is implementing the NFC IUser service, which fixes the NFC detection in Ultra Kaiju Monster Rancher.

And it's still a premium feature on most phones (Ultra Kaiju Monster Rancher)

Next, german77 implemented the cabinet applet (Amiibo manager window). This new settings window allows the user to register, format, and delete game data from their Amiibos, while also displaying any additional data available. This first implementation will only show up when a game requests it, a manual UI option will be added in the future.

Images optional for now (Shovel Knight)

On the audio side of things, Maide has been working on solving out-of-bounds crashing issues related to how the emulator and the Switch handle audio buffers. Here’s the thing, the game decides how many buffers it wants to use, and has the freedom to use the buffers as it pleases. As Maide says: “Put voice A in buffer 1 with voice B in buffer 2, mix them together into buffer 3. Put voice C in buffer 4 and mix buffer 3 and 4 into buffer 5, etc.” At the end of the line, if you need to output to 2 channels, only two final buffers will be used, for 6 channels, 6 buffers, but there is no order to those selected buffers, no rule says that they must be buffer 0 and 1. yuzu operated under the assumption that games would use buffers 0 to 5 for output, and that has been the case for the majority of games, but as always, there are exceptions, one being The Legend of Zelda: Skyward Sword HD. This particular game uses something similar to 8/9/12/13/10/11 for its 6 buffer outputs, or in proper hexadecimal values, 8/9/C/D/A/B.

The previous implementation took the first buffer as a starting point, buffer 0, and added +1 to fill the remaining 5 slots. That’s definitely not valid for Skyward Sword, the moment you want to access a buffer that is not part of those 6 first consecutive buffers, you get a crash for getting out-of-bounds, and this happens even with the first actual output buffer, at 8! Fixing this behaviour by checking the highest buffer and adding +1 stops the game from crashing, and should also have the benefit of not outputting weird sounds, as the correct buffers will be selected.

As most of you know, our current file system emulation is far from ideal. Morph’s Project Gaia should address most issues we have with it once his rewrite is finished. In the meantime, there’s nothing against fixing existing problems with it, and v1993 provides a huge hand by addressing a case that could be invisible to the user, and really annoying as a result. The emulator can auto-generate some of the keys required to decrypt and run Switch games. The problem is that those auto-generated keys are sometimes worse than those the user provided during the dumping process, yet they still took precedence. v1993 flips this behaviour, solving cases of games refusing to boot due to this conflict.

User interface improvements

Localization is an ongoing effort, and anyone can contribute here. This time the community added support for another language, Ukrainian! This addition is possible thanks to the work done by Docteh and GillianMC. Keep at it guys, we’re all with you.

Docteh also fixed the translation of pop-up warnings that show up when trying to remove game content.

Como corresponde

No one wants to lose their saves, especially not if it’s the user’s own fault. As per the request of one such user, toastUnlimited added a warning pop-up when a user attempts to delete a user profile. Because, yes, deleting a profile includes deleting its saves.

The UI must also protect the users from themselves

epicboy surprised everyone by slamming the front door open, throwing per-game input profile support in our faces, and leaving, refusing to elaborate further. A real Chad.

Right-click game > Properties > Input Profiles

This feature uses previously created input profiles, make sure to create some in Emulation > Configure... > Controls beforehand.

Future projects

There’s a lot going on behind closed doors, but it’s too early to start teasing you. We can confirm that both Project Gaia and Project Y.F.C. Part 2 are progressing healthily, but those are not the only important changes in the oven.

Personally, I’m helping implement SMAA, but what started as just a rebase of BreadFish’s OpenGL implementation ended up being more than a week of extra work dealing with the Vulkan implementation, taking precious time from the already busy schedule byte[] has. Sorry! But the result was worth it. We’ll talk about it next month, as it didn’t make the cut for this report’s timeframe.

That’s all folks! Thank you so much for giving us a bit of your time, and we hope to see you next time!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report October 2022

GoldenX86 — Sun, 06 Nov 2022 12:00:00 -0300

Greetings, dear yuz-ers! What a month we’ve had. A dozen graphical fixes, big kernel changes, audio, input and amiibo fixes, and more! Don’t touch that dial, because we’re just getting started!

Graphics and general bug fixes

Let’s start with the meaty part. New month, new games to fix!

Persona 5 Royal, one of two blockbuster releases this month, launched with some mysteriously black battle scenes in Vulkan. vonchenplus identified this as missing support for special OpenGL-style clear commands which are not supported by the Vulkan specification, and added a workaround to skip clearing in this case. More work remains to be done to properly implement these clears in Vulkan, but this allows the game to be playable.

Joker, no stealing the screen! (Persona 5 Royal)

Longtime graphics contributor Blinkhawk has returned from the dead to fix games. The other major release of this month, Bayonetta 3, came out, and to users’ dismay, it did not work in yuzu. After defeating the services issue causing it to freeze, Blinkhawk investigated and fixed a rendering issue causing it to appear white in Vulkan.

Is this Paradiso? (Bayonetta 3)

A new challenger approaches! Or rather, a new showing from some older games, Super Mario Sunshine and Super Mario Galaxy. While rendering bugs were fixed in Vulkan, and OpenGL with the GLSL backend, they are now fixed with the NVIDIA-exclusive GLASM backend, as byte[] finally acquired some NVIDIA hardware for testing and development.

Best. Music. Ever! (Super Mario Galaxy)

An NVIDIA card is not the only new hardware acquired by byte[] this month. He also acquired an Intel Arc A770 16GB, and used it to track down a driver issue. Despite passing all of our validation tests, the Vulkan driver is unable to compile the ASTC decoder used by yuzu, and yuzu unconditionally compiles it at startup. Therefore, byte[] has skipped compiling it if CPU decoding for ASTC is used instead, and filed a report to Intel for their reference. This allows yuzu to boot games in Vulkan when using the Intel Arc Windows Vulkan drivers.

Blue Player joins the fray! (Super Mario 3D World + Bowser's Fury)

byte[] also found and investigated two issues with the macro JIT this month. The macro JIT is an optimization which recompiles small programs that are uploaded to the GPU to control drawing into native machine code. The first issue he resolved allowed homebrew applications using the deko3d rendering API to finally become visible with the macro JIT enabled.

Better than NVN, it's free!

The second issue was causing MONSTER HUNTER RISE to fail to render most scene elements. yuzu has had a workaround in Mainline for over a year! However, this papered over this issue, which is why it took so long to get fixed. byte[] fixed this issue as well, and now all is working as intended – there are no more known issues with the macro JIT!

Someone put a world in my ocean (MONSTER HUNTER RISE)

Unfortunately, fixing the accuracy issues in the macro JIT has caused Xenoblade Chronicles 3 to crash at boot with official AMD Vulkan drivers used on Windows and opt-in on Linux (amdvlk). This issue previously manifested with the macro JIT disabled, and occurs due to a crash that happens when submitting a clear command. We have reported this as a driver issue to AMD, and they have confirmed they’re looking into the issue. While we wait for the fix, using OpenGL while running the game on 2x scaling can be a workaround.

Speaking of MONSTER HUNTER RISE, Blinkhawk contributed another fix for the rendering in this game, implementing the ASTC 10x5 format. Grainy textures begone!

ASTC acne, begone! (MONSTER HUNTER RISE)

byte[] found that while he was debugging graphical issues, yuzu would frequently crash after the merge of Project Y.F.C. He narrowed it down to some code that was improperly ported from our friends at the Skyline emulator and implemented a fix, finally allowing him to debug without worrying about the game’s rendering speed causing any issues. Now, a user’s PC performance won’t be a cause for crashes.

Maide and Morph were on top of two regressions from the merge of the 3D registers pull request from a few months ago. Morph found that the merge was causing many shaders to be recompiled unintentionally, and narrowed it down to a different default value for the tessellation parameters in the register definitions.

Meanwhile, Maide and byte[] worked together to find a strange rendering problem affecting Luigi's Mansion 3, and finally found the issue in the values of the stencil mask registers.

Luigi saw how much an RTX 4090 costs (Luigi's Mansion 3)

vonchenplus found an issue with how a compute shader for TRIANGLE STRATEGY was being compiled by yuzu’s own shader recompiler project, and implemented a fix by deleting a broken optimization pass, returning blocky rendering to normal.

Project Rectangle, I mean, TRIANGLE STRATEGY

Still on a roll, vonchenplus also implemented 1D texture copies. Normally, the guest driver (the GPU driver included with each game) has to provide what kind of texture type is in use in memory, but thanks to the previously mentioned open documentation NVIDIA provides, we now know that there is a way to set the correct kind when the memory is initialized. The end result is much improved rendering in Snack World: The Dungeon Crawl - Gold.

Almost looks like a 3D TV without glasses (Snack World: The Dungeon Crawl - Gold)

With Blinkhawk back, the team can finally start nagging him to fix his changes, more specifically, Project Y.F.C. Part 1. After addressing some semaphores and cache flush regressions, Blinkhawk fixed the remaining glitches affecting the ink logic in Splatoon 2 and the models flickering in the ATM in Animal Crossing: New Horizons.

Long vacations

byte[]’s kernel and services work this month has been focused on getting homebrew running, but this also fixed some graphical issues. The first major accomplishment was getting homebrew to run consistently in the first place. byte[] noticed that launching homebrew in yuzu would often cause the entire emulator to lock up in almost 50% of attempts - but only when using Vulkan. After enabling validation layers, and some careful investigation of the messages, he found and fixed a subtle race condition in Vulkan queue submission, finally enabling homebrew apps to work reliably with Vulkan.

You could say that unit tests are at the heart of emulation development

vonchenplus has also been on the ball with homebrew support this month, gifting yuzu corrected support for instanced draws and the zany inline index 3D registers, fixing gpu_console and allowing the Sonic 1 (2013) homebrew game to render in yuzu. The usual slate of regressions associated with these types of changes, this time affecting Super Mario 64, Super Mario Galaxy, Xenoblade Chronicles 3, and Animal Crossing: New Horizons, have also been identified and fixed.

gpu_console, one of the examples available

Your browser doesn't support mp4 video. :(

Yes Doctor, all the nostalgia directly to my bloodstream (Sonic 1 2013)

Finally, byte[] implemented a fix for the intense, seizure-inducing flickering produced when launching homebrew from the homebrew menu when Vulkan is enabled, which was caused by not recreating the images intended for presentation. Now, you can launch console homebrew from the homebrew menu, just like on the Switch!

Emulating hacked consoles is so hot right now

Switching topics to a minor (but quite annoying) issue, we have a quality of life improvement from byte[]. In the past, writing screenshots taken in yuzu to disk would noticeably block rendering the game. The user would perceive this as a relatively short freeze (the length of this freeze varies according to the size of the resolution multiplier used). byte[] made this fully asynchronous, allowing for smooth gameplay even during particularly intensive photo shoots.

CPU, Kernel, services, and core fixes

A fix for CoreTiming accuracy from a few months ago, as part of Pull Request #8650, was added to intentionally waste CPU cycles until a certain amount of time had passed, due to extremely poor support in Windows for high precision timing events. But in Linux, this fix isn’t needed, as Linux natively supports high-precision delays. byte[] modified the behavior, allowing Linux users to take advantage of this and lower the high CPU usage. Remember when we say that yuzu is faster on Linux? This is a great example of what we mean.

No Man's Sky was released and our tester, Law, found that it could boot with auto-stubbing enabled. byte[] investigated the log file and stubbed the previously unimplemented calls, CheckFriendListAvailability and GetCacheStorageSize, allowing No Man's Sky to boot.

Still the best screensaver

Bayonetta 3’s release caused some issues that were tricky to track down. Your resident bunnei rabbit properly implemented ListOpenContextStoredUsers, and the related StoreOpenContext which is used to set stored opened user profiles. ListOpenContextStoredUsers was causing Bayonetta 3 to crash on startup. Fixing the stubs allowed the game to finally boot, and while it is now playable, it is quite slow still. Stay tuned for performance optimizations that will benefit this game!

german77 took part in the fun, stubbing the SetRecordVolumeMuted service, allowing the game to boot.

Hot protagonists in your area (Bayonetta 3)

Another notable release from bunnei this month was the start of the multiprocess project. Since the very beginning, yuzu has only ever supported a single-process architecture, as games only ever use one process on the Switch. However, to help improve yuzu’s accuracy for Switch software, yuzu has been focusing on getting key operating system features working, and one of the most important is multiprocess support, since this corresponds to how Switch software actually works.

byte[] and bunnei have been hard at work getting certain prerequisites available for multiprocess support. One of those is support for server sessions, needed for the nx-hbloader homebrew. This is used on the Switch to launch homebrew, and is needed for homebrew that do not work when launched directly from their NRO file.

Additionally, byte[] needed to fix several services, as the previous stub implementations had assumed that they would never be torn down. With these changes, and the associated graphical fixes, nx-hbloader and nx-hbmenu now finally work as intended! To use them, you can extract hbl.nsp and hbmenu.nro from your Atmosphere installation. Place hbmenu.nro in yuzu’s SD card directory, and then launch hbl.nsp, and the homebrew menu will boot.

Your browser doesn't support mp4 video. :(

They launch now (Homebrew menu and Sonic 1 2013)

Let’s talk about amiibos. Amiibo data is stored both encrypted and as plain data. To access the encrypted portion, a key dump is required, but not all games use the encrypted portion and are just fine with the plaintext available. For those cases, german77 now marks amiibos as read-only if no key dumps are available. This won’t replace dumping your amiibo keys if a game needs it, but many games will be fine with just a basic level of read-only detection.

Thank you Gidoly and german77 for the pics!

Input improvements

yuzu performs vibration tests every time a game initializes a controller for vibration, but the problem (there’s always a problem) is that some controllers take longer than others to respond. Previously, a fixed 15ms delay was implemented, because some controllers simply needed that much time to respond. If the game performs successive vibration tests, the game is delayed until the controller responds, which results in a reduced framerate, for example, from 60 to 32 FPS. All that performance being lost waiting on a bad quality controller is a tragedy.

So, a better middle ground is needed. Thankfully, german77 came up with a much smarter solution. Instead of repeating the test each time, it’s better to cache it the first time and return that same result afterwards. A nice, free, performance boost for those of us who use generic controllers.

Newcomer ZwipZwapZapony (love the name) fixed a copy-paste oopsie in how left and right controller colours are identified. Thank you!

Audio changes

Have you ever noticed how in motherboard BIOS/UEFI settings, the Auto option seems to do nothing, and instead simply reflects the first option available in the list? Well, we cheated exactly like that for years. The Auto audio backend option only selected cubeb every time by default. The shame. Maide found out that some audio devices incur a huge latency when using cubeb, so he decided to perform a latency test and select either cubeb or SDL based on the results.

toastUnlimited then addressed a regression caused by this change, avoiding a crash.

New Switch firmware versions usually come with their fair share of new services and additions, so in an effort to avoid potential problems in future games, Maide implemented some new parameters that Nintendo added to their audio core with firmware 15.0.0.

User interface improvements

Some users prefer displays closer to the golden ratio, the glorious 16:10 aspect ratio. While Switch games are not intended to be played outside the standard 16:9 aspect ratio, some users are fine with stretching the image to fill their whole display, even if it means some slight distortion. This has been increasingly popular with the release of the Steam Deck, which uses a 16:10 display, sporting a 1280x800 resolution. There’s also the option of the community coming up with different aspect ratio mods for each game, allowing for proper use of those nice extra pixels. german77 took the time to add this new option to the aspect ratio list, which you can find in Emulation > Configure… > Graphics > Aspect Ratio.

I'm personally not a fan of stretching, long live the black bars

Docteh, Morph, and lioncash (who diverted some time from the usual, making sure all PRs submitted to yuzu are sane) had their fair share of fixing spelling mistakes. Happens to the best of us.

In an effort to help reduce user confusion while we rework our compatibility reports, Docteh added a new option to hide the compatibility rating column from the game list by default. Anyone interested in reverting it back can find it in Emulation > Configure… > General > UI > Show Compatibility List. Keep in mind, reports will not be accurate while we work to implement the new report system.

We're working to solve all those Not Tested reports

Not everyone prefers to have their games listed in English in the game list, many would rather have them in their native language, or at least another option from the official languages the Switch supports. vonchenplus worked to solve this, and now yuzu prioritizes displaying the games in the user selected language.

Even if working online forces you to constantly use English, reading in your native language is always the best

Hardware section

This section will be short this month as most things are in progress!

AMD, WIP

As we said previously, we got confirmation from AMD that they are looking into the cause for the crashes at boot now affecting Xenoblade Chronicles 3, along with other previously reported fixes.

Future drivers will be fun to test.

NVIDIA, one step closer

We’re making some slow progress in the matter of stability problems affecting Maxwell and Pascal cards. It’s too early to promise anything, so we’ll keep you updated. In the meantime, if you MUST run the latest drivers, use OpenGL.

Hopefully the next mid-range cards won’t be the same cost as an entire PC.

Intel Arc, let’s go!

With games now working on Vulkan thanks to byte[], we only need proud owners of Team Blue cards reporting issues on our GitHub. Message to Intel: there are sales outside of Europe, China, and the USA. Please start shipping already so your writer can start testing…

This goes for you too, GabeN.

Future projects

With all the regressions caused by the first part of Project Y.F.C., Blinkhawk has started providing internal testers with the first test builds of some of the changes Part 2 will include. As with any first try, there are of course regressions, but some long-standing issues are already fixed in these builds, so expect more news in future articles.

Not forgetting our file system rewrite, Project Gaia, Morph implemented support for the incoming save data path structure. Work on Gaia continues, some roadblocks were hit, slowing progress down, but Morph pushes on.

Special thanks to Mysterious Writer B for their big help while your writer is half dead dealing with classes.

He's Vengeance. He's the Night

That’s all folks! Thank you for your time and see you next month!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report September 2022

GoldenX86 — Tue, 18 Oct 2022 12:00:00 -0300

Hello yuz-ers! We have so much to talk about this month. From game fixes, input changes, and quality of life improvements, to new gameplay options available to everyone!

Project London: open-source, online Local Wireless emulation

As promised in the previous progress report, and explained in its dedicated article, LDN support is here and available to all users! Enjoy pwning some noobs in your favourite games. But before we explain the how, let’s cover some theory.

Available multiplayer methods on the Nintendo Switch

The Nintendo Switch offers 4 methods for multiplayer gameplay:

Good, old, couch local multiplayer. While this normally only refers to people in the same physical room, the community has been enjoying the benefits of remote access streaming, with services like Parsec, to play online with the lowest possible latency.
Local Area Network (LAN) multiplayer. This is when multiple Switches connect to the same local network. This option has been emulated and available in yuzu for quite a while now. It’s limited to very few games, and it doesn’t have good tolerance for lag.
LDN multiplayer, more commonly known as Local Wireless, the star of this section. This is when one Switch hosts a session over the built-in Switch WiFi hardware while others connect to it as guests. The trick here is that nothing stops emulators from using a server infrastructure to host rooms so users from anywhere in the world, including locally, can join and smash each other. This method is far more supported by games than LAN.
Nintendo Online. This is the paid Nintendo service to play online, which also includes other bonuses such as official emulators to play older titles. We have no plans to offer support for Nintendo Online in the near or far future.

Project London includes full support for LDN, with room hosting and joining, and revamps our LAN support to use the new LDN code in place.

Now, let’s get to the fun part: how to use it!

A user can launch the Public Room Browser by selecting the Multiplayer option in the Menu Bar and then selecting Browse Public Game Lobby, or by clicking the status bar tip in the bottom right labeled Not Connected. Click here to find a room!

The new Multiplayer submenu

From there, double-clicking a room will allow the user to join it. Keep in mind, the Preferred Game is just a suggestion and there is no hard restriction on which games can be played in a room. Please keep this in mind when joining public lobbies and be courteous to your fellow yuz-ers! Any rooms that are user-hosted may enforce this by kicking players or locking their room.

A lock means it's a password protected room

Speaking of user-hosted rooms, the Create Room option in the Multiplayer menu allows users to host their own rooms, with custom player limits and optional password security. Some ports need to be forwarded in the host’s router/modem configuration, so please follow our guide here.

Feel free to host any game you want!

Once a player joins a room, they can chat with other members, see the game they are running, and very importantly, the game versions other players are using. Most games tend to only work when all players run the same game update version, so remember to dump the latest from your Switch!

It’s not mandatory to join a room before starting a game in yuzu, but it is recommended. At the moment, only LAN supports connecting with real Switches. LDN is yuzu to yuzu only, but we’re working to include native Switch support for LDN sometime in the future.

So far, very few games have issues with LDN. Only Super Mario Maker 2, Mario Golf: Super Rush and DRAGON BALL FighterZ have been reported as incompatible. Any other local wireless compatible game should work fine, but don’t be shy to report any issues should you discover them.

One bit of info, Super Smash Bros. Ultimate has a hardcoded 6 frames of delay when playing over LDN. This is supposedly to “help buffer” the latency expected from online and WiFi gameplay. While the ideal solution is to play in local multiplayer with Parsec (no forced delay on local play), not everyone has good upload speeds to host, or is comfortable with giving remote access to their computer.

An alternative is available: run the game at 120 FPS, reducing the delay to only 3 frames instead. For this, all users in the room must do two things:

Install the 120 FPS mod available here. Right click the game in yuzu’s game list and select Open Mod Data Location, then place the folder of the compressed file in the location that yuzu opens.
Set game speed to 200%. This can be set on a per game basis with custom configurations. Right click the game in yuzu’s list like before and select Properties > General tab > set the Limit Speed Percent to a blue enabled value (this means it’s a custom value, ignoring the default one) > change it to 200%.

Reducing input lag by running things faster, life hacks

Some GPU power is required to sustain 120 FPS, as such, our minimum hardware recommendations may not cut it (an RX 550 falls under 100 FPS in 1v1 fights), but modern low/mid-end hardware should be fine. Testing also shows that AMD Windows drivers can only reach framerates higher than 60 if the display supports it. We reported the issue to AMD, hopefully in the future this doesn’t force users to get high refresh rate monitors.

And that’s it! Join rooms, both in yuzu and in game, and fight! Or trade those Pokémon, your call. This endeavour was possible thanks to the ldn_mitm project who provided us a licence exemption, and the work done by Tobi and german77, along with the testers (your writer included) who never had so much fun crashing games in the name of progress.

After the Mainline release, Linux users reported that LDN rooms refused to work on some Linux distributions. The issue is in how the SSL package is distributed. toastUnlimited, taking reference from a previous pull request from Docteh, fixed the issue so now all supported operating systems can enjoy LDN.

Some users reported crashes when playing Pokémon Sword/Shield. While we implement the correction for it, make sure that a valid network device is selected in Emulation > Configure… > System > Network > Network Interface. The crash seems to happen when None is set as the network interface.

Graphic changes

NVIDIA OpenGL users may have seen some strange graphical glitches in games like Dragon Quest Builders, SNACK WORLD: THE DUNGEON CRAWL, and Pixel Game Maker Series Werewolf Princess Kaguya due to an oversight in yuzu’s handling of the performance-enhancing vertex_buffer_unified_memory extension. vonchenplus swooped in with a fix, and these games now render as they should.

Dragon Quest Builders

SNACK WORLD: THE DUNGEON CRAWL

Pixel Game Maker Series Werewolf Princess Kaguya

Users may have noticed an intriguing square moon in Live a Live. This is caused by the texture cache not correctly synchronizing ASTC textures that the game is using to all layers, so vonchenplus added a workaround to avoid filling the extra invalid layers with an error colour, which changes the moon back to the round shape we all love.

Not exactly a Red Moon, dood! (Live a Live)

Some systems, like Steam, don’t like yuzu’s behaviour of spawning a new process to check for working Vulkan support. toastUnlimited updated the Vulkan checker with a configuration option to, well, stop checking, allowing those systems to function the same as with older yuzu builds.

After three months of regression solving and the usual nasty delays, Project Y.F.C. Part 1 is finally merged to Mainline! You can find more information about it, as well as what’s expected in the near future for Part 2 here.

One regression remains, for now. It affects certain puzzles in the single player mode of Splatoon 2. While Part 2 is in development, users affected by this problem should stick to Mainline version 1190.

We mentioned last month about trying to push more aggressive Staging Buffer values in order to benefit GPU users that can enable Resizable BAR/Smart Access Memory (or ReBAR/SAM). While the option did get merged briefly with Mainline 1189, users quickly reported both big performance gains and losses, with no correlation to which GPU/CPUs were in use. This change seems to be very platform specific, and the average tilts towards performance losses, so byte reverted it.

It’s been a while since Morph dabbled in graphics work. .hack//G.U. Last Recode was unable to boot due to excessive vsync event calls. Limiting the event to only once per display allows this .hack to finally boot and play.

.hack//G.U. Last Recode

Audio changes

The cleanup for Xenoblade Chronicles 3 from last month continues this month with a new audio pull request from Maide. This fixed the audio desynchronization issue that some users were having during cutscenes. Previously, Maide’s audio implementation sometimes had issues with the game audio producing samples too quickly for the host audio backend (SDL or Cubeb) to be able to play in time. Now, if the game starts producing too many samples, it will be temporarily paused until the audio backend catches up.

Maide also implemented a relatively large cleanup of the audio system and how it relates to pausing and shutdown. Before Pull Request 8842, the audio system had its own timer system for dealing with the backend that ran independently of yuzu’s timer system, CoreTiming. Now that the synchronization issues when doing this were fixed, Maide removed the custom timer system to now run everything through CoreTiming, which correctly handles pausing and shutdown. The scaffolding for the audio system to be aware of pausing and shutdown was therefore no longer needed, and could be deleted.

Xenoblade Chronicles 3

These audio changes did, however, come with a minor regression. In multi-core mode, timer callbacks are run on their own thread, which allows them to execute independently of the CPU cores. However, because yuzu tries to be deterministic in single-core mode, every timing callback and every emulated processor instruction in this mode is run from a single host thread. In single-core mode, this prevents the timer callbacks from being effectively paused, which causes the audio service to try to continuously pause the game to catch up. Maide worked around this issue by simply not pausing if single-core mode is enabled.

For once, Maide was not the only contributor to work on audio! vonchenplus noticed that the new HwOpus service, which is a service for optimized playback of Opus audio, didn’t implement any of the multi-stream functionality needed for Dragon Quest X to boot. He added one new function that the game needed, GetWorkBufferSizeForMultiStreamEx, and the game booted.

Dragon Quest X

Core emulation

yuzu is slowly but surely improving its ability to run homebrew applications. So when the team discovered that the Ship of Harkinian homebrew (a PC port of The Legend of Zelda: Ocarina of Time) did not work correctly in yuzu, we were intrigued and tracked it down to a single missing service implementation. german77 added support for the pl:s service, which is used for loading fonts, and the game now boots and renders, with frame interpolation up to 60 fps working correctly.

Your browser doesn't support mp4 video. :(

Pure nostalgia, right click and enable audio (Ocarina of Time, Ship of Harkinian)

In the realm of our “other architecture” news, liushuyu modified yuzu’s CMake setup to be partly compatible with the ARM64 architecture. This allows building the yuzu-room LDN server application for ARM64. Pi server, anyone?

Stay tuned for future news regarding yuzu on ARM64…

Input Changes

One of the longstanding issues with yuzu’s input emulation was motion controls not working after the controller reconnects. Thanks to german77, this has now been fixed. This was happening because yuzu was only checking for motion controls when the controller first connected, but not on subsequent reconnections. Ensuring that yuzu checked for motion controls on every reconnection resolved this issue.

Over the years, yuzu’s input emulation had been missing support for emulating the popular Pokéball Plus controller. In his efforts to reverse engineer this, german77 found that most meaningful features for it were locked behind Nintendo Switch Online (NSO). Although this made him lose interest in it, he partially implemented support for emulating this controller (including motion controls), thus opening it up for others to improve upon. For now, you can select this in Pokémon Let's Go, Pikachu/Eevee! and use it like any other controller, but loading data from it or writing data to it is NOT supported.

Last month’s Amiibo emulation support work also saw major improvements and bug fixes. With these changes, Amiibo keys are now a mandatory requirement to read/write any data. This also fixed Amiibo support in games like Shovel Knight and Super Smash Bros. Ultimate among others.

A minor bug within GameCube controller input mapping which led to GC triggers overwriting the ZL/ZR buttons was fixed. And to further complement this fix, german77 also made analog input buttons toggleable for extended usability.

Accessibility is both very important and, sadly, very easy to ignore too. For example, something simple: what if a user needs more time to map buttons individually? In an effort to help with this particular case, the button mapping timer duration has been increased from 2.5 seconds to 4 seconds.

UI Changes

We also had a variety of UI improvements from multiple contributors this month.

The old SD card icon has been replaced with a new colourful microSD Card icon by Dev-draco.

Small details matter

Tachi107 fixed a few minor typos within the yuzu source code.

german77 modified the ordering of the input profiles saved in Emulation > Configure... > Controls. They are now sorted by name.

While the colourful theme has been the default for a while, some icons remained in a “Default” theme directory. But as grabbing icons from other themes isn’t supported on linux, this was broken. Docteh fixed this by moving all the icons to the colourful theme.

Since the Debug configuration tab was getting crowded, Docteh made it scrollable.

While this change also helps Windows users, Linux users will benefit the most from it

Docteh also fixed the broken help page hyperlink on the TAS configuration window .

People seem to forget that blue underlined text indicates a hyperlink intended to be clicked

Miscellaneous

For a long time, any yuzu bug reports from Windows users had to be manually reproduced and investigated by the team. Linux users had the option of providing stack traces, but there wasn’t an easy way for Windows users to provide similar debug info.

To overcome this, toastUnlimited implemented support to create Windows crash dumps within yuzu itself. This allows any layman on Windows to easily obtain a crash dump without jumping through various developer intended hoops. But since this feature has a big performance impact, this was added behind an option in the Debug settings for users to access. You can find it in Emulation > Configure… > General > Debug > Create Minidump After Crash.

Only use it if you want to debug a game or to pass the file to a developer, the performance loss is significant!

Since the dumps use modern Windows SDK features, there’s a risk that this change can break compatibility with older Windows options. yuzu only officially supports Windows versions 10 1803 and newer. And Linux, of course. It’s faster than Windows.

Hardware section

AMD Radeon, when increasing accuracy produces crashes

Users started reporting crashes when booting up Xenoblade Chronicles 3 on AMD Radeon GPUs running official AMD drivers (either the Windows driver, or the Linux amdvlk driver). We’re investigating the amdvlk source code to find the reason, and already notified AMD with all the relevant information we have.

The cause seems to be improvements in Macro JIT’s accuracy. Testing has shown that even with older driver and yuzu versions, disabling the MacroJIT speedhack causes the official AMD Vulkan drivers to crash, so it sadly checks out that improving its accuracy gives the same result now.

Affected users can try running Mainline 1188, or just run the game using OpenGL. The Mesa RADV driver is unaffected.

NVIDIA, one source of crashes down, more remain

We have merged the multithreaded ASTC CPU decoder mentioned last month, so we strongly recommend NVIDIA Maxwell and Pascal (GTX 745/750, 900, and 1000 series) users to disable ASTC decoding if you run the latest drivers.

You can find the option in Emulation > Configure... > Graphics > Accelerate ASTC Texture Decoding, enabling this setting uses the GPU to decode, while disabling it uses the CPU instead. As a bonus, now this option can be a performance boost on systems with very weak integrated GPUs, like old laptops with MX series Geforce hardware, or any Intel iGPU, where the CPU would do a faster job dealing with ASTC decoding. Testing has shown that Geforce MX 500 and Radeon Vega 7+ tier GPUs are slightly faster using the GPU for decoding. On affected NVIDIA hardware, the performance decrease while decoding ASTC textures is minimal. Avoiding a crash, for example, when opening the map in The Legend of Zelda games is arguably far more important.

Crashes caused by recent driver updates remain, but your writer continues to harass an NVIDIA driver developer daily (I only need to get into Intel to do the same to all three vendors now). This leads us to recommend the 472/473 series of drivers for Maxwell and Pascal hardware to ensure the best performance and compatibility with yuzu. There’s nothing wrong with using the latest drivers, but until these crashes are resolved, expect instabilities and graphical glitches with them. Turing, Ampere, and Ada hardware (1600, 2000, 3000, and 4000 series) exhibit some weird behaviour but are much more stable on the (at the time of writing) latest 520/522 series of drivers when compared to their older brothers.

One wonders how long Maxwell and Pascal will continue to be supported by NVIDIA drivers.

Intel ARC support

No news yet on Vulkan support for these new “AV1 video decoder cards” from Intel that can also work as a GPU. Low availability has made it difficult to get our hands on one, but it’s something we want to solve ASAP.

OpenGL is “functional” right now, but Intel continues to be the worst vendor regarding OpenGL support on Windows, so the experience is pretty bad. Linux Mesa drivers are reported to work correctly, and with good performance, in both OpenGL and Vulkan.

Speaking of AV1, for now we’ve been using h.264 encoding for the videos embedded in our articles, as it is both widely supported and very lightweight in regards to hardware requirements. Would you prefer if we switched to AV1 from now on? It can be a big battery drain on devices without dedicated hardware decoders, but it would allow for even lower bitrates while keeping a similar level of quality, something datacapped users have complained about in the past. Let us know on Reddit, our forums, or our Discord server what you would prefer!

Future projects

For once, we don’t have much to say in this section. Or maybe I should say, we don’t want to start generating hype for new projects just yet.

Blinkhawk has started working on Part 2 of Project Y.F.C., as previously mentioned, and the rest of the GPU gang (Byte[], Maide, vonchenplus) is also busy with some top secret changes (for now, your writer has a reputation to uphold) to improve both rendering accuracy and performance.

Having the first part of Y.F.C. merged to Mainline opens the floodgates to many projects that were on hold until now. We will discuss these in more detail in the next progress report.

Special thanks to Mysterious Writer B for their help with this progress report, and to CaptV0rt3x who came to aid at a moment’s notice.

That’s all folks! As always, many thanks for your time. We hope to see you in the next article!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report August 2022

GoldenX86 — Fri, 16 Sep 2022 10:00:00 -0300

Welcome back, yuz-ers! August was a month packed with progress. A plethora of graphical changes, kernel and file system improvements, and more work pumped into network emulation. Next slide, please!

Graphical changes

This month included a number of notable fixes for July’s blockbuster release, Xenoblade Chronicles 3. While Xenoblade Chronicles 3 did technically work on release day in yuzu, it took us some time to work out the stability issues.

The first of these, mentioned last month, was a fix for yuzu’s shader recompiler. yuzu does not use a GLSL compiler to generate SPIR-V, the Vulkan shader language. Instead, it generates SPIR-V directly, which is much faster, but has more potential for error. In this case, the shader recompiler failed to declare some variables in the SPIR-V shaders, and left references to them as null, causing the shaders to crash the driver when compiling. Maide and byte[] quickly found and fixed the problem, allowing the game to run in Vulkan on release day.

Wotah! (Xenoblade Chronicles 3)

The set of pipelines used by Xenoblade Chronicles 3 is huge, with many pipeline caches clocking over 15000 entries after extended gameplay. With all graphics backends, yuzu precompiles shaders before the game starts, and doesn’t allow starting it before compilation is finished. With OpenGL on GLSL, compilation takes over a full minute to complete with a pipeline cache as large as the ones generated by Xenoblade Chronicles 3. To make matters worse, you previously could not cancel out of the process while it was compiling. If you tried, yuzu would freeze up and continue to wait for the compilation to finish before allowing you to close the game. byte[] resolved this minor UX annoyance by having the shader compiler check for cancellation after each shader is compiled, allowing compilation to instantly be stopped at any time.

Name's Kermit the Frog, pleased to meet you (Xenoblade Chronicles 3)

Xenoblade Chronicles 3’s massive set of pipelines also causes problems for emulation. Because yuzu tries to give you as stutter-free an experience as it can, it tries to load all known pipelines into memory before you even start playing. This might be a reasonable proposition if a game had just a few thousand pipelines. However, keeping Xenoblade’s 15000+ distinct pipelines all in memory simultaneously causes the memory usage in the GPU driver to skyrocket. Cemu users of old may remember facing a similar issue when using NVIDIA GPUs.

To this end, byte[] looked for any issues in yuzu that might be causing the GPU driver to hold on to more memory than it needs to. byte[] noticed that OpenGL tracks individual objects for shader source code in addition to just for compiled shaders. Properly allowing these shader source code objects to be freed reclaims a substantial amount of wasted memory. Users can expect much lower VRAM and RAM usage now while running OpenGL and suffering emotional damage.

That's a big snuffin' difference (Xenoblade Chronicles 3)

One advantage yuzu’s OpenGL backend has had for Xenoblade Chronicles 3 for some time was stability. It didn’t really crash. However, Vulkan was another story. Even after the initial Vulkan shader fixes previously mentioned, the game would still randomly crash during cutscenes. byte[] was able to reliably reproduce the issue and found that yuzu was receiving some invalid references in the GPU processing. Whether or not this was something the game was legitimately doing, or just an emulation bug, he identified that yuzu could avoid the crash by passing VK_NULL_HANDLE for an image view, instead of trying to create an image view for a null image, which was guaranteed to crash.

Vulkan no longer cooks itself (Xenoblade Chronicles 3)

AMD users on Windows were left in the dark about Vulkan support for Xenoblade Chronicles 3 for a bit. One of our testers, your writer, obtained a log with Vulkan validation errors, and determined that the crash was due to trying to use some vertex formats that were not supported by the Windows driver. However, they were supported by RADV, the Linux Mesa driver. byte[] additionally identified a case of the opposite, where a format was supported by the Windows driver but not RADV, and implemented a generic workaround that would substitute a compatible format for both cases, fixing multiple crashes at once.

Progressively getting fit (Xenoblade Chronicles 3)

A few GPU changes not related to Xenoblade also made it in this month.

After years, since the beginning of our Vulkan backend, yuzu finally added support for VSync in Vulkan by new contributor djrobx. As described by the pull request adding it, if the emulation and display are very close to precise sync, there can be fits of juddering when the newly generated frames don’t decisively fall as next to be displayed. This change allows yuzu to completely synchronize frames with the monitor refresh rate, preventing any juddering. Thank you very much!

No more tearing, Vulkan edition

Merry, the author of dynarmic (and a real life White Mage), implemented an optimization for the process of converting between tiled and untiled images for the GPU. This doesn’t impact the performance of games very much, as they generally avoid converting between tiled and untiled images, but it significantly improves the performance of homebrew apps, which convert every frame to display to the console.

On the topic of unusual techniques, vonchenplus implemented support for a legacy OpenGL format called rectangle textures.

Legacy features seem to be popular with some game studios

As a side effect of this change, a pipeline cache purge had to be issued by Morph.

You may be thinking, but aren’t all textures rectangles? That is true, but the thing making rectangle textures distinct is that they are indexed in shaders with coordinates from 0 to their width/height – texel coordinates, instead of 0 to 1 – normalized coordinates. This mode is not very useful, so it is a surprise to see it still used by games. This change fixed a lot of rendering issues in Fast RMX and The Touryst (two games using the same engine).

No more vacations in the Abyss (The Touryst)

In the case of Fast RMX, disabling DYNAMIC CAMERA EXPOSURE in its in-game graphic settings fixes an overbright rendering bug. Testing shows that OpenGL seems to be more stable for this title.

F-Zero for Switch when, Nintendo? (FAST RMX)

Also focusing on homebrew, vonchenplus implemented support for a few things needed to get the RetroArch homebrew working inside yuzu. Yup, more “emulator in emulator” shenanigans.

The first step is the clkrst service, used to control clock speeds on the console, which was stubbed to allow RetroArch to boot. Emulation of clock speed is not very meaningful for yuzu, so it’s not a loss. The second is a specialty behaviour by switch-mesa, which uses a different framebuffer crop and appears halfway down the screen without proper emulation.

While preparing the Project London changes for release, Tobi found some issues with Rocket League that were preventing it from working properly. byte[] found that it could boot in single core, but the game had terrible rendering in Vulkan. To do this, byte[] added support for the R16G16B16X16 format used by the game, fixing the rendering issues. Still, more work is needed to make this game playable on yuzu.

The better League (Rocket League)

Working on his Magnum Opus, byte[] also implemented a workaround for a previous performance fix to Super Mario Galaxy and Super Mario Sunshine. While the performance fix should have been regression-free, since it was a bug in the buffer cache, many games needed the less accurate behaviour from before the change. Mario + Rabbids Kingdom Battle, Splatoon 2, and Super Smash Bros. Ultimate all had some extra flickering that was introduced after this pull request, so byte[] made the feature, pessimistic flushing, optional, and disabled by default, since most games were unaffected.

Feel free to test it, but expect a performance loss

Finally on the list for GPU changes this month, german77, along with bylaws from the Skyline emulator, added emulation for the viewport swizzling extensions used by some games. These were supported by NVIDIA GPUs with an extension, but not AMD or Intel GPUs, and so a few games would appear to render upside down or flipped. Games like Street of Rage 4, Celeste, Axiom Verge, and many others are now playable on AMD and Intel!

A new meaning for inverse climbing (Celeste)

There should be a difficulty mode called upside-down (Axiom Verge)

CPU, kernel, and file system emulation

We have some good news for users still running out-of-support versions of Windows! Thanks to an investigation done by vladkosi, Merry was able to implement the required changes in fastmem to support Windows versions older than Windows 10 version 1803 again.

While this is great news for the Windows 7 gang, it does not change our position regarding operating system version support: only Linux, Windows 10 version 1803, and newer are officially supported. Time will tell what happens to compatibility with older Windows versions after future changes to Vulkan and memory management are implemented, but for now, they work for a while longer.

But the good news doesn’t end there. Here are some changes intended to help the modding community!

In the past, inline comments added to pchtxt mods weren’t allowed, as we parsed the text in a way that made them incompatible. Morph now delimits the hexadecimal value string, allowing modders to add comments. For example:

Before: here             to here
         v                 v
12345678 12345678 // comment
         ^      ^
After:  here  to here

Our current file system emulation can be considered spaghetti code due to old guesses made when less information was available, and patchwork done by developers that are no longer contributing to the project. There’s no way to sugar-coat it, this is the main reason Morph has been working so hard for over a year on Project Gaia, a full rewrite of the current virtual file system implementation.

Meanwhile, some further patchwork can be done to reduce the headaches developers and modders currently endure. For example, Build IDs are padded by a bunch of zeroes, and modders are more used to the short form without including the irrelevant zeroes at the beginning. To remedy this, byte[] parses the Build ID string using fmt to dynamically add the required zeroes when needed.

Continuing to focus on improving RetroArch’s experience in yuzu, vonchenplus discovered that recursively calculating the size of the files when parsing the directories has a negative effect on performance, in this case perceived as “loading times” when booting a game with the emulator (inside an emulator). Simply ignoring this information is a good way to improve the user experience. Note that this change doesn’t help in running native Switch games on yuzu, it only provides faster load times for RetroArch.

UI changes

People have been asking for stronger audio volume in yuzu for a long time, and Maide delivers. Now, if the user goes to Emulation > Configure… > Audio, they can set the volume up to 200%, really cranking it to 11!

Don't wake up your neighbours

Something to keep in mind is that some games have their volume tuned up to the output they are using. A game may be louder in handheld over docked, for example, so don’t stress your poor ears.

Part of yuzu’s code is still based on Citra, even some sections that are no longer relevant, or have become outdated over the years. Cleaning up code is a boring but necessary part of any project, more so for open source ones, and yuzu is no exception. One feature that was very useful in the early days is loading ELF binaries. Instead of dealing with XCI and NSP dumps, back in the early days, devs dumped and extracted the whole file structure of the game, and loaded the ELF binary directly, in a similar way to how on Windows the user opens a .exe file to load a program.

Some years down the line and not only is this feature tarnished out of grace, but it also stopped working. Since it’s not a priority at the moment, and it can lead to user confusion, byte[] removed it from the File dropdown.

Asian Language Windows users noticed that the Size column in the game list and the Speed Percent setting displayed very weird characters.

Alien numbers

Of course this isn’t acceptable, so Docteh implemented the necessary changes to workaround this issue in Windows.

Much better

Adding to the list of Asian-language-only UI bugs, if a user started yuzu, for example, in Chinese and then switched to English, the Filter bar at the bottom and the game list columns at the top would remain untranslated, refusing to switch. Forcing Qt to retranslate these objects solves the issue, making Docteh happy.

Docteh implemented a couple more UI fixes as well, cleaning up the About dialog and making the default Port number in the Direct Connect UI ignore translations.

yuzu About dialog changes

Users complained that the Controller Profile drop down list’s character limit was too short, inhibiting their creativity. german77 stepped up and increased the character limit.

Input improvements

UI navigation with a controller is a relatively recent addition to yuzu, so there is room for improvement. For example, users reported that if the “Prompt for user on game boot” feature is enabled, controller inputs will be able to navigate the options and start the game, but it won’t be able to actually change the profile or cancel the boot process. Newcomer jonesyUK solves both issues with a bit of Qt magic. Thank you!

Some users prefer to depend on DS4Windows instead of yuzu’s native support for game controllers. While there is a good reason for that, it’s a simple way to have a single app handle XInput emulation, it can also lead to some interesting issues german77 discovered. For example, current versions of DS4Windows can’t handle two subsequent vibration commands, producing (depending on the person you ask) an uncomfortable, constant vibration. To solve this brrrrrracing issue, german77 added a small delay so the app doesn’t skip the stop signal.

On a more colourful topic, and with the intention of fixing a bug with Mario Party Superstars, german77 spent many hours cooking how to properly emulate controller colours, with a side dish of fixing battery level icons too!

Art Attack!

Navigate to Emulation > Configure… > Controls > Advanced and go to town!

And to close this section out, we have to own up to an oopsie on our side. With the initial implementation of IR camera support, the output was saved to storage. Every single video frame as an individual image file… This led to TONS of files being written to disk, making navigation with the file manager a pain, and eating a lot of free storage. Oops. german77 acted quickly and moved the output to a buffer.

If any user suffered from this and can’t remove the files, open the Command Prompt or Terminal, navigate to the Pictures folder, and run del IMG_00*.jpg to wipe them all out in a single blow.

Hardware section

Intel ARC joins the fun

We received information that early adopters of A380 Intel GPUs had issues running their games using Vulkan. Since this hardware is not globally available yet, it’s not easy for our developers and testers to get their hands on it, so please post issues in our GitHub including log files, or contact us on our forums or our Discord server. We’ll ask for more information, if needed, to find the reason for this. Hurray for the early adopter woes.

AMD, making use of OpenGL

Users with AMD GPUs reported that specific points in Xenoblade Chronicles 3 always resulted in vertex explosions. A workaround for this is to run the game with OpenGL and a 2X resolution multiplier, get past the area, save, and swap to Vulkan.

Why the oddly specific 2X resolution multiplier? For the same reason our performance chart last month had no results for Xenoblade Chronicles 2 on this new OpenGL driver, it leads to a driver related crash. 2X works around this crash and AMD has been properly alerted to this issue. No news from them so far, but since we got access into their Vanguard beta testing program, we’ll tell you as soon as the fix is out in a public driver. The game is not that much slower under OpenGL now, but shader stuttering will always be significantly better under Vulkan.

We recommend more emulator developers to apply to Vanguard, as the indirect approach of the built-in driver bug report tool is not ideal for the specific needs of console emulators.

NVIDIA making us go compute ourselves

We confirmed that at least a big part of the crashes affecting Maxwell and Pascal GPUs by the current 516.XX series of drivers is caused by some driver change in compute shaders, which resonates with our compute shader based ASTC texture decoder. As a solution, and to avoid this problem in the future as it isn’t the first time an NVIDIA driver update broke it, we’re considering switching to a multithreaded CPU decoder developed by Morph.

The cause for the shadow flickering on KOEI games is still under investigation.

Future projects

The delays in merging Project Y.F.C. don’t only affect Mainline users, they also impede progress in development. In another example of Hell freezing over (no one expected AMD fixing OpenGL), NVIDIA of all people open sourced some documentation (partially of course, this is NVIDIA we’re talking about, they’re so closed source they don’t even get fresh air). This includes proper names for Maxwell 3D registers, completely new registers, and even previously unknown values. Maide has been checking, replacing, and cleaning a lot of code thanks to this new official information, but the merge for this change will have to wait. No game fixes are expected out of this, but the clean-up and ease of understanding is very much worth it.

An interesting experiment that will benefit all users in a few bandwidth-starved games like The Legend of Zelda: Breath of the Wild, Xenoblade Chronicles 3, and SHIN MEGAMI TENSEI V, among others, is increasing the size of Vulkan’s stream buffer size. Testing shows a performance boost of 10-50% depending on the system, even without ReBAR support, which limits the buffer size to 256MB. Having access to all available VRAM opens the possibility for even higher gains!

Look at the performance difference! (Xenoblade Chronicles 3)

After too much nagging from your writer, byte[] implemented a draft to easily test the feature with a slider, but the final goal is to manage it dynamically, so don’t expect to see this feature as a UI option in an official release.

Working on the finishing touches for Project London, Tobi has not been passive at all:

Adding the ability to proxy socket packets, which includes custom rooms with local network support, including LAN games, not only LDN.
Stubbing and adding some required data types.
Improvements to the in-progress room feature.

The most fun ever doing internal testing

Oh! How could we almost forget? Project London, LDN support, is finally out now! More information in the dedicated article and Multiplayer Guide. We’ll recap the release in the next Progress Report.

That’s all folks! Thank you so much for sticking with us, and I hope to see you all next time!

Special thanks to Mysterious Writer B for your help on this article!

The suspense bites me

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

New Feature Release - Local Wireless Multiplayer

CaptV0rt3x — Sun, 11 Sep 2022 01:40:00 +0530

Hey there, yuz-ers! The MOST awaited feature of yuzu, Local Wireless Multiplayer (LDN), is finally here! So what are you waiting for? Time to grab your friends and jump right in!

What is this?

The Nintendo Switch console supports various multiplayer options. Among these, the following options are useful when you want to play multiplayer with other Switch consoles.

Table indicating yuzu's supported Switch multiplayer modes

Graphic demonstrating the key differences between the three wireless modes

The Switch's HorizonOS uses the LDN service for all Local Wireless communication.
This is why Local Wireless Multiplayer can also be referred to as LDN Multiplayer.

Thanks to the incredible efforts of our developers FearlessTobi and german77, Local Wireless Multiplayer in yuzu is no longer a dream! Special thanks to spacemeowx2 and all the contributors of the ldn_mitm project. Without their extensive reverse-engineering of the LDN service, and the gracious license exemption for yuzu, this would not have been possible.

⚠️ Attention

Currently, Local Wireless Multiplayer (LDN) is only supported between instances of yuzu.
Multiplayer between yuzu and a real Switch or between yuzu and other emulators is not supported!

Where can you get it?

The Local Wireless Multiplayer feature is now available in the latest version of the Early Access release. We will be working to polish this feature and make this available to the Mainline builds soon.

If you're using the yuzu installer, you'll automatically be updated to the latest build.
If you're not using the yuzu installer, please download it from our Download page.

We highly recommend using our installer to always stay up to date on both Mainline and Early Access builds.

Local Wireless (LDN) Multiplayer

yuzu’s Local Wireless multiplayer (LDN) differs a little bit when compared to the Nintendo Switch. The Switch console uses the LDN service to scan for other Switch consoles using Wi-Fi and connects all players. Here, one player would act as the host and all others would connect to it.

yuzu, on the other hand, employs virtual rooms to allow players to create and join game lobbies within said rooms. Since this emulates the Switch’s ability to do local wireless multiplayer, it does NOT rely on Nintendo’s servers and does NOT require a Nintendo Account. While on a real Switch, you’d be limited to the people in your immediate vicinity, yuzu boasts a complex server/client infrastructure that forwards a game’s wireless communication across the internet.

In order to connect with other players, players simply need to join the same room within yuzu’s Public Room Browser. But, before opening the Public Room Browser, you will have to first configure your network interface in yuzu.

You can find this setting under System -> Network and you need to select your internet connection from the drop-down as shown below.

yuzu's Network Interface configuration

Out of the box, we provide you with an assortment of public rooms hosted across the world by yuzu. Creating and joining rooms is extremely easy in yuzu and can be done in just a few clicks.

yuzu's Public Room Browser

If you’re a Verified User, you can create your very own public room for people to join. These public rooms can be seen by anyone using the Public Room Browser, but you can also password protect them to restrict users’ access. Verified Users will have their forum nickname and profile picture populated in the chatroom.

⚠️ Reminder

When hosting a room, remember to port forward or your friends won’t be able to connect!

If you prefer not to sign up for our platform, you aren’t out of luck! Unverified Users still have the ability to create unlisted rooms, directly connect to unlisted rooms, and can join any yuzu hosted room.

Do note that Verified Users will have their privileges revoked for violating any yuzu policies while in the room chatroom. Please respect the Preferred Game listed in publicly hosted rooms, as even unrelated games will add to the bandwidth load.

Public Room chat and moderation features

You can use these rooms for LAN mode games as well — instead of ZeroTier or Hamachi.

Please visit our multiplayer guide for further help with Hosting, Port Forwarding, Authentication, and Moderation of your publicly hosted rooms.

Development

FearlessTobi began development by leveraging the existing virtual rooms infrastructure from Citra. Due to code similarities between yuzu and Citra, this tried-and-tested infrastructure easily became the foundation of this feature.

Now that the virtual rooms were taken care of, Tobi moved onto the LDN service and its protocols. Using the research and code from the ldn_mitm project, he implemented the necessary changes for yuzu instances to communicate with each other over these virtual rooms. During this process, Tobi put an extra emphasis on ensuring no personal data, such as IP addresses, was leaked to the other room members.

As the feature slowly matured, Tobi began utilizing yuzu’s internal team of testers to verify the feature across several titles for compatibility and performance validation.

With the multiple testing iterations, various bugs and glitches were found. german77 relied on his own reverse-engineering and hardware tests to debug these issues, which then made it easy for the team to fix these various problems. He also made several UI fixes to improve its usability and brought the codebase up to yuzu standards.

Compatibility

Please note that as this is the initial release of the feature, some games may have some limitations. We hope to slowly fix these over the course of the next few months.

yuzu’s Local Wireless Multiplayer was tested by our team of Testers and Support staff across a small set of popular titles. Their compatibility findings are as follows:

List of yuzu-tested multiplayer titles

Screenshots

Animal Crossing: New Horizons

Splatoon 2

Mario Kart 8 Deluxe

Pokémon Legends: Arceus

Luigi's Mansion 3

Super Mario Smash Bros. Ultimate

Pokémon Let's Go: Pikachu/Eevee

Pokémon Brilliant Diamond/Shining Pearl

Diablo III : Eternal Collection

Teenage Mutant Ninja Turtles: The Cowabunga Collection

Monster Hunter Generations Ultimate

Kirby's Dream Buffet

Fin

As with any new update, we’ve tested the feature internally, but our efforts can’t compare to the community as a whole. We could have easily missed an edge case or some weird bug or issue among the vast collection of games with Local Wireless.

Test any and all games! Poke, prod, and play! Please break this release if you can! With your help, we can make yuzu the best it can be. Please reach out to us on our Discord and report any bugs you find, so that we can quickly address them.

That’s all we have for now, until next time! Happy emulating!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report July 2022

GoldenX86 — Mon, 15 Aug 2022 12:00:00 -0300

Hello yuz-ers, what a month we’ve had! Great graphical changes, an amazing audio rewrite, preliminary work on LDN support, testing new OpenGL drivers, and plenty of fixes! Continue reading to find out more.

Part 1 of Project Y.F.C.

Since we’ve been teasing you for months (and we will continue to do so) in previous articles, you know Blinkhawk has been working on a bunch of miscellaneous GPU related fixes and performance improvements. While we will have more information in a dedicated article in the near future, please enjoy the following brief overview.

As the scope of the project grew, the team decided to split it in two parts, with the released first part focusing more on game fixes and improving accuracy. While that doesn’t mean part 1 doesn’t already improve performance, part 2 will focus exclusively on it.

Becoming playable! (Hades & Mario Golf: Super Rush)

This story started many moons ago. The awesome devs working on Skyline Emulator finished implementing their NVDRV service (NVIDIA Driver service) and they offered it to us, as it is much more accurate than our old implementation.

YO-KAI WATCH 4, before and after

The implemented changes in part 1 of Project Y.F.C. include:

Full rework of the GPU driver, based on the reverse-engineering and code from Skyline Emulator with full permission from the respective team.
Full rework of GPU memory management.
Initial implementation of GPU Channels, fixing Super Smash Bros. Ultimate “World of Light” mode, Deltarune, and several other games.
Bug fixes and performance improvements to the GPU DMA engine.
Several fixes for Vulkan, the GPU Buffer Cache, and the Shader Decompiler, all of which affect multiple games.
Reworked host frame presentation to be considerably smoother (improves Xenoblade Chronicles games).

The World of Light single-player mode is now playable! (Super Smash Bros. Ultimate)

A large list of critical changes like this, sadly, brings regressions with it. We’re working to resolve these regressions, but Blinkhawk is busy with IRL things, so expect a delay to see these changes implemented into Mainline while we sort things out and pave the way for part 2. (Remember: you can check the hovercard or the PR itself to see its merge status!)

Not all games are in perfect shape... yet! (The Witcher 3: Wild Hunt)

Project Andio

Not a name we’ve mentioned before, right? Well, it was a surprise for us as well! Maide is behind this wonderful gift: an almost complete rewrite of yuzu’s audio engine.

The main driving force behind this project was to resolve the multi-year old issues that have accumulated thanks to our very old initial audio implementation. yuzu was missing many playback features, such as audio effects. But the old code was too hard to maintain, making it impossible to keep up with the Switch’s updates over the years.

Here is a before and after of Metroid Dread while underwater. You can notice the effects missing in the first recording, as if Samus was just out in the open.

Download the audio instead Download the audio instead

Cleaner code allows developers to more easily stay up to date (the current implementation uses the changes introduced in firmware version 14.0.0), and should help introduce changes found by reverse engineering in the future.

The list of fixes is so large, it’s practically countless. While over 15 official issues were fixed, it’s impossible to know how many undocumented issues have been resolved.

We plan to have a dedicated article for Andio in the near future where we will dig deeper into the changes introduced.

All users can enjoy the benefits of Project Andio, available in both Mainline and Early Access!

Preliminary work on Project London

Yes, bunnei, it’s London.

For those that didn’t catch on to the name, Project London is our work to get LDN (Local Wireless) support into yuzu, including hosted rooms for online connectivity.

Such rooms, and their corresponding user interface, are what Tobi has been working on.

Multiplayer rooms can be created, with chat functionality.

The implementation is based on Citra, and while it’s already perfectly functional, it won’t be available for users until the network backend is ready.

How's SEGA nowdays? (Puyo Puyo Tetris)

Thankfully, as you can see above, internal testing has been positive under ideal conditions, so the “only” remaining work is tweaking and bug fixing. If only it were that simple…

An online service like this requires the transfer of network packets, so ENet is added as a dependency.

Stay tuned for future improvements on this work in progress!

Core timing, or how to suffer so much with a fix

It has been an eventful month for a long-maligned corner of the yuzu codebase, generally referred to in hushed tones among developers as CoreTiming. CoreTiming may be the cause of many timing-related emulation issues in yuzu.

While reviewing Project Andio, Blinkhawk noted that one of his longstanding open pull requests, which implemented a more precise version of CoreTiming, fixed some audio corruption regressions in emulated games, and even fixed some games that were previously having issues with freezing, such as Mario Strikers: Battle League. With the new audio code being almost ready to go at that point, the team decided to get this pull request rebased and merged so we could have a new audio system without any regressions. The new CoreTiming implementation would use multiple host threads to wait for events, and should have been much better in theory.

However, it didn’t fix everything. Maide found that there were still some lingering issues with audio callbacks not looping as precisely as they needed to. In yuzu, looping events previously used CoreTiming to reschedule themselves for an exact number of milliseconds after their execution, instead of when they were intended to be executed. This caused significant drifting and issues with the new audio renderer. The usual victims were the most affected, users running CPUs with only 4 threads.

To fix this, Maide reworked the way looping events were handled. Now, CoreTiming automatically computes the correct time to reschedule a looping event, making the implementation significantly more precise for those types of events. With the change to looping events in, and noticing that the other changes Blinkhawk had added were causing serious regressions, the team opted to remove the multi-threaded host CoreTiming implementation, and then most of Blinkhawk’s new implementation entirely, as it was still causing serious performance problems for a subset of users.

But that wasn’t all that changed for timing this month. Intel Alder Lake (Gen. 12) CPU users on Windows have long been reporting noticeable clock drift in Super Smash Bros. Ultimate, but it got a lot worse since the NVNFlinger rewrite a few months ago. As previously reported, the resident bunnei rabbit mostly fixed this issue in a follow-up pull request which restored the (inaccurate) behaviour of the old implementation, and the clock drift issue improved significantly for those users.

Maide, not content to just improve audio, discovered that the way yuzu’s NVNFlinger implementation was waiting on buffers would drift, due to the same problem that was previously fixed in CoreTiming! Instead of reimplementing the fix here as well, he modified NVNFlinger to use a timing callback, which fixed the drifting issues in SSBU, and also resolved many longstanding issues with frametime inconsistency. This also provides a significant performance boost in many games due to keeping the frametime presentation consistent, and allows Fire Emblem Warriors: Three Hopes to be playable.

Jumpy, visible stuttering

Flat, smooth as silk

Time to smash those attack buttons (Fire Emblem Warriors: Three Hopes)

Finally, BreadFish64 implemented a way to read the exact TSC frequency of the host CPU. The TSC (timestamp counter) is a high precision timer measuring the number of base clock ticks performed by an Intel or AMD processor since boot. CoreTiming uses this value to emulate the ARM physical count register, which performs a similar role as the TSC for ARM devices, like the Switch. Getting the exact TSC frequency, as opposed to just estimating it, allows CoreTiming to avoid drifting due to mismatch between the host frequency, which depends on your CPU and the guest clock frequency, which is fixed to 19.2MHz.

More precision and faster boot times are never a bad thing!

Kernel changes

While using the new debugger on games and homebrew, comex spotted an issue causing yuzu to miss breakpoints in code that had already been run, or hit breakpoints which had already been deleted. Merry investigated and discovered an inaccuracy in Dynarmic’s caching of code blocks. Fixing the cache clearing and calculating block hashes correctly fixes the issues with breakpoints being hit.

comex also observed an issue with watchpoints, where resuming execution after breaking on a watchpoint would seemingly fail to resume with the correct state. byte[] investigated the issue and found that it happened when Dynarmic failed to update the PC register inside watchpoint callbacks. Merry fixed this issue again by completely rewriting Dynarmic’s support for watchpoints, now breaking immediately when necessary and avoiding almost all of the performance penalty of enabling watchpoints. Nice!

byte[] has also been hard at work fixing various kernel issues and inconsistencies throughout June, and this month is no exception. This time around, while searching for the source of a mysterious freezing bug in Super Mario Galaxy, he rewrote the entire scheduler and brought it in line with the current state of the art in reverse engineering of the Switch kernel. This fixed issues in a number of games, but most notably fixed the freezing issues users had in Mario Strikers: Battle League (once you use an intro-skipping mod), and allowed Mononoke Slashdown to boot for the first time.

Some graphical bugs are expected for now (Mario Strikers: Battle League)

Mononoke Slashdown

While preparing the new scheduler for release, byte[] also noticed an inefficiency in the way guest threads were being emulated. To fix it, he changed the process of starting fibers to use support for C++ language features, and significantly simplified the implementation.

GPU changes

Last month, Behunin contributed a new GPU queue implementation intended to improve the performance of submission handling from the emulated game. Some time after this, freezing issues in Fire Emblem: Three Houses started cropping up. After a long trail of hunting, byte[] thought the issue had been found and fixed by pull requests #8483 and #8538, but more careful debugging revealed that the cause of the freeze was unfortunately from the new GPU queue implementation! Morph stepped up and reverted the use of the new queue implementation, finally fixing the issue, at least for now.

Don't ask (Fire Emblem: Three Houses)

Xenoblade Chronicles 3, one of the most anticipated Switch releases in a while, released, and to the dismay of the yuzu community, would crash on boot when using Vulkan. Due to differences in time zones, Maide was our first developer to lay hands on the new game, with byte[] lagging behind. Maide found that there were some Vulkan shaders that crashed the GPU driver when they were compiled. yuzu is different from most Vulkan programs, and it directly generates shaders in binary format to respond to the needs of the game’s shaders, which can cause problems when the way yuzu translates a shader is different from the way a GLSL compiler would translate it. byte[] quickly helped Maide identify the sources of these shader compilation crashes and, together, fixed both FSwizzleAdd and ConvertDepthMode, allowing users to run the game in Vulkan.

Thank you Night for the amazing pics! (Xenoblade Chronicles 3)

We’re aware that AMD Radeon GPUs running on Windows still experience crashes with Vulkan at boot. This is because those drivers lack support for the VK_FORMAT_R16G16B16_SFLOAT texture format. We implemented an alternative path emulating this format with a similar one to solve this issue. We’ll cover it more deeply in the next progress report, along with several other bugfixes for this amazing game.

Another of the various issues affecting this new release is an absurd level of memory usage when running in OpenGL. yuzu, in the past, cleaned shader sources after dealing with the shader. Now, for some reason, this game manages to skip that check. In order to improve the ridiculous memory usage, byte[] implemented glDetachShader, a more “official” way to achieve the same result. While this doesn’t solve the issue entirely, testing shows a 5GB reduction in RAM usage from just a single code line addition.

Let’s stay on the subject of GPU emulation for a bit longer. In a past Progress Report, we explained how toastUnlimited implemented a status check system to ensure good Vulkan compatibility when opening yuzu for the first time.

The original implementation worked by running a small Vulkan instance at boot, detecting if it crashed, and saving the result in the configuration file. On the next boot after the crash, yuzu informs the user and locks itself to only offer OpenGL. This required two boots to get the whole picture, and a manual intervention by the user was needed to re-enable Vulkan as an option, pressing a button in yuzu’s configuration.

This new approach uses a child process that is only tasked with starting the Vulkan loader. If the child process crashes, the parent process marks the currently running instance of yuzu as not being Vulkan compatible. This has the benefit of only having to run yuzu once to detect the current status. If the user solves the issue (updating the drivers or any Vulkan layer application causing issues), only restarting yuzu is needed as nothing is changed in the configuration files now.

This change helps users identify issues and stop potential crashes, but the general recommendations still apply: manually update your GPU drivers (never trust Windows Update), and keep any application that runs an overlay or records the screen updated to their latest version.

Moving on to more specific game fixes not related to GOAT Xenoblade Chronicles 3, our resident Kirby clone, Morph, implemented a texture format MONSTER HUNTER RISE has been asking for: ASTC_10x6_UNORM. That’s right, another ASTC format. Your GPU will hate you while decoding it.

This doesn’t solve the rendering bugs we face with this game, but it makes things look a bit better!

Rise ye Tarnished! Wait, wrong game (MONSTER HUNTER RISE)

Linux Flatpak (Discover) and AppImage fixes

While Flatpak is not the recommended way for our users to enjoy their favourite Switch titles on Linux, due to lower performance and some missing desktop integration features, it is a great option for many Linux users who have Flatpak installed by default and want a low-friction way to get access to yuzu. It has been the preferred choice by Steam Deck users since its release. As the reports from users rolled in, the team fixed some notable Flatpak-exclusive regressions this month.

But why were these issues Flatpak-exclusive, and not found in the regular Linux AppImage builds? Flatpak enables extra checks in the C++ standard library, which are aimed to catch buffer overflow errors before they happen, intending to help with debugging. Unfortunately, if a check fails, it causes yuzu to instantly crash, which makes it more difficult to debug the issue from yuzu’s log files alone.

The switch to Vulkan by default caused games which used any CPU-based rendering to crash. If a game wants to render an image to the screen from the CPU, instead of the GPU, it will first convert the image into an optimized layout that the Switch GPU understands, and then ask the GPU to render the optimized image. To deal with this, yuzu undoes this layout conversion and uploads the data to the host GPU for presentation. byte[] discovered that due to the size of the optimized layout and the unoptimized layout being different, a subspan used in unoptimizing the layout would overflow and cause the check to fail. The fix was simple: just use the optimized size for the converted layer, since it would always be larger.

Thanks Wetbear for the pic!

It wouldn’t be a proper yuzu pull request without a seemingly unrelated regression. Pokémon: Let's Go, Pikachu!/Eevee! had a strange performance regression caused by byte[]’s previous change, where the framerate when attempting to play with Pikachu or Eevee would drop to approximately 7 frames per second. byte[] investigated it and found that using the larger size caused the process of re-optimizing a frame for the game to read back to be much slower, since it was now dealing with a much larger image. He then fixed it by using different sizes for the optimized and unoptimized images, finally putting these foolish performance issues to rest.

Project Andio introduced a few new regressions in the Flatpak builds as well. One of these was fixed in the pull request itself before it was merged.

When decoding buffers which were input from the emulated game, it was possible for a span operation to overflow. Maide fixed this by being more careful about handling the sample buffers when decoding input. From user reports, there were still crashes, and Maide found an issue with the DepopPrepare command, causing another overflowing span. Fixing this finally allowed users to enjoy the Flatpak builds once more. Flatpak Linux users rejoice!

Simple and convenient

Flatpak isn’t the only one to get a piece of the cake, AppImage receives some love too!

Vulkan detection is not only a Windows issue, it can also happen in free land. toastUnlimited found out that the libQt5Multimedia library causes issues with Vulkan in AppImage builds. Since the library is used, excluding libwayland-client is the workaround in place for now. We’ll evaluate the user response we get from this change and consider keeping it or removing libQt5Multimedia altogether.

Docteh started working on improving the environment variables used in our build process to give AppImages a proper title bar. Once this work is finished, the title bar should look identical to Windows builds.

Input improvements

A unique feature of the Nintendo Switch is the capability to use infrared cameras installed in the right Joy-Con. The main function of the cameras is to detect shapes and measure the distance to objects, but it can also be used to transmit a feed to a screen, letting you turn your Joy-Con into a heat-seeking monstrosity. Fox-2!

Interested in adding this awesome feature to yuzu, and providing full support for games like Game Builder Garage or the Nintendo Labo collection, german77 emulated the clustering processor required to let the games access the camera on the Joy-Cons or any camera the user wants to provide, even if it is a desktop capture obtained from OBS Studio.

While this looks like a homebrew app, it's in fact the real IR interface Nintendo provides for its games

Users wanting to play with this setting can find it in Emulation > Configure… > Controls > Advanced tab > Infrared Camera.

What a sleek little menu

This work doesn’t include the moment processor required by 1-2-Switch! just yet.

Steam Deck users reported having issues when using external controllers, but not while using the integrated Deck controls. toastUnlimited hopped onto the issue and found that the reason is the included prerelease SDL2 version we’ve been using. Reverting to a slightly older version solved the issue.

A recent and very interesting community effort is to focus on adding online functionality to single player games, allowing for fun co-op opportunities not possible in the original game. Super Mario Odyssey recently received a mod that allows for this online functionality, and the one thing keeping yuzu from supporting it was the on-screen keyboard lacking a way to input an IP address! Luckily, Morph was on the case and implemented the necessary symbols to input the required IPv4 addresses by the online mod.

Up to 10 people at once! (Super Mario Odyssey)

Link4565 implemented some required fixes in yuzu’s network services to improve compatibility with this awesome mod. Thank you very much!

Have fun ruining Bowser’s wedding!

UI changes

A small regression from the input rewrite revealed itself just now. The WebApplet’s input bit was assumed incorrectly, causing user input to be completely ignored. Thankfully, Morph found the reason and implemented the fix.

Last month, Docteh renamed the status bar’s DOCKED status (redundancy, yeah!). For consistency, this dumb writer decided to do the same for the Controls configuration window, for consistency.

Boring change, who is responsible for this?

Sometimes something “functioning as designed” can look stalled from the user’s point of view due to how the UX (user experience) is presented, ask any new Linux user for example. In this case, when loading an application, the shader progress bar at boot would appear stuck if a game was started with no previous pipeline cache or if a homebrew was booted. Since this leads to confusion, byte[] decided that it’s better to reset the status bar than let it remain stuck until the program finishes loading. As said before, the devil is in the details.

One of the available configurable hotkey options in Emulation > Configure… > General > Hotkeys is Audio Volume Up/Down. Users have requested to tune the curve in how volume is changed so that it’s more sensitive at lower values. Human hearing senses volume logarithmically instead of linearly, so it makes perfect sense. german77 added incremental steps the closer you are to 0% volume as a way to better copy how our flesh and bone bodies perceive the world.

General bugfixes and improvements

A beautiful feature of tightly integrated systems is their wonderful control over suspend and resume, and the Steam Deck is no exception. If you’ve ever experienced issues with suspend and resume, you know what I mean. Experienced developer devsnek wants to help yuzu take advantage of this feature over the course of three different pull requests. This includes emulating the actual suspend/resume mechanic of the Switch, as some games make use of it as one of their gameplay features. With these changes, users can suspend their games by simply pressing the power button of the Deck, exactly like on a Switch.

For those of us living in remote places, suffering from terrible ISPs, or both (FML), we have fantastic news! toastUnlimited reduced the size of each yuzu download by around 24MB by only including what specifically belongs to yuzu in its source. Those interested in building the bundled source that comes with the installer must now run git submodule update --init --recursive in order to be able to compile the project.

Hardware section

This is a new section to communicate and discuss new relevant bugs, fixes, and findings related to specific hardware that can affect the user experience within yuzu.

NVIDIA, missing the perfection that 472.12 was

We mentioned last month how the 516 series of drivers is detrimental to Maxwell and Pascal users, making Vulkan unstable. We’re still debugging the issue, as it isn’t easy to catch, but a possible cause is suspected: GPU accelerated ASTC texture decoding. If you own a Maxwell or Pascal GPU, must remain on the latest driver update, and want to test if you can make Vulkan stable again, try disabling Accelerate ASTC Texture Decoding in Emulation > Configure… > Graphics. Please report your results on our forums or Discord server.

Another known issue caused by the 516 series of drivers is some funny flickering on trees in KOEI TECMO games like Hyrule Warriors: Age of Calamity.

Your browser doesn't support mp4 video. :(

Day time party! NVIDIA Vulkan Left: 516.94 & Right: 512.95 (Hyrule Warriors: Age of Calamity)

These issues could either be regressions or undocumented behaviour changes, possibly caused after following the API specification more rigorously.

There are also performance related issues affecting users with G-SYNC/FreeSync displays, causing low framerates (usually games get stuck at 24-30 FPS). We have a few ways to bypass this issue:

Unfocus and refocus yuzu’s window each time you boot a game.
In yuzu, disable View > Single Window Mode.
Enable Exclusive Fullscreen from Emulation > Configure.. > Graphics > Fullscreen Mode. Then just play your games in fullscreen by pressing F11.

The root of the problem is caused by some bad combination of running a Qt window inside another window, and NVIDIA’s way of detecting the framerate of windowed applications. Removing any of the two factors solves the low framerate while still taking advantage of Variable Refresh Rate.

AMD OpenGL, 25 years in the making

Hell froze over, pigs learned to fly, and starting with the Windows driver version 22.7.1, AMD introduced a completely new OpenGL driver, making Radeon cards on Windows viable options to use both APIs, not just cool kid Vulkan. Performance is close to 100% higher, or more in some titles, and many rendering bugs are fixed. But why write about it, let the numbers do the talking:

Thank you RodrigoTR!

Wow! That’s a lot of numbers, let’s try to make it easier to digest:

Thanks toastUnlimited!

We’re not experts in the benchmarking area, so hopefully the above graphs help.

Above are results of an RX 6600 and a GTX 1660 SUPER running a few games in OpenGL and Vulkan. 22.6.1 represents the old infamous OpenGL driver, 22.7.1 is of course the new driver. Linux is represented by Mesa 22.1.3 running radeonsi with the amdgpu kernel module for OpenGL, and RADV for Vulkan. NVIDIA is running its latest (at the time of writing) Windows driver. Remaining relevant hardware used is a 5600X and 16GB of RAM at 3600MHz. The RX 6600 was running at PCIe 4.0 8x with Smart Access Memory enabled, although that won’t make a difference, more on that later. Operating systems used are Windows 11 and Manjaro Linux, both up to date and on their respective default stable branches. yuzu is on Mainline 1112, with GPU accuracy set to normal to make GPU driver bottlenecks easier to measure, 1X resolution multiplier, and Default value for Anisotropic Filtering.

A single regression under investigation and reported to AMD aside (Xenoblade Chronicles 2 crashes loading Abble’s Fountain, the measuring spot, could be caused by some driver thread crash), performance is now very close to Vulkan numbers, be it either from AMD or NVIDIA.

It’s now perfectly valid for a Radeon user to switch to OpenGL if a specific game requires it, like for example with Xenoblade Chronicles 3, or a Unity/Unreal Engine based game (SHIN MEGAMI TENSEI V). As a bonus, while not being very stable, the SPIR-V shader back-end can be used on games with “simple” shaders like Super Smash Bros. Ultimate or Super Mario Odyssey, making shader building much more tolerable when compared to GLSL, giving it a performance much closer to the Nvidia-only GLASM.

Another lesson learned from this is that some games, like Legend of Zelda: Breath of the Wild, just outright prefer NVIDIA’s mature OpenGL driver. Ara ara.

Lastly, to end this Red Team section. In the past, we reported a way to defeat RDNA2’s overcorrecting power manager in order to get decent framerates. This method, while simple, has a downside: It’s an overclock. Or at least counts as one.

We found an alternative that should be more globally applicable. The trick this time is to make the driver force high clocks on a more important section of the GPU when speaking about emulation performance in general: GPU VRAM. All this while keeping the warranty in check.

The process is simple, make the integrated video encoder work in the background while yuzu (or any other emulator) runs. This is easily achieved from Radeon Software by going to Settings > Record & Stream and enabling Instant Replay. Intel/Linux owners should be able to reach similar results by instead using the Xbox Game Bar or setting OBS to keep a buffer.

A driver toggle for power management would be so much simpler

After this, in yuzu enable Exclusive Fullscreen from Emulation > Configure.. > Graphics > Fullscreen Mode. Then just play your games in fullscreen by pressing F11. This step can be avoided if you also enable Record Desktop, but please keep in mind this will increase your power consumption even while idling.

The performance gains are the same as with the previous overclocking method, up to 73% in GPU bottlenecked titles.

RX 6500 XT and RX 6400 users, since you lack a video encoder in the first place, refer to our original method mentioned at the start, or ask for a refund.

Intel, killing support for 2 year old hardware

Intel recently announced that their Windows driver for Gen. 9, Gen. 9.5, and Gen. 11 GPUs (that is any CPU based on the 14nm Skylake architecture and all its many marketing renames, plus Ice Lake) is now in “legacy software support”, which in layman’s terms means they are officially dead. While this doesn’t affect yuzu immediately, any new Vulkan features we add in the future could potentially break functionality in a similar way to what happened with old AMD GCN hardware last year. This leaves integrated Intel GPU users with a single alternative, Linux, which offers support for even older hardware. For example, an ancient HD Graphics 4400 can run yuzu with the Mesa drivers.

Users should consider learning how to use Linux if a hardware upgrade is not a viable option in the near future, Mesa has always offered better performance for Intel GPUs.

Future projects

Part 2 of Project Y.F.C. is a bit delayed for now, real life issues as previously mentioned, but its feature list and expected progression is laid out.

Project London is progressing in a healthy fashion, we loved the internal testing done so far.

And a possibility has just recently started to open for even better GPU performance in the (not so near) future. GPU fastmem is one of the features that Rodrigo had to leave for later, before passing the torch and moving onto “greener sides”.

The main roadblock holding GPU fastmem back was driver support, which is now a mostly solved issue. We only need to start talks with the AMD, Intel, and the AMD Linux kernel module developers to ask for some increased limits. Once those obstacles are out of the way, yuzu should, for example, be able to take partial advantage of Resizable BAR/Smart Access Memory, helping reduce PCIe bottlenecks, and should help improve particle rendering to make GPU accuracy a less critical performance setting. No pressure, Blinkhawk!

That’s all folks! This one turned out to be longer than expected. Thank you for staying until the end, and we hope to see you again next month! Thank you NazD for the summary pic!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

New Feature Release - Installer for Linux

CaptV0rt3x — Thu, 11 Aug 2022 23:00:00 +0530

Hey there, yuz-ers! Guess what? We’ve got some news to share. We’re excited to announce that the yuzu installer now supports Linux! Let’s jump right in!

What’s happening?

As we mentioned, the yuzu installer is available for Linux. The installer will distribute AppImages of Mainline and Early Access builds for our Linux users.

You can now download the new installer from our Downloads page.

(Note: Early Access builds require a subscription to our Patreon. We appreciate any and all support!)

Why?

When we originally released our installer, our user base was predominantly composed of Windows users. Although a weak excuse, that’s why the installer’s Linux compatibility wasn’t a priority for us then.

But, over the years we’ve seen consistent growth in the number of our Linux users and realized that we had to ensure that they reaped the benefits of the installer too. We’re so happy our Linux community continues to expand and support us.

It's never a bad idea to pick both builds

Thanks to the efforts of toastUnlimited, who implemented Linux compatibility for the installer, we’re now able to address this long overdue feature request.

Remember, we update daily!

Fin

As with any new update, we’ve tested the installer internally, but our efforts can’t compare to the community as a whole. We could have easily missed an edge case or some weird bug or issue. So, please reach out to us on our Discord and report any bugs you find, so that we can quickly address them.

That’s all we have for now, until next time! Happy emulating!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report June 2022

GoldenX86 — Sun, 10 Jul 2022 12:00:00 -0300

Dear yuz-ers, we had fantastic progress during June! Driver bugs are being squashed, there are kernel and CPU improvements, UI and input changes, and more!

PSA for AMD Radeon users (and NVIDIA tags along)

Let’s begin with a driver bug we mentioned last month. The Vulkan extension VK_KHR_push_descriptor finally arrived for AMD hardware with driver version 22.5.2 for Windows, but it wasn’t stable. Radeon users would tell you that any game would crash in Vulkan after updating. To mitigate this, toastUnlimited implemented an extension block for the specific Vulkan driver version AMD reports for 22.5.2 (and its equivalent Linux AMDVLK package), 2.0.226.

Skip forward a month and the new 22.6.1 driver is released with VK_KHR_push_descriptor fixed! But, and there is a but, the new driver reports the same Vulkan version, 2.0.226, which forces our devs into a dilemma. Since the extension block can only work with what the GPU driver reports, the Vulkan driver version in this case, we can either keep the block and ensure compatibility with older broken drivers, or remove the block and force users to update to the current (at the time of writing) 22.6.1 driver. We opted to do the latter, as it keeps the codebase cleaner, and there is some evidence that suggests this may fix input lag issues found when using FreeSync displays.

To be specific, AMD Radeon users with cards still supported by AMD (Polaris and newer) must update to the latest video driver, 22.6.1 or newer, in order to get proper Vulkan support. Users with older cards out of support (GCN 1 to GCN 3) don’t have to worry, that hardware already can’t update to newer drivers (custom drivers can’t update Vulkan to add new extensions either), and yuzu will use the slower code path that works without requiring support for VK_KHR_push_descriptor.

Okay, that covers Radeon users. Let’s talk about the greener side. With the release of the 516.XX NVIDIA driver series, there seems to be a performance boost for Turing and Ampere GPUs running under Vulkan (that’s 3000, 2000, and 1600 series cards). Great, but it has a price.

Maxwell and Pascal users (1000, 900, 750, and 745 series cards) will experience device loss crashes some minutes into running games in Vulkan. A device loss basically means the driver pulling the plug for some reason. Until we find the cause of this issue and either implement a fix or report it to NVIDIA, Maxwell and Pascal users should stick to 512.XX drivers.

It’s always boring to start an article with a bunch of warnings, but this is one of the few tools we have available to reach as many affected users as possible.

Graphical changes

We should be covering the release of the first part of Project Y.F.C. here, but due to schedule issues it was moved to the next report. We’re sorry for the inconvenience and we’ll make sure to cover it in the next article. The good news is that besides yuzu Fried Chicken, there have been other fun GPU improvements to report.

Behunin is back with a very interesting optimization for our gpu_thread, “a bounded multi-producer multi-consumer concurrent queue”. This delivers a small 1 or 2 FPS performance boost, but more importantly, better recovery times after load related stuttering spikes.

The beloved The Elder Scrolls V: Skyrim, once considered the benchmark for open world gaming, until better games came out that is, can now boot! Skyline emulator developer bylaws found the reason this classic refused to boot until now: the assumed behaviour of the first value of the GPU related semaphore was wrong, it should perform a release instead of returning a constant zero. Now, thanks to this great find by bylaws, the Dovahkiin can finally wake up in that cart.

Yes, we're finally awake (The Elder Scrolls V: Skyrim)

You can see we have some rendering issues to solve.

One of our recent important rendering changes was the NVFlinger rewrite, who would have guessed that coding an implementation closer to the Switch would result in a smoother gaming experience?

However, after its release, user reports mentioned timing and frame pacing issues in games like Super Smash Bros. Ultimate. Match time would pass increasingly slower, around a second longer per minute on Ryzen systems, and exacerbated with Intel Alder Lake CPUs (12th gen).

The solution bunnei arrived to, contrary to what one would think, is to implement a less accurate behaviour. yuzu is multithreaded, and very heavily so (even if it doesn’t show up in CPU % usage graphs), and a 100% accurate implementation of NVFlinger would not be sensitive enough for the emulator’s requirements.

Weird CPU architectures aside, while the issue is solved, Intel Alder Lake users are recommended to run the latest BIOS and chipset driver versions. Check your motherboard/laptop support sites for these updates.

While still on the topic of NVFlinger goodies, we present a highly requested feature! Veteran users will remember that during its single threaded days, yuzu would allow control over game speed. With the arrival of multicore, known at the time as Project Prometheus, this feature was only available in single core mode, to the chagrin of many people. How time flies!

yuzu now has control over the frame time calculation, allowing a new method to unlimit the framerate regardless of the CPU emulation mode! You can find the option in Emulation > Configure… > General > Limit Speed Percent. Needless to say, if you want to make a game run faster, the game should allow it, and you must have the hardware performance to reach the new target speed.

No visual change compared to previous versions, but completely new functionality

Debugger

Now, we’re going to dive into a bit of developer paradise here.

A few months ago, yuzu developer byte[] found himself trying to debug some game issues in yuzu involving a certain Welsh cat, among others. Unfortunately, he soon ran into more trouble, as it was exceedingly difficult to view the internal states of games and watch or modify their behaviour without needing to extensively hack up yuzu.

The source of the pain was not having any way to use a debugger with the emulated games.

Originally, yuzu inherited a GDB-compatible debugger interface from Citra, but it was lacking many important features. And even that had to be deprecated during Project Prometheus (multicore emulation) because of its inherent shortcomings.

It only worked with single core mode
It was slow - it could sometimes take 30+ minutes to boot a game, particularly if you had any logging scripts
It had some significant code quality issues

After being removed during the Prometheus rewrite, yuzu did not have any debugger interface for a long time.

Wait, what is GDB again?

The GNU Debugger (GDB) is a portable debugger that runs on many Unix-like systems and works for many programming languages, including Ada, C, C++, Objective-C, Free Pascal, Fortran, Go, and partially others.

– Wikipedia

With GDB, you can:

Step through code on an instruction-by-instruction basis
Modify memory and registers on-the-fly
Even completely replace sections of running code dynamically

Thus, you can see how extremely useful having a GDB-compatible debugger interface is, for developers and mod creators alike, as you can now debug games, homebrew, and game mods without having to fiddle with the console every single time.

A 32-bit example, in this case Super Mario Galaxy

Challenges

After the old debugger interface had been deprecated, a few members of the community forked it and continued to patch and maintain it. A few notable ones are Hedges and astrelsky. It was thanks to these forks that byte[] was able to add initial support for the Wii Hagi emulator in yuzu.

However, he was soon faced with a much more annoying problem. Recent changes to yuzu’s CPU emulation were causing Super Mario Galaxy to deadlock. This issue only happened in multicore mode, right after the end of the first video cutscene. He was out of ideas and needed a functional debugger to continue investigating the issue.

Since the old debugger interface didn’t support multicore mode, byte[] had to start from scratch. Motivated by his drive to figure out the issue, byte[] began working towards a new GDB-compatible debugger interface for yuzu and he had very specific goals:

It should work
It should quickly get out of the way, so he could focus more on the root cause

As the saying goes, “the first step is always the hardest”. And for byte[], indeed it was; his biggest challenge: “Not knowing where to start”.

byte[] had the networking code written and working, but did not initially understand how to tie it with the threading code. After some healthy brainstorming sessions with other devs, he eventually figured out solutions for the challenges he was facing.

Changes

Since he was starting from scratch, byte[] took the opportunity to make some sorely needed improvements to the interface.

The old debugger interface was based on “stepping” the emulated CPU core. Stepping here means executing one instruction of the emulated program at a time.

This posed a number of problems because almost all games have multiple threads, and if you are stepping and a thread asks to wait, then another thread can start running in its place in the same CPU core, with all the state changed. This breaks continuity and can even crash the debugger.

The new debugger interface overcomes this by performing debug stepping on threads instead of stepping the emulated CPU core. In yuzu’s context, when a thread is stepped, the debugger will ask the thread to step, then the Dynarmic interface will detect this condition and tell Dynarmic to step it, and when the thread has been scheduled again, it will mark that the thread stepped and notify the debugger again.

Super Mario Odyssey, in gibberish form

What are the benefits?

Apart from this, we have a few more notable quality-of-life (QoL) additions. The debugger interface is now thread-stable, edge cases in stepping and pausing are now handled, and it has tons of useful debugging features, like:

Support for both 32-bit and 64-bit code
Ability to modify any memory and registers at any time
Readout of guest thread names
Support for unlimited numbers of instruction breakpoints
Support for up to 4 memory watchpoints

UI changes

When talking about user interface and experience, you can always count on Docteh.

In a repeat of what Morph fixed back in February, Docteh found out that after a crash, the yuzu main window may reopen in some kind of borderless fullscreen… thing. The culprit was the UILayout\geometry value in yuzu’s qt-config.ini file. A slap in the face and the issue should be gone for good. Ouch.

With the intention of helping new users adapt to yuzu, Docteh renamed the status bar DOCK text (which used to only change colour to reflect its status) to DOCKED/HANDHELD. Now the current emulated status is clearer, and users won’t confuse it when using dark or light themes. Making things easier to understand must never be underestimated. Car makers should try it someday.

The devil is in the details

Translation bugs always manage to slip by. The first time yuzu is opened, it will display a big folder with a plus icon, asking the user to add the location of their game dumps. The text of this message failed to re-translate if the user changed the interface language from Emulation > Configure… > General > UI > Interface Language. Solving this took a couple of changes in how the window handles re-translation.

Good way to learn another language!

Docteh is also sneaking some preliminary work for migrating to Qt6 in the future. The QDesktopWidget class is now officially deprecated, so QScreen takes its place.

Additionally, some classes affecting the Web Applet were also deprecated, so some tweaks were in order to ensure future compatibility. Hopefully Qt6 will mean the return of the Web Applet by default?

Once we’re ready to migrate, this should provide better dynamic DPI scaling, allowing 4K display users to finally understand what is going on in the control settings window, for example.

Input improvements

Input is german77’s speciality, a “diamond in the rough” that is being polished one PR at a time, for eternity….

Continuing the work with Ring Fit Adventure, german77 stubbed the PerformSystemButtonPressingIfInFocus service , solving an SVC (Supervisor Call) crash which occurred when pressing ZL or ZR.

With the official Switch update for the firmware version 13.2.0, Nintendo implemented a new GetVibrationDeviceInfo. While german77 worked on implementing those changes, one game in particular refused to work, de Blob. When this game sends a controller disconnect signal, it uses a -1 value, which is invalid as only unsigned values are accepted on the Switch. Maybe it’s an emulation issue somewhere, or this game just loves to do this and the Switch just accepts invalid values. Regardless, our solution is to replicate this peculiar behaviour. The end result is de Blob now gets in-game!

de Blob 2

Kernel and CPU changes

Possibly the most silent part of yuzu’s code, but also the most critical. Kernel emulation is the engine block that keeps all parts working together in harmony, so you can expect that changing even a small part of it can have ripple effects anywhere. One must tread carefully, heh, thread carefully. Sorry, not sorry.

Anyway, byte[] has been particularly busy this month in this delicate area, screwdriver in hand and not fearing anything. Several changes include getting up to date with the latest reverse engineering findings, but there’s more.

To help with pause and resume functionality, he has implemented KProcess suspension, “the kernel mechanism intended for this” as the pull request explains. Clean pause and resume is always a blessing when you have to leave the PC to do something else.

While working on simplifying guest pauses for single core and multicore emulation, byte[] discovered that if asynchronous GPU emulation and multicore CPU emulation were disabled (something we strongly recommend against, but it’s a valid option for CPU thread starved users, or FX users), a race condition would happen when initializing the CPU and GPU threads. Several single threads still are multiple threads. Hammer in hand, byte[] implemented some barriers to fix this specific crash.

Pause is the word of the week, and this time, it could make a specific game crash. The old StallCPU behaviour would wait for all thread execution to stop. It was slow, but safe. Fire Emblem: Three Houses would get into a GPU thread race condition with the new method. Telling the kernel to wait for all threads to stop on pause avoids the crash.

If, for some reason, yuzu would jump to an invalid address, emulation would hang and the log would get spammed with infinite amounts of Unmapped Reads. Fixing this required work on both Dynarmic and yuzu, resulting in stopping ReadCode callbacks to unmapped addresses.

exlaunch is a framework for injecting C or C++ code into Switch applications and modules. exlaunch can work on unpatched units, allowing developers to “go to town” with it. yuzu didn’t support it, but comex implemented the required functionality to have it up and running. Thank you!

Newcomer DCNick3 joins the fray! For their first brawl, they implemented the ExitProcess SVC, which allows homebrew apps to gracefully exit on close.

Issues with third-party antiviruses

Users have recently reported crashes starting with Mainline version 1075 and newer. The cause seems to be third-party antiviruses, more specifically ESET/ NOD32. A HIPS false positive is issued, sandboxing yuzu and blocking its access to the system page file. Basically, if fastmem is unable to secure 4GB of page file to work (or 6GB if the extended memory option is enabled), the emulator will crash.

Three options are available to solve this for now:

The user can disable fastmem from yuzu’s settings, the setting is in Emulation > Configure… > General > Debug, from there, enable the option labeled as Enable CPU Debugging at the bottom, and from the CPU tab, disable both Enable Host MMU Emulation options near the bottom. This will produce a performance loss that can reach up to 30% on some games.
Add a HIPS exception to both yuzu folders, %appdata%\yuzu and %localappdata%\yuzu. User reports show mixed results with this approach.
Outright uninstall ESET and use Windows Defender instead.

Here are image examples on how to reach the required options

Future changes

toastUnlimited has been working on making yuzu compatible to be compiled with LLVM Clang under MinGW-w64. There are multiple reasons to consider this approach:

The default compiler we use for Windows builds, MSVC, is currently unstable on its latest 2022 version, forcing us to revert to version 2019, and making yuzu lose some compiler optimizations in the process, losing a bit of performance.
GCC 12, the default Linux compiler yuzu uses, has optimization errors and problems with some warnings, making it unviable at the moment.
Clang allows for aggressive optimizations that should provide good performance boosts. One example is Polly.
Along with GCC, LLVM makes it much easier to produce code optimized for the SSE4.2 instruction set. That’s right Core 2 Duo users, you’re next in line for the chopping block.

The main reason we haven’t switched to this new system by default is Project Gaia, or, well, the lack of Gaias currently. Some of its changes are mandatory to get Clang builds up and running on Windows. While this pull request is completed, its full implementation will be on hold until Gaia is out, which isn’t far away now.

Get a kettle, boil some wotah, and make yourself a cuppa tea, because Project London has bloody began.

That’s all folks! Thank you for staying until the end. See you next month!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report May 2022

GoldenX86 — Sun, 12 Jun 2022 17:50:00 -0300

Greetings yuz-ers. This time around, we’re covering small and incremental improvements to yuzu. Rest assured, we also have some major rewrites and improvements in the works, and we’ll touch on those near the end. Roll the tape!

End of support for EOL Windows versions

Let’s first address the elephant in the room, shall we?

While working on dynarmic and kernel emulation, including improving the compatibility of 4 thread CPU systems, we made changes to dynarmic and fastmem that broke support for Windows 10 revision 1803 and older, including Windows 7 and Windows 8/8.1.

While fastmem was only ever designed to work with newer operating systems, the changes to dynarmic breaking support for older Windows versions was purely accidental. That being said, it is yet another sign of the times, and that a pre-Windows 10 experience in yuzu will continue to become more subpar. Due to our focus on improving accuracy, stability and performance, it doesn’t make much sense to divert time and resources onto maintaining old and out of support operating systems. From Mainline version 991 and onward, only Windows 10 revision 1809 and newer, Windows 11, and Linux, will be the officially supported operating systems.

This decision is reinforced by the lack of GPU driver support on EOL systems (which affects Vulkan support going forward), inconsistencies in the maximum path length (critical for file system emulation improvements), as well as worse memory handling on a kernel level, which is required to properly emulate the Switch and its subsystems.

Not forcing the developers to divert their time into supporting dated platforms (which they no longer use), means that they can instead focus on improving the core emulation components.

Finally, projects like Dolphin have already followed the same path, and for the same exact reasons.

A 13 years old Windows is old enough to drive in some places.

For those that still prefer to not upgrade, Mainline 990 and older will work just fine.

Vulkan by default

As previously discussed, we have to circumvent issues like OEM-locked drivers (so common on Intel hardware, it has its own official procedure) and broken third party software limitations (outdated screen recorders are a common cause of broken rendering) in order to provide a smooth experience with Vulkan as the default API.

The two main causes for Vulkan related crashes when trying to boot a game or opening yuzu’s configuration are:

Broken Vulkan layers on HUD and screen recording software could cause issues when yuzu and drivers add support for new Vulkan extensions. Keeping software up to date is the only way to prevent this issue from happening.
Outdated GPU drivers that lack the required features to run Vulkan. This is usually caused by relying on Windows Update to provide the drivers instead of manually installing the latest version, or Intel laptop vendors providing locked custom (meaning nerfed) drivers that are never updated. If possible, always install the latest GPU driver manually, don’t rely on Windows Update.

Thankfully, we have a new system that can workaround those issues that are outside of our control. yuzu will now perform a Vulkan check at boot.

If the check passes, yay!, you can use Vulkan or OpenGL and select which API to use, or in Vulkan’s case, which device to run yuzu with, as always from the Graphics section in configuration.

Check passes, Vulkan works!

If this check fails, a warning will be displayed the next time you launch yuzu. If this happens, you will only be able to use OpenGL as the graphics API. You will still have the option to pick the shader backend (GLSL, GLASM, SPIR-V) that best suits your needs.

Oh oh..

For those that happen to land in this situation, a button labeled “Check for Working Vulkan” at the bottom of the Graphics settings window will show up, allowing to retest Vulkan support.

Once you manage to solve the issue, click on the button at the bottom!

Thanks to toastUnlimited, gone is OpenGL as the default graphics API. Out with the old, in with the new. Long live King Vulkan.

Going forward, Vulkan will be the top priority for our developers, but they will still continue to support OpenGL. OpenGL users are recommended to use the GLSL shader backend, as GLASM and SPIR-V will receive limited support from now on.

Graphical changes, driver issues, and the nostalgia bliss that is the good old 64

This past month, byte[] continued the wave of improvements for Super Mario 3D All-Stars. This time, he noticed a bug in the DMAcopy (direct memory access) of the Nintendo Switch’s GPU.

DMACopy is a mechanism that many games use to send texture data to the GPU, it handles the format conversion from “pitch” (pixels on a line by line basis) to “tiled” (gridded) images. This process works by writing the pitch image data into GPU memory accessible by the DMA engine. Next, a DMAcopy is requested through the DMA engine driver, converting the image data into a separate buffer accessible by the GPU. This buffer will then be used as the texture on the final draw.

After fixing bytes_per_pixel, Super Mario Galaxy now has proper lens flare.

RTX On? (Super Mario Galaxy)

byte[] also improved the way OpenGL interprets face flips depth, replacing the previously reported fix. The face flips used by Super Mario 3D All-Stars and the Nintendo 64 emulation are an uncommon configuration on the GPU. The previous implementation had bad rendering in OpenGL, a complete black screen.

While this wasn’t an issue while using Vulkan (performance aside), now Super Mario 64 and Super Mario Galaxy are playable in both graphics APIs. Fermi GPU users rejoyce.

It's-a Mario, now running fast in OpenGL! (Super Mario 64)

One of the important parts of yuzu’s graphical emulation is the need to translate small sets of GPU instructions, called macros. yuzu uses a Just-in-Time (JIT) compiler to execute these macros in a performant way. It provides a performance boost of about 10% over interpretation in most cases.

byte[] found that due to emulation inaccuracies, sometimes a macro could try to access a parameter that was too far outside the bounds of what it was supposed to be accessing. This could crash the emulator without a single trace as to why in some cases. One less reason for annoying crashes.

Additionally, byte[] added the option to dump all macros used by a game for debugging purposes.

But why are macros important enough to merit their own dump mechanism?

Turns out, the Nintendo 64 emulator (totally not outside Nintendo’s Terms of Service), included with the Nintendo Switch Online (NSO) subscription, reassigns the same macros multiple times, each time with different code. yuzu incorrectly appended the new code to the end of the macro in this case, instead of replacing the existing code. Properly clearing that code on upload address assignments allows the NSO Nintendo 64 emulator to be playable. Time to re-enjoy those classics!

We need more games with the atmosphere of The Legend of Zelda: Majora's Mask

Future graphical fixes for the NSO Nintendo 64 emulator will be part of Project Y.F.C.. AMD and Intel users are free to run Vulkan without concerns, but NVIDIA users are recommended to use OpenGL.

Polaris AMD Radeon users (RX 400 and RX 500 series) reported that drivers 22.3.2 and newer caused crashes on multiple games, most notably The Legend of Zelda: Breath of the Wild and Animal Crossing: New Horizons.

Driver patch notes mentioned implementing the VK_KHR_workgroup_memory_explicit_layout Vulkan extension. The quick conclusion would be that AMD released a broken extension on the new drivers, which wouldn’t be the first time, but that wasn’t the case. The issue only affects Polaris GPUs, and the extension is available to newer architectures too, like Vega or RDNA2 (we don’t talk about ~~Bruno~~ RDNA1).

After a few debugging sessions we found out that yuzu’s implementation of VK_KHR_workgroup_memory_explicit_layout assumes that all compatible GPUs support 16-bit integer operations. While this was the case for all compatible GPUs previous to AMDs implementation of the extension, the Polaris architecture is notorious for its lack of the more recently popular 16-bit precision support (shows its age, you could say, Polaris is 6 years old by now), and as expected, forcing a GPU to do something it doesn’t support will result in a crash, hurray.

toastUnlimited disabled the extension on Polaris GPUs while we wait for our dedicated GPU devs to have the time to implement a proper fix. We plan to allow the extension to work with old-school 32-bit precision in the future.

While still on the subject of AMD Windows Vulkan drivers, we have to talk about another extension issue. Since driver version 22.5.2, support was added for VK_KHR_push_descriptor, an old extension that has been working in every other driver for the past 5 years, be it Intel, NVIDIA or Mesa.

While we don’t yet know the root cause of the issue, only AMD’s Windows drivers crash when calling VK_KHR_push_descriptor. As this extension is critical to the entire rendering process, any AMD GPU would crash on any game.

It seems that this time around, AMD may have simply released a broken implementation of the extension. This extension previously worked with yuzu’s Vulkan implementation without issue. If that’s the case, it’s AMD’s turn to solve the issue. In the meantime, toastUnlimited blocked the extension on the affected AMD Vulkan driver versions.

Elsewhere on the GPU emulation front, asLody implemented stencil fixes when two faces are disabled. This should improve rendering for some games that natively use OpenGL.

HLE Improvements

Moving onto the subject of HLE emulation, a very dear section for bunnei. The dev team has been working hard at improving the accuracy and performance of yuzu’s kernel emulation.

This time around, a big change was made with how games and the emulated OS can “lock resources”. This improves emulation performance with literally every game, and to a varying degree, on any CPU. Let’s dive in.

In software engineering, a spinlock is a lock that causes a thread trying to acquire it to simply wait in a loop (“spin”) while repeatedly checking whether the lock is available.

Example of a spinlock, simple but gets the job done

There exists another synchronization primitive with a similar function, the mutex.

The word “mutex” stands for an object providing MUTual EXclusion between threads. A mutex ensures that only one thread has access to a critical section or data by using operations like a lock and unlock. A critical section is a shared resource that many threads want to access. While there is no issue if multiple threads want to read the same critical section, no new thread can modify the section until the previous thread finishes its own writing. Under this scenario, the first thread locks the section, and will remain that way until the lock is released.

Example of a mutex

In theory, when a thread tries to lock a mutex and it does not succeed (for example because the mutex is already locked), it will be paused. The operating system will then take the opportunity to schedule an available and ready thread to run in its place. The paused thread will continue to sleep until it is able to acquire the mutex. This may happen once the current thread holding the mutex lock releases it.

Consequently, threads “spinning” to acquire the lock will waste (perhaps precious) system resources. While the Switch’s own operating system uses spinlocks, this drain on resources can be problematic when emulating on lower-end hardware. Using the host operating system (Windows or Linux) mutex allows yuzu to continue emulation tasks on other available threads.

Helpfully, most modern operating systems use hybrid mutexes and hybrid spinlocks. The spinlock approach would work fine on systems with threads to spare. However, for emulation, we need many threads (for UI, audio, GPU emulation, logging, etc.), so this approach is not quite ideal, especially on CPUs with low core/thread counts.

Thus by moving from spinlocks to mutexes, we were able to improve how yuzu runs on systems with low core counts. Our testing results showed that yuzu is now much more usable on 4 thread systems, solving stability issues on 4 cores/4 threads CPUs (most notably in Pokémon Sword/Shield), and substantially improving performance on (previously completely non-viable) 2 cores/4 threads CPUs.

The best news for the low-end gang!

UI changes

Pivoting towards user interface improvements, Docteh, who is becoming a regular here, has been very helpful with some translation holes we had for a while.

For example, the Custom RTC setting had several issues if the Windows system locale was set in certain languages, making it either display incorrectly (for example lacking the AM/PM indicator), or completely unusable. Fixing the display format allows Custom RTC to show up correctly in any language now.

The Network tab in Emulation > Configure… > System could remain untranslated after changing languages. This was a simple case of forgetting to include the tab in the translations, so Docteh fixed the oopsie and the lone Network tab now displays as it should.

Netto-kun. Now I want a Battle Network Legacy Collection, c'mon CAPCOM!

For a while now, the layout of yuzu’s About dialog, particularly on Linux, has had some issues. While we’ve attempted to fix it in the past, these attempts would have an adverse effect on the Windows builds, and vice versa. Via qtcreator, Docteh fixed the About dialog UI file, and removed an old warning caused by the original .png image. Thanks Docteh for taking the time to properly address the issue once and for all!

Controller changes

german77 is the undisputed king of this section again. He continues the endless quest of providing the best user input experience possible.

german77 noticed that motion continued reporting data even when disabled, causing Pokémon Let’s Go, Eevee/Pikachu! to spam StopSixAxisSensor errors in the logs. While working on this, he also noticed a missing parameter, delta_time. Its proper implementation allows yuzu to have an accurate motion refresh rate, equal to the Switch.

In an all-in-one pull request, german77 made several input changes, including:

Add proper error handling for several HID functions
Improve previous implementations to match more closely to native hardware.
Implement functions needed by Nintendo Switch Sports, EnableSixAxisSensorUnalteredPassthrough, IsSixAxisSensorUnalteredPassthroughEnabled, LoadSixAxisSensorCalibrationParameter, GetSixAxisSensorIcInformation, ResetIsSixAxisSensorDeviceNewlyAssigned.

While we’ve made some great progress here, Nintendo Switch Sports will be unplayable on yuzu until we rework our audio and make some much needed GPU fixes too. While audio and perfect rendering may not seem critical to playability, games often are quite unstable if these are not accurate. Rest assured, we’re working on these and will have more to share soon!

Changing game genres, Arcaea was reported as having issues with touch-release emulation. Turns out this game checks for the reported touch position on release, and some input drivers lose their position data after release. Additionally, multi-touch was found to not work properly on touch screens.

After performing basically a mini-rewrite of the touch emulation, german77 fixed both issues.

Osu! but better? (Arcaea)

One of the hurdles when working with a near endless amount of different controllers is the different quality of implementations they have. Since yuzu used to wait for the controller to respond after sending a vibration signal, slow controllers could stall the whole emulator, causing severe stuttering. To counter this, german77 moved vibration to a queue in a separate thread, allowing yuzu to move along with emulation, letting your controller make its best effort. This is just another example of how emulation can often be improved by moving blocking operations to asynchronous background threads to improve overall usability. In fact, yuzu uses dozens of threads for emulation, which is all the more reason why eliminating spinlocks really helps things to run as smooth as butter!

Future projects

While Project Y.F.C. was slightly stalled due to some NVFlinger regressions, these have since been resolved and will be covered in the next progress report! Under blinkhawk’s lead, Project Y.F.C. is making great progress and is on track to release soon. As a reminder, Project Y.F.C. is an overhaul of various parts of our GPU emulation, fixing many inaccuracies and improving both performance and compatibility.

Maide is up to something. (Hint: if you check the previous progress reports, you’ll notice a common theme with their pull requests)

And toastUnlimited is working on getting MinGW Clang builds for Windows, which could potentially be faster than the MSVC builds we’re using now. This work is tied with the release of Project Gaia, so it will take a bit.

Bonus track

As an extra bonus, gidoly, one of our team members recently got his hands on a Ryzen 5800X3D, giving us the chance to compare it to a regular 5800X fixed at 4.5GHz so only the extra cache should be relevant.

Here are the results!

Still the best upgrade path for a Zen1 user

While the 5800X is manually forced to a 4.5GHz frequency, the 5800X3D naturally tops out at a 4.45GHz clock speed, the results are respectable, but nothing amazing. Pokémon Brilliant Diamond certainly loves the extra cache, while Metroid Dread is punished by its extra latency.

That’s all folks! As always, thank you for your support, and we hope that you enjoyed this summary of our recent progress. See you next month! Until then, keep on emulating, and let us know what we can do to make yuzu the best possible emulation experience!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report April 2022

GoldenX86 — Wed, 11 May 2022 12:00:00 -0300

Hello yuz-ers, the month of April has been amazing! We’ll discuss CPU and Kernel performance improvements, several GPU emulation changes, UI tweaks, and more!

Saving Princess Peach yet again

Continuing his work to better support the official GameCube/Wii and Nintendo 64 emulators (codenamed Hagi and Hovercraft respectively), byte[] has introduced several new PRs to further improve the compatibility of the titles included within Super Mario 3D All-Stars.

byte[] first implemented support for GLSL in Super Mario Sunshine, as not everyone can run Vulkan. This is achieved by adding support for indirect addressing in OpenGL.

This change doesn’t include support for GLASM at the moment, since our developers aren’t too fond of having to deal with NVIDIA assembly shader code. Imagine being asked to fix an issue in a car engine, and the only given tools for the job are a rock and a stick.

However, that was only half the battle. Proper OpenGL support for Super Mario Sunshine and Super Mario Galaxy required solving an old limitation we had with the aging API: broken Z scale inversion.

Most Switch games use either OpenGL, the popular free graphics API, or NVN, the proprietary NVIDIA API exclusive to the console. Arguably, NVN is much closer to OpenGL than Vulkan in how it operates.

The Tegra X1 GPU on the Switch is flexible enough to allow the coordinate system to be changed at the discretion of the game developer. While most games will behave closer to what OpenGL expects, with the Z-axis facing away from the camera, Hagi and Hovercraft emulated games (which render using Vulkan and is exclusive to a tiny handful of titles on the Switch) have the coordinates inverted and the Z-axis facing into the camera, the way Vulkan games would expect to natively render.

byte[]'s Z-axis diagram

This was not an issue if you wanted to play Super Mario Galaxy or Super Mario Sunshine in yuzu with yuzu’s Vulkan backend, as the behaviour matched with what the game expected. But if you tried to play using OpenGL instead, yuzu would not correctly interpret that the faces were flipped due to the Z scale inversion, and thus rendered only the back faces of objects.

The solution is very simple, flip the front faces when the Z-axis is inverted.

Welcome to the Shadow Realm Resort (Super Mario Sunshine)

Next in line, you may have noticed that Super Mario Sunshine rendered with a black bar at the bottom. This is because the Wii and GC games natively use an aspect ratio different to the usual 16:9 we’re used to. Instead, the games render at a 5:3 aspect ratio. Super Mario Galaxy informs the system to explicitly crop the screen to its native resolution of 1920x1012, but Super Mario Sunshine does not, so yuzu previously did not attempt to crop the game, resulting in a conspicuous black bar at the bottom of the render.

Diagram of the cropping process

While the game proportions in Super Mario Sunshine, arguably, appear more correct with the black bar, that’s not how Nintendo intended the game to be played. For accuracy’s sake, byte[] interprets the game’s implicit crop request, which stretches the image to match the native 1920x1080 resolution of the Switch, both for Vulkan and for OpenGL .

Do not adjust your set (Super Mario Sunshine)

In the previous report, we mentioned how S8D24 < > ABGR8 texture conversions allow Super Mario Galaxy star bits to behave correctly. Well, it’s OpenGL’s turn to join the fun.

S8D24 to ABGR8 texture conversion diagram

We mentioned last month how Super Mario 64 had special requirements to start running on yuzu. Most games compile their code ahead-of-time (AOT), that is, before being shipped to you. The Operating System’s job is to execute that precompiled binary code, and then you’re playing games.

Super Mario 64, on the other hand, runs just-in-time (JIT), to make it easier to develop the Hovercraft emulator, and to allow reusing the same Hovercraft binary for different games. The Hovercraft emulator loads a native Nintendo 64 ROM of Super Mario 64, and then its JIT compiler takes the ROM and translates the original MIPS (the architecture of the Nintendo 64’s CPU) instructions into AArch64 (the Switch’s CPU architecture) instructions on the fly. Only then will the operating system execute the game code.

Ahead-of-time versus Just-in-time compilation diagram

This is similar to how yuzu translates AArch64 instructions into AMD64 instructions with the assistance of Dynarmic.

The JIT service, which is required to use JIT compilation on retail titles, is a functionality that yuzu didn’t have implemented, simply because no other game had ever needed it. Additionally, there were some obstacles to implementing it in a direct way, since it requires calling custom code supplied by the game, something which was never needed by any previous service implementation. So, some preliminary stubs aside , byte[] implemented the HLE JIT service to allow the Hovercraft emulator to function and Super Mario 64 to boot.

In a separate PR , byte[] adds documentation of how the JIT service interface operates. This should help other open source projects, if needed.

Of course, this wasn’t enough to get Super Mario 64 playable, as there were rendering issues to solve as well.

It’s never that simple… but let’s try to explain it simply. Nintendo Switch games bundle their own individual GPU driver with each game. This is done to increase compatibility, you don’t need to update every console in the world if a driver version has an issue.

For unknown reasons, either the Hovercraft emulator or the bundled GPU driver reports Vertex Buffers that are simply too large, especially when compared to what the game actually uses. Whether it’s an issue in the included emulator or just a driver bug, we can’t know for certain, but we do need to work around this problem.

Erroneous Vertex Buffer size diagram

So, instead of using the insane reported buffer size, byte[] says NO! and uses the backing memory size instead.

It's-a him! (Super Mario 64)

Performance on Vulkan is not stellar for now, but you can finally enjoy all 3 of the Super Mario 3D All-Stars games with both APIs.

Lastly, Morph implemented a fix to keep the web applet open in the foreground , as the Super Mario 3D All-Stars games require it or else they would crash a few minutes into gameplay.

General graphical fixes

Following up on last month’s NVFlinger rewrite, bunnei continued to track issues and bug reports. He fixed the reported issues and further cleaned up the code to improve code quality. See the code changes for the NVFlinger rewrite here .

Xenoblade Chronicles 2 and Hyrule Warriors: Age of Calamity would experience interesting issues which were caused by the new GPU Garbage Collector introduced as part of Project Y.F.C.. We talked about those changes back in January.

As you can see on the top bar below, Xenoblade Chronicles 2 would use exorbitant amounts of VRAM in OpenGL (top bar). The bottom bar shows the result after the fixes were implemented.

Not the best way to test your whole VRAM (Xenoblade Chronicles 2)

Age of Calamity would display interesting graphics at random intervals:

This is why you don't blast Caramelldansen too hard (Hyrule Warriors: Age of Calamity)

Blinkhawk fixed the regressions and both games are back in business.

Often times in emulation, when you fix one issue, another pops up. The cropping fix byte[] implemented for Super Mario 3D All-Stars had the lovely unintended side effect of breaking rendering for homebrew apps in Vulkan. Thankfully, Morph added the magic line to the code that solves this regression.

Skyline framework: Part 3

There has been important progress in getting the Skyline modding framework working. Here are the two links if you missed our previous progress reports on the subject.

tech-ticks has been quite busy working on the finishing touches . The latest changes include:

Better LayeredExeFs support, which results in easier mod distribution and self-updating capabilities.
Support for the SO_KEEPALIVE socket option, which allows the Skyline TCP logger to operate.
Implementation of DNS address resolution, which is required by plugins that use HTTPS requests.

We must mention that while Skyline kernel support is basically finished, bugs in yuzu’s codebase prevent proper operation of the modding framework. For example, due to underlying emulation issues, ARCropolis won’t work until Project Gaia is finished, and some of the changes previously mentioned need some fine tuning from our part to function properly.

There’s yet more work to do, but we’re a lot closer. We can see the finish line!

UI improvements

Merry, the core developer of Dynarmic, made some changes to the add-ons game properties window , improving column widths.

Low resolution users will like this

The hotkeys configuration window also got some love , changing the minimum column width.

It's also great for GNOME users

Both changes are extremely beneficial for bloated or size unoptimized desktop environments, like GNOME Shell.

Tachi107 fixed some embarrassing typos in our logging , and updated the About yuzu window to properly mention our new licence, GPLv3.0+. The + is there because we want to leave the door open for newer revisions.

Screenshot of the yuzu About box

Not stopping there, Taichi performed some cleanup and made improvements to Flatpak builds , including using proper app ID, fixing some typos, and adding a launch parameter to make yuzu use the dedicated GPU by default on Linux instead of the integrated GPU.

Docteh has also helped considerably in improving yuzu’s UI.

With a bit of manual thinkering, they managed to bypass some Qt limitations in order to display more readable hyperlinks in our dark themes.

People seem to have forgotten what hyperlinks are for, just click them!

Thanks to a report from GillianMC in our Discord server, Docteh found out that some quirks in the Qt API caused the compatibility status of listed games to not be translated. The cause lies in QObject, you can find the specific details in the pull request’s description . Now the status is properly reported in the corresponding language.

Example in Spanish

Similarly, D-Pad directions also didn’t translate properly. The same suspect, once again . Someone, please send a warrant asking for the detention of Carmen Sandiego.

Example in French

Kernel and CPU emulation changes

Let’s begin with two changes that happened in March.

Our resident bunnei rabbit continued his work on rewriting yuzu’s kernel memory management to make it accurate to the latest system updates. This time, he tackled and revamped how the kernel code memory is mapped and unmapped .

Code memory support, in the context of the Switch, allows games and apps to load and unload smaller parts of their code on the fly. Thanks to these changes, Super Smash Bros. Ultimate no longer causes memory access issues while loading/unloading NROs, making the game stable for long play sessions.

bunnei also migrated slab heaps for the guest (Switch) kernel objects from host heap memory to emulated guest memory. With this change, yuzu’s memory layout is now more closely matching the console.

A slab represents a contiguous piece of memory. A heap is a general term used for any memory that is allocated dynamically and randomly.

The slab heap is the space used to store guest kernel objects. By moving these away from the host (PC) heap memory (RAM) to emulated guest (Switch) memory, we can ensure that the kernel objects never go beyond the system limits and cause memory leaks on the host (PC).

Thread local storage (TLS), the mechanism by which each thread in a given multithreaded process allocates storage for thread-specific data, was also rewritten making it accurate to the latest HorizonOS behaviour.

With these changes, we have now completely fixed the kernel memory object leaks that affected a few games, but went largely unnoticed, due to the previous implementation allowing unlimited allocations.

Back to the list of April changes, bunnei also reimplemented how yuzu handled thread allocation for HLE service interfaces.

Services are system processes running in the background which wait for incoming requests. The Switch’s HorizonOS has various services that perform various tasks e.g Audio, Bluetooth, etc.

Previously, we used to allocate one host thread per HLE service interface because -

some service routines need to potentially wait a long time for completion, like network or filesystem access, and
we don’t support guest thread rescheduling from host threads.

A thread which is blocked will have to wait until the action that blocked it, such as I/O or simply sleeping for some amount of time, completes.

The issue with this approach was that since it’s the host (Windows or Linux) that schedules the service threads, yuzu could create weird behaviour particularly on systems with hardware limitations due to the spawning one thread per service and the sheer number of service implementations we emulate.

With the rewrite, yuzu now has a single “default service thread” that is used for 99% of the service methods that are non-blocking. For the services that are time-sensitive and for those that need blocking, we still allow thread creation (e.g. Audio, BSD, FileSystem, nvdrv)

This brings down the service thread count from double digits to single digits, thus improving stability and consistency - especially on systems with less cores. Users with 4 thread CPUs (either 2 cores + HT/SMT, or 4 cores) should see performance and stability improvements in most games.

Another battle for proper shutdown behaviour is fought and won. yuzu currently does not emulate multi-process capabilities of the HorizonOS kernel, because it is not required to emulate any games. However, the multi-process APIs that are used by games still need to be managed in the way they expect. All HorizonOS services have a port (for both client and server) that is used as a channel of communication between the game process and service process. A session is opened for each communication interface for them both and they are managed by their respective kernel objects. When the game closes the client port, the service closes the server port, and everything is shut down.

The issue with our previous implementation was that yuzu wasn’t properly tracking all the KServerPort and KServerSession objects for each service. And because of this, the services weren’t properly getting closed, which in turn was causing further issues.

This originally worked fine, but was regressed when we migrated guest kernel objects to emulated guest memory, as we mentioned previously. bunnei figured out the issue and quickly reimplemented how we track these kernel objects .

By having a single place where we can register/unregister open ports and sessions, we can now keep better track of these kernel objects. And by ensuring that they are closed when we tear down all services and kernel, we get much better emulation shutdown behaviour.

Input changes and general bugfixes

If the user sets a very high DPI value for their mouse while using mouse panning, the cursor may be able to escape the rendering window. IamSanjid implemented the required fixes , including better centering timings to solve this issue. Thanks!

german77 has several fixes ready for us.

Let’s begin with an interesting one. yuzu’s screenshot capture feature allows an easy way to save moments at the resolution the scaler is currently set at. The hotkey for screenshot capture could be spammed, leading yuzu to a crash if several requests for screenshots were sent. This could be worsened if the rendering resolution was set to a high value. To solve this, yuzu now ignores new requests while a capture is being processed , and prints a warning in the log.

There’s always room for improvements in emulation, as nothing is ever truly complete. This time, german77 focuses on inaccuracies found in our input emulation.

IsSixAxisSensorFusionEnabled is implemented by reverse engineering all Sixaxis functions, and it was verified by comparing with unit test homebrew results done on the Switch. This should potentially improve motion accuracy.

The HID service in charge of handling input commands, among other things, used to operate by copying its assigned shared memory and reporting back the changes. This leads to mismatches or delays in the input process, and can potentially make games read completely incorrect data.

Obviously this isn’t ideal, so german77 gets rid of the memory duplication and uses the ever magical * pointers to access the shared memory directly instead. This can fix bugs affecting countless games, with the biggest example being the Pokémon: Let’s Go games having a hard time detecting controllers.

Hotkey presses will now be triggered by using a queue . This has the benefit of not having to wait for the UI to respond, reducing their delay.

Analog sticks got some love , with a couple of important changes in their mapping:

The default maximum range is now set to 95%, to ensure that games get to use the whole range. This change, for example, avoids characters walking when the stick is at certain angles in games like Pokémon Legends: Arceus. The minimum range was lowered from 50% to 25%, providing greater precision, particularly for people trying to play racing games with a matching wheel. Auto-center correction is stronger now, avoiding drifting without having to rely on stronger dead-zone values. Individual axis values can be manually deleted now if buttons were mapped manually.

Previously, only Player 1 could automatically reconnect a controller by pressing a button. Other players only could do so when using a keyboard. german77’s pull requests aims to solve that, allowing any of the remaining 7 players to reconnect their controller . No privileges for those higher in the hierarchy anymore.

This change is under testing at the time of writing, as it could potentially cause regressions. Be sure to use the status hovercard to check back in a few days!

Future projects

Project Y.F.C. is not far away from releasing its first part of two planned.

Project Gaia continues to progress slowly but surely, now causing some previously broken games to finally boot for the first time.

Minecraft and Mortal Kombat 11 are now booting!

That’s all folks! We’re still playing catch up with some kernel and CPU optimization changes, so expect a more extensive section next time. Thank you for the company, see you next month!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report March 2022

GoldenX86 — Sun, 10 Apr 2022 12:00:00 -0300

Hi yuz-ers, glad to have you back. This month, we discuss an emulator inside an emulator, parts of Project Y.F.C. being added, graphical fixes for old and new titles, and more!

PSA for NVIDIA users: Part 4

Yes, there is more. This time we have a blessing and a curse.

While the latest 5XX.XX series drivers fixed tessellation issues affecting Luigi’s Mansion 3 and improved performance in Vulkan, they also introduced a crash when blitting MSAA images, meaning that running games like Monster Hunter Rise, Rune Factory 5, Sonic Colors Ultimate, and several others at resolutions different than native would result in a crash.

Thankfully, epicboy works around the issue by using 3D helpers like what’s been done for AMD and Intel drivers.

Now, to be fair, blitting MSAA images is against the Vulkan specification, so NVIDIA is in the right to no longer allow it. It’s just a bummer to have that sudden change in behaviour with something that was previously allowed and working. Proper documentation would help a lot here.

Tagging along, a PSA for AMD users too: the latest drivers, 22.3.2 and later, which add support for the VK_KHR_workgroup_memory_explicit_layout extension, break fishing in Animal Crossing: New Horizons and can possibly make other games crash. Revert to 22.3.1 if you find such a regression.

The Vulkan emulator

byte[], a newcomer to yuzu but in no way a novice at the art, arrived with a very interesting Pull Request, implementing Wii Hagi emulator support into yuzu.

This official Nintendo emulator (totally not outside their own ToS, they swear) is what allows the titles contained inside Super Mario 3D All-Stars to work. This means getting Super Mario Galaxy and Super Mario Sunshine playable, with Super Mario 64 support coming at a later date, as this game needs a complete JIT service implementation.

byte[] didn’t stop there, several other changes were also implemented.

Implementing SPIR-V shader support for register-addressed const buffer accesses , which also includes the LDC.IS access mode (the variant of an instruction), allows Mario to retain his body in this dimension in Super Mario Sunshine and Super Mario Galaxy.

Super Mario Sunshine

Super Mario Galaxy

Super Mario Galaxy uses a combination of the depth buffer and stencil buffer to “see” the objects behind the star pointer used to shoot star bits. That’s right, a texture determines game physics.

Properly handling that S8D24 < > ABGR8 texture conversion solves incorrect collisions with the poor star bits. A later fix solves issues with NVIDIA drivers .

Your browser doesn't support mp4 video. :(

No star bits for you until you finish your homework (Super Mario Galaxy)

A shader miscompilation (a bad assumption on yuzu’s part, oops) caused interesting black holes in Sunshine. Fixing the oopsie provides Delfino Plaza with the intended “shading”, and most likely silently solves issues in other games too.

Super Mario Sunshine

And finally, fixing a bottleneck in the buffer cache eliminates slowdowns and helps improve performance by up to approximately 4.5x in Galaxy. Again, this could have a positive impact on other games, but don’t expect it to be similarly significant.

Merry updated dynarmic to the latest version to provide better support for Super Mario Galaxy, adding support for accelerated SHA256 CPU instructions , among other changes. This avoids softlocking Galaxy at the final level.

Your browser doesn't support mp4 video. :(

This toad sure likes to talk a lot (Super Mario Galaxy)

POYO!

Kirby and the Forgotten Land turned out to be one of the best platformers in recent times, and also quite a challenge for our devs.

epicboy got the ball rolling by solving geometry pop-ins that were very noticeable throughout gameplay.

Your browser doesn't support mp4 video. :(

That tree just pops! (Kirby and the Forgotten Land)

This was achieved by improving the accuracy of the constant buffer uploads . This change also had the added benefit of fixing rendering issues in Monster Hunter Rise, making it playable.

Such pretty locations (MONSTER HUNTER RISE)

From Monster to Monster Hunter (MONSTER HUNTER RISE)

Another issue that we were quickly made aware of is that NVIDIA hardware would consume VRAM like crazy, to the point of filling up even high-end hardware in minutes.

PC requirements: RTX 3090? Not on our watch!

Unmapping pre-existing rasterizer memory before the memory range was mapped solves the issue and allows NVIDIA users to not need RTX 3090 levels of hardware to have a good experience.

However, epicboy issues a PSA that this pull request may introduce regressions that are being investigated, and that VRAM consumption is further improved by using the Disable Dynamic Resolution mod available on our site.

epicboy also fixed an svc break crash that would occur if the game was run with Asynchronous GPU Emulation enabled , an option that should always remain enabled.

And finally, an off-by-one error in the stream buffer was responsible for causing vertex explosions. The solution is to simplify the implementation of stream buffers . As the new implementation can only feed a single upload request at a time, this may provide a small performance loss in some cases, but it’s sure to fix several other games in the process.

A look inside Kirby's powers? (Kirby and the Forgotten Land)

AMD Radeon users may experience more stuttering than usual when running this game, depending on the specific GPU they have. This is because the available Windows AMD drivers don’t offer support for the VK_EXT_vertex_input_dynamic_state extension, which helps reduce the shader count by 3 times the original amount. The Mesa RADV support for the extension is broken in RDNA2 hardware, as reported last month, so it remains blacklisted along with the Intel Windows support. NVIDIA hardware and older AMD GPUs on Linux offer proper support and enjoy the significantly reduced shader count, and the associated reduced stuttering when building their cache. CPU thread count will be critical here, at least until AMD adds official support for the extension.

Graphical changes and optimizations

bunnei has the highlight of this month with the rewrite of the NVFlinger implementation , a part of Project Y.F.C..

NVFlinger is the service in charge of presenting to the display, so any improvement in this area will bring more stable frametimes, perceived as less stuttering even when the frame rate count stays at a solid 60 FPS.

Our original implementation was basically guess work done back in 2018, and it was lacking in several areas. For example, yuzu would block threads until the last frame was ready to be presented. This obviously leads to undesired stuttering unrelated to system performance.

The new implementation is on par with the Nintendo Switch, based on the Android Open Source Project. This means yuzu changes its licence from GPLv2+ to GPLv3+ to accommodate the Apache 2.0 licence AOSP uses.

Your browser doesn't support mp4 video. :(

ABZU

Games like ABZU and DRAGON BALL FighterZ improve considerably, but other games like Xenoblade Chronicles 2 require fixes that are still in testing in Project Y.F.C..

Your browser doesn't support mp4 video. :(

DRAGON BALL FighterZ

Enjoy the smooth as butter gameplay!

asLody has been working on optimizing the LOP3-LUT shader instruction with the objective of improving performance and helping with getting Hades to work. Sadly, this first implementation caused some issues.

degasus, which you may know from a certain Dolphin emulator, managed to implement a patch , which later turned into its own pull request, that solved the issues and achieved the same level of optimization.

This is not enough to get Hades running. Project Y.F.C. will take care of that in the near future, but it’s a small global performance boost that mostly benefits low-end GPUs. It also provides easier to read code when performing maintenance.

We documented our problems with video decoding on Linux Flatpak builds in previous progress reports. A check was added to avoid crashes, but in the process, Windows builds got stuck on CPU decoding! Users with low thread CPUs could immediately tell the difference during video playback.

By simply disabling this check on Windows , Windows builds can again enjoy the extra performance gained from decoding via GPU. If video playback feels smoother, you now know the reason! Thanks epicboy!

toastUnlimited started work on improving yuzu’s Vulkan error handling.

This is a very common issue caused mostly by very outdated GPU drivers installed by Windows Update, or custom slower drivers provided by laptop manufacturers that are used to lie on battery life metrics or keep up with cheapened cooling solutions. This most commonly affects Intel GPUs, but Vega based Radeon GPUs can also suffer from it occasionally.

Another popular reason for this issue, as mentioned in previous reports, is outdated Vulkan injectors breaking support altogether. Software like OBS Studio, OBS Streamlabs, Bandicam, Action!, Overwolf, GShade, iCUE, MSI Afterburner, or anything with an overlay that injects into Vulkan can completely break rendering if it is outdated, or the developers don’t keep up with recent Vulkan releases.

toast’s fixes solve 2 different scenarios . Changing the behaviour of how yuzu handles both GPU instance creation and rendering instance creation helps avoid direct-to-desktop crashes caused by outdated drivers or broken Vulkan injectors.

There’s more work to do, but this lets us get closer to offering Vulkan as the default graphics API in the future.

epicboy found out that avoiding a doubly locked mutex fixes a crash when using Extreme GPU accuracy on the OpenGL backend, making it a safe option for those aiming for the most possible accurate rendering. This option is only accessible from Emulation > Configure... > Graphics > Advanced.

He also includes an optimization focused on eliminating if(false) {…} branches in the shader code . This has the added benefit of reducing shader build times ever so slightly. Hey, less shader stuttering is less shader stuttering!

Not all changes benefit everybody

In an effort to reduce RAM use in yuzu, Merry tested reducing the size of the code caches in dynarmic. During internal testing, the change proved to be perfectly fine, a small reduction of memory use with no side effects.

Once the result went live, users started to complain, reports of sudden stuttering affecting Super Smash Bros. Ultimate were in all communication channels.

Dynarmic has to emulate whatever instruction a CPU lacks, and that takes more cache space. Older hardware, for example Skylake based CPUs (gen. 10 and older) or early first and second generation Ryzen CPUs, would not only have smaller caches, but would also lack support for some instructions more modern CPUs provide.

Once the cache runs out, a recompilation happens. This results in impressive lag spikes experienced during Smash battles a few seconds into the match.

Reverting the change was all that was needed to solve the issue. Happy Smashing!

General bugfixes

Recent Nintendo Switch firmware updates changed the behaviour of the inline on-screen keyboard. Morph updated yuzu’s emulated equivalent to match the new versions, allowing games from the Monster Hunter series to be playable without having to transfer a save file after character creation was finished.

The hardest part of starting any new game, character naming... (MONSTER HUNTER RISE)

Morph also worked on MiiEdit, the applet for Mii creation that german77 started working on last month. Morph’s changes add support for games requiring older firmware versions .

Our holy war against crashes at shutdown continues to rage on. Merry fixed a deadlock on exit that was hidden in the logging thread . It’s like the Hydra, you cut off one head and two new heads appear.

toastUnlimited has been having fun working on improving yuzu-cmd.

Adding the -c or --config argument will allow the user to specify a custom location for a configuration file . This can be useful for game specific settings.

Extended memory layout support was added .

SDL2 has a limitation in that it doesn’t automatically resize the “rendering canvas” when you enter in fullscreen mode. yuzu previously used the resolution of the native game, so either 1280x720 in undocked mode and 1920x1080 in docked mode. With this change, the resolution of the desktop will be used instead , allowing proper exclusive fullscreen support, and letting the scaling filters display as they should.

v1993 applied some changes to the sockets (LAN and LDN) service, allowing inexact address length values . This prevents crashes on Minecraft v1.12.1, as the game passes zero as the value for the address length.

toastUnlimited gave us a simple, but really important, quality of life change, disabling the Web Applet by default . This was necessary due to many games having issues with it. The Web Applet is responsible for blocking controller input, and not many users are interested in the tutorials the service is mostly used for, so it’s a sacrifice worth the small loss. For anyone interested, the Web Applet can be re-enabled from Emulation > Configure… > General > Debug > Disable Web Applet.

And continuing on the topic of quality of life changes, yuzu will now save the fullscreen status for future boots. Close or stop a game while in fullscreen and the emulator will automatically maximize for you when you start the next one!

german77 couldn’t let a month pass without contributing a pull request! He’s fighting to make Flip Wars compatible. Correctly adding a Signal event on AcquireNpadStyleSetUpdateEventHandle makes the game playable.

Flip Wars

Future projects

Merry is testing adding a Paranoid CPU accuracy , an option not for the faint of heart! It would disable most optimizations (but not fastmem) with the main purpose of aiding in CPU optimization debugging, but we all know it will be used for extra comfort if there is CPU performance to spare.

Project Gaia is experiencing some minor delays caused by new additions Nintendo made in recent firmware updates.

And regarding Project Y.F.C., we’re measuring performance increases, as well as getting games to render for the first time:

It's one hell of a game! (Hades)

That’s all folks! Thank you for staying with us, and see you next month!

We will include relevant kernel changes in the next report.

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report February 2022

GoldenX86 — Tue, 15 Mar 2022 12:00:00 -0300

Glad to have you here, yuz-ers! This month, we’re proud to showcase a ton of kernel changes that finally fix long standing bugs, massive performance improvements, UI and input changes, and more!

But first, we present to you: a heavily requested feature. Not for yuzu, but for our articles.

While we try to only discuss changes that are currently available in Mainline builds, due to time constraints or delays, we sometimes list pull requests that will be in Early Access for a few extra days after the release of a progress report.

To allow for accurate status reports, liushuyu implemented hovercards that we writers can then add to links for pull requests. If you place the mouse over the dotted hyperlink, you will be able to see the current status, title, number, and merge date of a PR. Try it here! .

The different possible statuses are:

Red: Pull request closed, it won’t be part of any build
Purple: Merged to master, it already is on Mainline, or will be in 24 hours at most (if our buildbot doesn’t die in the process!)
Green: Pull request open, not yet added to Mainline unless it has the mainline-merge tag, check the pull request link to confirm

There are a few more, but these 3 are the most important

You can come back to the articles at any time from now on to see if a feature has been merged to Mainline already, as these cards will update dynamically accordingly. Keep in mind that this is not an immediate process. A merged pull request will be added to Mainline in the next autobuild, so it may take up to 24 hours to see a status change on this site.

With that out of the way, let’s get started!

Graphical fixes, and how to increase performance

Due to problems with the RADV drivers on Linux, using the Vulkan API would crash yuzu when run on AMD’s RDNA2 graphics cards. Most notably, this problem affected the Steam Deck, as reported by users who tried testing yuzu on their devices.

It was determined that the crash happened because of VK_EXT_vertex_input_dynamic_state, a Vulkan extension used to minimize the number of pipeline objects needed during the shader compilation process. These structures are massive, and sometimes, a game may want to change only a small portion of the contents held in them, such as the vertex input state. Using this extension allows the API to dynamically change these members in the structure with a simple function call, eliminating the need to create a whole new object, thus, reducing the amount of resources used by the operation.

While this bug is being resolved upstream, epicboy pushed a PR to blacklist the extension on RDNA2 devices running RADV drivers, so yuzu does not outright crash.

But there was still one more driver with problems for us out there.

Mesa’s ANV driver on Linux does not support the texture format VK_FORMAT_B5G6R5_UNORM_PACK16, and this caused yuzu to crash when running a game that made use of it, such as Bowser's Fury. To bypass this problem, voidanix implemented a solution that emulates BGR565 textures by swizzling the RGB565 format instead.

In a similar vein, Morph implemented a missing vertex format , used by the title パワプロクンポケットR (Power Pro Kun Pocket R).

asLody also implemented a missing framebuffer format , this time used by Yo-kai Watch 4.

The original name is technically 妖怪ウォッチ4 ぼくらは同じ空を見上げている (Youkai Wotchi Bokura wa Onaji Sora wo Miageteiru)

Another fix by this developer was adding missing semaphore operations for MaxwellDMA, used by Legend of Zelda: Breath of the Wild and Pokémon Legends: Arceus.

Kernel changes, and how to tame Smash

Continuing with the ongoing work on the kernel, bunnei has revamped the kernel memory manager to make it more compatible with the latest system updates.

One neat setting that came along with these changes is the ability for yuzu to support different memory layouts, such as the “6 GB extended memory layout”, used in developer units (a feature requested by the modding community).

Some mods can utilize more RAM than the Switch can provide, mainly high resolution texture replacements. To solve this issue, bunnei added a toggle to enable the extended 6GB memory layout that real developer kits would have available. Those extra 2GB will allow heavy mods to work without issues. You can find the setting in Emulation > Configure… > General > Extended memory layout (6GB DRAM).

Mod away!

Don’t expect it to make a difference in emulation performance, games will not care if the emulated console has more than 4GB, they only care about having enough free memory for their operations.

bunnei has also been improving the accuracy of the page table management by migrating locks to using emulated guest locks and improving the mapping and unmapping of physical memory .

As always, the biggest motivator behind this work is increasing the accuracy of our implementation, while also fixing any bugs that may have been hiding there these past years.

Dynarmic, our ARM JIT recompiler, also got a number of new optimizations and bugfixes this month.

Blinkhawk corrected the fencing logic for the serialization of memory store/load operations in Dynarmic’s x64 code emitter, and subsequently updated the submodule to bring these changes into yuzu’s codebase. This fixed the freezes that affected Pokémon Legends: Arceus.

While investigating the stability issues of Super Smash Bros. Ultimate, bunnei and Merry found that the problem was caused by an error in the SpaceRemaining function, used to calculate the remaining space available for JITed code in a cache block.

Dynarmic splits these code blocks in two regions, named near and far. This scheme aims to minimize L1 CPU cache misses by keeping “hot” code in near readily available for execution, while “cold” code is pushed into the far region. Due to a bug in the way the remaining space was being computed, the near region would overflow into the far region, overwriting “cold” code with “hot” code. The CPU would then attempt to run the “cold” code that was previously there, and crash horribly on the try.

Ultimately (no pun intended), this translated as crashes after a few matches in SSBU, since that was the time it took to run out of space and overflow the cache. By correcting the comparisons used to compute this value, the devs were finally able to mitigate one of the longest-standing problems surrounding this title.

We did so many CPU fights to test these changes... (Super Smash Bros. Ultimate)

Merry has also been busy implementing support for a new CPU optimization , which makes the emulation of ARM exclusive access instructions through the use of cmpxchg (compare and exchange) instruction of the x64 architecture.

The ARM instruction set contains instructions that can exclude access to a memory address, so that only some instructions — a pair, in this case: one for reading values, and another for writing them — can operate safely in a multicore environment, without the interference of instructions from other threads, who may also want to access the same value in memory.

It achieves this by marking the address “for exclusive access” after reading the value in memory, so that an “exclusive” store instruction only writes into this address if it is marked with this flag. A “normal” store instruction, on the other hand, was designed to always clear this flag after writing. Thus, the exclusive instructions can use this information to know when the value in the memory address was altered by a non-exclusive instruction, and restart the whole job again, until the operation succeeds.

ARM is able to control this behaviour through a piece of hardware called the Exclusive Monitor. But emulating these instructions accurately on the x64 architecture can be very difficult, given the complex nature of testing and debugging in a multithreaded environment. Thus, their previous implementation was rather conservative and inefficient, to ensure concurrency.

It is possible, however, to approximate the original behaviour through the use of cmpxchg, which compares the value in the memory address with a reference, and if they match, it writes a new value into it. Thus, one can use the value in a memory address as the reference, and later write another value into the same address if, and only if, the stored value matches the reference. Relying on the semantics of this instruction, exclusive memory reads and writes can be inlined into the JITed code and speed up their execution.

Titles that make extensive use of these exclusive instructions, such as Pokémon Legends: Arceus, should see a slight increase in performance.

Some Nvidia numbers

Some AMD numbers

General bugfixes and UI changes

german77 did some work on the UI to spice things up.

He improved SDL battery level detection , realigned some of the UI elements in the control settings, and gave us new, prettier battery symbols!

Cute and simple!

german77 also added new hotkeys by popular request. Joining the fray are Docked/Undocked (for controllers), Window Adapting Filter, GPU accuracy (switches between normal and high), and mute/unmute audio.

Once you master the hotkey-jutsu, no one will be able to stop you

Another highly requested fix was improving Amiibo support . Our old code wasn’t very accurate, leading to several games failing. While there is room for improvement, this new implementation is far more accurate and should allow stable use of Amiibo dumps in most games now.

We also want to announce that native support for NFC scanning of physical Amiibos is being worked on! We’ll have more information to share as progress is made.

Morph fixed a weird issue that’s been appearing lately. Under some circumstances, after reopening yuzu, the window would be a maximized borderless… thing. As it turns out, for some reason the configuration file was not resetting the frameless flag after closing yuzu. Forcing a removal of the flag at each boot solves the issue.

Maide added a very useful feature to modders and anyone interested in the internals of their games. Previously, yuzu dumped the base exeFS, which only includes data from the base game, missing any new addition from updates or DLCs. Instead, by dumping the patched exeFS , like EliEron suggested in the past , users will have access to update files!

toastUnlimited found out that Splatoon 2 crashes when accessing the inventory in the LAN lobby. Stubbing the IsUsbFullKeyControllerEnabled function is all that was needed. Splat your friends with impunity!

With all that ink evaporating into the atmosphere, rain must be fantastic

For retro gaming fans, both toastUnlimited and german77 have fixes for the SNES and NES emulators included with the Nintendo Switch Online service (yes, you can dump and play those offline too). Stubbingmnpp:app solves crashes, and updating the process revision of our audio emulation allows the official emulators to work properly on yuzu.

Our team members are big Earthbound fans

Input improvements

As it happens each month, german77 dominates this section.

As a way to test how strong the current rumble setting is, you can now force the controller to vibrate by pressing any button while the Configure Vibration window is open.

Joy-Con goes BRRRR

Gamepads have drift, not only in the exaggerated fashion Joy-Cons are known for, but every gamepad has a certain degree of drifting to it. To hide this, consoles auto-center their sticks.

On yuzu, one of the limitations of SDL is that it will only read the factory calibration on a Nintendo official controller, skipping any user calibration profile that may be available. We counter this by auto-centering at boot, but sticks can still go anywhere they like, so german77 adds an option to manually center each axis as an additional option. Just right click any direction of a stick in our controller settings.

Just one right click away

Support was added to allow mapping the Enter key , which previously just restarted the mapping process.

toastUnlimited added support for motion inputs to yuzu-cmd, our terminal version of the executable. Terminal warriors can now enjoy some Just Dance too.

Improving emulation to not use emulation

xerpi implemented the 32 bit version of the OutputDebugString, CreateCodeMemory, and ControlCodeMemory supervisor calls. Thanks!

xerpi’s help has a bigger objective in mind than just helping some little-known Switch emulator. They’re developing vita2hos, a translation layer to run PlayStation Vita apps and games natively on the Nintendo Switch! The road ahead is long, since most Switch debug tools are 64-bit only, and the Vita is firmly a 32-bit console, so several rewrites and changes are in order to get the project going.

yuzu lacks some functionality to offer full 32-bit execution mode support, so the PR was opened to help improve that area, since xerpi is using Switch emulators to assist and ease development. We can’t wait to see how this project grows!

Vulkan is the future

With the work on Project Y.F.C and other changes scheduled, we’re slowly aiming for enabling Vulkan by default, and keeping OpenGL in long term support. This section will not list changes in yuzu, but settings users can tweak to improve their Vulkan performance in yuzu and other emulators.

One of the main issues with performance on Vulkan is the aggressive frequency management current GPUs will do to save power. Since the actual 3D load produced by Nintendo Switch games will be very low for even a modern low-end GPU, clock speeds tend to stay on the power saving side of their spectrum.

An easy way to considerably improve performance is to force the GPU to run at higher sustained clock speeds. The highest value the GPU can reach is usually irrelevant here as most GPUs will be faster than a Switch’s Tegra X1, but the sustained clock speed is what will keep framerates high and stuttering to a minimum.

NVIDIA users have a simple single setting in the NVIDIA Control Panel, Prefer maximum performance. You can find this toggle in 3D Settings > Manage 3D settings > Program Settings tab click on Add and select yuzu from the available options, then scroll down to Power management mode and set it to Prefer maximum performance.

Ol' Reliable UI

On the AMD side, this requires a bit of manual work, and may only be compatible with RDNA based GPUs. Only relatively recent Radeon drivers added the option to tune both minimum and maximum GPU frequencies on the included Radeon WattMan. This can disable the warranty of your Radeon product.

What needs to be done, in a similar way to NVIDIA, is to add yuzu as a profile on the Gaming tab, click on Tune Game Performance and set Tuning Control to Custom. Enable GPU Tuning and you will be able to tweak the Min. Frequency (%).

While this can be set globally on Radeon Software, we recommend to use per-application profiles

Besides the GPU, increasing the memory clock speeds will always help in emulation, especially at high resolutions

Using a humble (and worse than mediocre) RX 6500 XT as an example, we can see Pokémon Legends: Arceus increase its framerate up to 73% for free, managing to surpass an RX 570 at ease, simply by raising the minimum clock speed from 500MHz to 2875MHz (a 475% increase, as the next graph shows).

Too much power-saving can also be a bad thing

The performance gains here can be massive, but one can start to see diminishing returns past a certain point.

Future projects

Project Y.F.C. continues to mature as more previously broken games start to become playable. Blinkhawk informs us that he’s currently changing focus to performance. We can’t wait to tell you more!

Fire Emblem Warriors

Morph has a message regarding the progress of Project Gaia:

Poyo!

And german77 has been playing with implementing a Mii editor applet . Current support is pretty barebones, but anyone interested is free to build the pull request and try it.

Sweet home Alabama?

That’s all folks! We thank you for your time, and we hope to see you next month. Glory to Mankind.

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report January 2022

GoldenX86 — Fri, 11 Feb 2022 12:00:00 -0300

What a month we’ve had, yuz-ers. This time, we offer you a plethora of kernel changes, input fixes and new additions, yet more NVIDIA driver fixes, user interface changes, and more!

PSA for NVIDIA users: Part 3

It’s not over yet.

As you know, regular NVIDIA desktop and laptop GPUs don’t support decoding ASTC textures, so yuzu makes use of the compute capabilities of the GPU to parallelize the process. However, the recent release of the 511.XX drivers introduced an issue that affected our compute shader based accelerated ASTC texture decoding.

Crispy (Super Mario Odyssey)

After some investigation, epicboy found that the reason for the bug is an over-optimization introduced by the new drivers (an optimization for one scenario results in issues for another). A small change in behaviour solves the issue . You can find more technical information in the pull request.

Users playing Hyrule Warriors: Age of Calamity or Luigi’s Mansion 3 should stick to the 47X.XX series of drivers, as any version newer than that will have several rendering issues. Don’t fret, we’re investigating the cause!

Abstract art generator (Hyrule Warriors: Age of Calamity)

On the flip side, version 511.65 includes support for the recently released Vulkan 1.3, and improves performance considerably when using said API. Some games show an increase in performance of up to 24%!

A new Legend

Finally, after over two decades, the Pokémon franchise diverges from its tired formula and implements a big change to gameplay in the recently released Pokémon Legends: Arceus.

All this at the cost of graphical fidelity. But hey, there are worse looking games… on the GameCube.

Apart from the disappointing graphics, this game’s release exposed several issues with yuzu, and has even helped us fix long standing issues that affected many more games.

bunnei fixed a deadlock found in the code used to migrate threads among the cores , which caused some noteworthy softlocks present in Pokémon Legends: Arceus.

The problem can be summarised as follows: One thread (thread A) would be waiting for another one (thread B) to release a lock, and conversely, thread B would be waiting for thread A to release another lock, resulting in a deadlock.

Best gameplay change in decades (Pokémon Legends: Arceus)

Moving on from kernel issues, epicboy implemented various GPU changes.

He found that reducing the amount of buffer allocations at the start, rather than only at the end, prevented the game from crashing in certain locations.

Some Vulkan drivers, especially Intel Windows ones, can’t process 64-bit atomic operations (operations that can run independently of any other processes). epicboy adds support in yuzu for unsigned 2x32-bit atomic operations , as that’s the fallback option such drivers use. With this change, the game boots with Intel GPUs running Vulkan.

AMD had a longstanding issue with Transform Feedback in both their official Windows and Linux drivers, causing rendering issues in countless games. While this was recently solved in the Linux AMDVLK drivers, AMD Windows drivers still need to be told which Execution Mode will be in use next.

Explicitly stating to use Xfb Execution Mode before starting to use Transform Feedback solves all issues related to it on AMD Windows Vulkan drivers, not only benefiting Pokémon Legends: Arceus, but also games like Xenoblade Chronicles 2, Xenoblade Chronicles Definitive Edition, Hellblade: Senua's Sacrifice, Donkey Kong Country: Tropical Freeze, POKKÉN TOURNAMENT DX, and many many others.

Pokémon Legends: Arceus

Xenoblade Chronicles Definitive Edition

Donkey Kong Country: Tropical Freeze

Pokémon Legends: Arceus is affected by vertex explosions, exhibiting what looks like textures stretching at random. The bad news is that this is a problem with the Buffer Cache, and fixing it will take considerable time.

The good news is that Blinkhawk, with some help from epicboy, managed to implement a temporary workaround to avoid this problem while a permanent solution starts taking shape. Flushing the buffer before writing saves us from polygon hell, at a minimal performance cost.

Imagine how it looks from space (Pokémon Legends: Arceus)

Mark this the day we start to plan yet another Buffer Cache Rewrite.

As a start, Arceus showed a considerably higher VRAM use than normal, causing 2GB GPU users to crash during cutscenes. Blinkhawk’s solution is to expand the specific direction the buffer cache is increasing , instead of the previous method of doubling the size. This allows 2GB users to play regularly, and 4GB users to be able to scale to 2x without fear of crashes.

Now for some general recommendations:

Having a save from previous Switch Pokémon games will unlock special clothing options after the tutorial.

We measured a slim performance improvement on the (currently) latest 22.2.1 AMD Windows drivers and, as mentioned, a 24% boost with the 511.65 NVIDIA Windows driver. Chad Vulkan 1.3 lending a hand.

Regarding GPU accuracy, while Normal produces the highest performance, High allows for proper particle rendering, so if you want the extra accuracy and have the performance to spare, stick to High.

Effects, particles, and certain attacks seem to render incorrectly at resolutions over native 1x. While we’re investigating the reason for this, it seems to also happen on the Switch itself, so it could just be the nature of these shaders (feels reminiscent of the ghosting in the 3DS Pokémon games.

Thanks Serfrost! (Pokémon Legends: Arceus)

yuzu’s default setting is to run games in OpenGL using GLASM, commonly known as assembly shaders. These settings will cause weird shadow acne on characters, and the solution is to either use GLSL instead of GLASM, or what we recommend, switch to Vulkan altogether.

Broken shadows? Zero! (Pokémon Legends: Arceus)

Users of Radeon GPUs older than the 400 series running Windows will experience crashes due to outdated and out of support drivers. Not even modified drivers seem to help, so the only solution is to use Linux with its still supported, and quite faster, Mesa drivers.

Finally, excessive mod use or high values of Anisotropic Filtering can cause vertex explosions with some GPU configurations. We’re still investigating the cause for this.

Other graphical fixes

Blinkhawk made some changes to the Garbage Collector (GC), which encompasses a number of bug fixes, improving the algorithm to make it clean memory in a smarter fashion, and also making it more efficient for iGPUs.

The value of the minimal, expected, and critical thresholds were rebalanced, so that it does not act as aggressively on GPUs with more memory, while it still performs the job within an acceptable margin for low-memory graphics cards. Additionally, yuzu now queries the size of the GPU memory instead of estimating it, allowing the GC to make better decisions when cleaning it. These changes seek to benefit both low-end and high-end GPUs the most, without affecting either negatively.

Special consideration was put on ASTC textures, which are notoriously heavy on the memory. The GC would clean them too early, causing graphical corruptions on titles that make use of these resources. For this reason, the conditions to determine when to clean ASTC textures were made less strict, which should mitigate the problem in most scenarios.

Although these changes were originally part of the YFC project, Blinkhawk decided to implement these changes now, in order to alleviate the problems related to the previous GC implementation. There is still a lot to come from this project, so please stay tuned for more information in future updates.

Keep in mind, special case titles like ASTRAL CHAIN will still require 3GB of VRAM or more to properly emulate.

On another hand, some titles, such as the Super Mario 64 port (homebrew), would experience freezes in some GPU models (especially iGPUs).

Blinkhawk investigated the problem, and noticed it lay within our Vulkan Scheduler, a class that abstracts the command buffer so it can perform OpenGL-like operations in a Vulkan environment.

As the scheduler manages the order in which it must queue GPU commands before sending them to the device, it is vital that the fencing logic used to determine this is timed correctly.

Previously, the scheduler would only queue command chunks whose type offsets were different from zero. The problem arose because there exists a specific valid type of command whose offset is actually zero. Not taking into consideration this case hindered the fencing logic of the scheduler, preventing it from performing its work properly.

Thankfully, the solution did not require any difficult change, and Blinkhawk was able to mitigate these freezes by submitting a simple patch that addresses this specific problem.

It's-a him! (Super Mario 64 homebrew)

Kernel changes

The code for Memory Management — one of the functions of the kernel — was originally written back in early 2020, based on the information available at the time. Since then, there have been numerous updates to the Nintendo Switch’s operating system, as well as new documentation obtained through reverse engineering.

For this reason, bunnei has been going through each and every part of the code used to manage the memory, focusing on improving both the stability and the accuracy of the kernel.

These changes involved brushing up the memory attribute definitions and permissions , so they match the behaviour of the latest HorizonOS more closely. Most of the code used to map and unmap memory was tidied up , and various functions were renamed to match the official naming. Similarly, the code used to allocate and clear the heap memory was reviewed in this way.

This new implementation should perform better, and also make the code easier to read and navigate.

While investigating the long-standing crashes pertaining to Pokémon Sword/Shield, bunnei found they were related to race conditions.

The first would happen when opening a new session to a service: that is, yuzu would create a host thread (a non-emulated thread), where service session requests can be dispatched to asynchronously. When this session was closed, the host thread for the closing session was being removed from the tracking list at the same time as a new one was added, which caused the race condition.

Services are requested by games when they want to send certain audio to play to the speakers, request certain graphics to be loaded into memory, etc. Pokémon Sword/Shield, in particular, opens and closes LDN service sessions very frequently, which is why it is one of the most affected titles.

By introducing a worker thread to manage the service list , now only one thread will be able to create or destroy service sessions, preventing the crash from happening.

Following this lead, bunnei revisited the code used to exit threads, and found that another race condition occurred, where thread references were being destroyed while they were still selectable for scheduling, resulting in a crash.

The solution was to reimplement the thread termination code more accurately , so that it matches that of the HorizonOS. yuzu now waits for the thread to be unscheduled from all cores before closing it, so that it is destroyed only when it is no longer running.

Another long-standing problem with Pokémon Sword/Shield was related to the code used for the High-Level Emulation (HLE) Service Thread Management.

When a game requests certain services, instead of emulating the internal logic of the Nintendo Switch’s OS (which would be Low-Level Emulation, LLE), yuzu runs an implementation written by the developers that performs the same job on the user’s computer.

These HLE services need to be able to interact with the emulated kernel, in order to grab locks and triggers for rescheduling, etc. yuzu achieves this by making use of dummy threads, which are created as an emulated KThread entity.

A dummy thread is created for every host thread of a service interface running in the user’s computer, so that whenever the kernel needs to interact with a host thread, it can do so through these dummy threads.

Previously, these dummy threads were not being released when their main thread was destroyed, and hence, they would accumulate over time. Since the kernel imposes a limit on the amount of threads a process can make, yuzu was eventually unable to create more threads to open service interfaces in long gaming sessions. Furthermore, these dummy threads could inadvertently be scheduled on the emulated cores, which resulted in a crash, as they are not real threads meant to be run.

After investigating these problems, bunnei implemented various fixes and checks to correct this faulty behaviour, and prevent resource leaks and crashes.

Next, bunnei fixed the KThread counter increment/decrement operations, as the old implementation was incorrect, and could occasionally underflow. This is the aforementioned counter used to keep track of all the KThreads in a process, ensuring the limits imposed by the kernel are not breached.

epicboy also took a look at the kernel, and added a new shut-down method to properly synchronise threads before their destruction. This change fixes a hang that could occur when stopping emulation in yuzu.

UI improvements

In a series of minor changes, a number of contributors decided to improve and correct some elements displayed on our interface, and the way the user can interact with them.

german77 noticed that some items, such as the Stop and Start buttons, were not being disabled from interaction once the emulation process stopped, and promptly fixed this erroneous behaviour .

He also went ahead and implemented the graphical elements needed to report the battery levels of UDP controllers. While this code has been in yuzu’s source for some time already, preparing the appropriate front-end graphics and the subsequent implementation into the UI had been pending tasks for a long time.

Pretty useful for Joy-Cons!

While updating the AMD FidelityFX Super Resolution (FSR) dependency to the latest version, Moonlacer changed the text string to replace the brackets around the Vulkan Only message with parenthesis, for consistency with all the other text in our interface.

In a similar vein, gidoly corrected a series of spelling mistakes in the strings describing the name of commercial gamepads, namely the PlayStation and Xbox controllers.

Based on a Patreon poll conducted in our discord server, gidoly also made the necessary changes to make the Dark Colorful theme the default theme used when running yuzu for the first time on Windows.

v1993 also made changes, so that now using the Colourful theme allows Qt to use the system-wide colours in *NIX systems , instead of forcing dark ones.

Default by popular demand

Naturally, users can still change the theme through the configuration settings, if so desired.

Input changes

german77 has been especially busy this month, so there’s quite a bit to cover in this section.

Users reported that the game パワプロクンポケットR, and other games of the Power Pocket saga, crashed when in-game. This is caused by the SetNpadAnalogStickUseCenterClamp service being able to initialize the applet_resource subsystem even if it wasn’t initialized before. Emulating this behaviour solves the issue and makes some game modes playable . However, some game modes still show that yuzu lacks support for some vertex formats, causing crashes.

パワプロクンポケットR

yuzu will now only display the currently supported controller types in the applet , depending on what each game reports as compatible.

Fullkey is the codename used by Nintendo to refer to a generic type of controller that reports itself as a Pro Controller if you connect an “unsupported” gamepad. This can refer to the GameCube, NES, SNES, N64 and Sega Genesis controllers. In case of problems, the console falls back to reporting a Pro Controller for those types of controllers. german77 added this functionality to yuzu as well .

Support was added to allow devices with only an accelerometer present to act as motion devices . While this means broader support, lacking a gyroscope means very poor results in motion, as some axis movements won’t be registered.

With the help of v1993, german77 fixed the mapping of UDP controllers (any device connected using the cemuhook protocol). Motion now correctly automaps and manual mapping won’t reset the device in the input list.

In a separate PR, by request of v1993, german77 added support for the Home and Touch buttons on UDP connections .

Some motion devices can input very precise values, if the threshold is too high, the motion values will be ignored. Reducing the threshold for gyro data fixes this issue.

While playing Mario Tennis Aces in swing mode, motion could suddenly stop working. This was because the update rate interval for motion data was set too high. Decreasing the motion update rate to 10ms restores functionality .

Also related to motion emulation, the quality and sensitivity of the device can also affect gameplay. As a way to compensate, german77 introduced an option to configure the gyro threshold , you can find it if you have a motion capable controller (in the example, dual Joy-Cons). Configured in Emulation > Configure… > Controls > right click Motion > Set gyro threshold.

Right clicking!

Accessing 2-player mode in Pokémon: Let’s Go Eevee & Pikachu requires performing a shake motion. The emulated shake on the keyboard was too weak to be registered by the game, so increasing its “force” shakes things up to allow local multiplayer.

One of the features missing with the release of Project Kraken, the input rewrite, was mouse motion support. German77 reintroduced support for it , now using the mouse wheel as input for the Z-axis. Also, mouse buttons get their proper names when being mapped.

Another feature that somehow missed the memo was stick modifiers for keyboard input , holding a mapped key to move an analog stick with a reduced limit. For example, with default keyboard mappings, if you hold shift, the left analog stick will move only up to 50% of its range, allowing keyboard users to walk.

We recently introduced controller UI navigation. While comfortable, some users run external programs to translate controller input into keyboard and mouse input. For them, a toggle to disable controller navigation was added in Emulation > Configure… > Controls > Advanced > Controller Navigation.

Couch gamers will love this

By default, yuzu assumes that non-Nintendo Switch controllers, for example the Xbox controllers, will use rumble motors. These are cheaper and use an exponential amplitude curve for their rumble, making this kind of method incompatible for emulating HD Rumble. The DS5 on the PlayStation 5, instead, uses more expensive linear actuators (and needs a linear amplitude curve), like the Pro Controller and Joy-Cons. With this change , german77 extended support to include the official PlayStation 5 controller, the DS5, which is capable of the required precision for HD Rumble.

General changes and bugfixes

TAS scripts can sometimes have errors in them, resulting in yuzu encountering a crash. german77 provides the necessary code to add error handling to TAS scripts , preventing these crashes.

Windows has a nasty, hidden limitation that is the maximum open-file limit a program can use. Some game mods can contain many, many files, going over the previous 4096 limit. Therefore, Morph doubled the limit to 8192 .

v1993 has been working on code cleaning using PVS-Studio, and the results have been great. So far, errors were found and fixed in four separate input related areas , the shader recompiler , and even kernel emulation !

Thanks v1993! Nothing beats cleaner code, especially if it solves out-of-bounds issues.

Morph stubbed the SetCpuOverclockEnabled service (you don’t need to overclock the host CPU on the fly when emulating). This allows Gravity Rider Zero to boot, but nothing is yet displayed on screen due to missing texture format support.

And finally, german77 implemented the 32-bit variant of the supervisor call (SVC) SynchronizePreemptionState , making Espgaluda II playable.

Espgaluda II

Meanwhile, liushuyu updated the dynarmic external submodule, providing optimizations and also fixing compile errors caused by an update of another external, the fmt library — used to format text in yuzu’s log and interface.

german77 also added new hotkeys that allow users to manipulate the volume of the application directly with the gamepad, a feature that will surely come in handy to the people who enjoy yuzu from the comfort of their couch.

By default, Home + D-Pad Right will mute the application, while Home + D-Pad Down will lower the volume, and Home + D-Pad Up will increase it. Users are free to change these mappings through the configuration menu Emulation > Configure > Hotkeys.

The more the merrier!

While working on this change, german77 noticed the equation used to transform from percentage values to “loudness” (i.e. output power) was too aggressive below the 70% mark, making the volume extremely soft in this range. Thus, he decided to modify the formula, so that the transformation is smoother throughout the full range of percentage values.

Old is in red and new is in green. Look at those curves!

Future changes

Progress continues smoothly on our projects in development. For example, german77 is having fun with some heavily requested features. Blinkhawk managed to complete one of the top secret projects Rodrigo left unfinished before turning green, Host Conditional Rendering. Expect to hear more of it in future Project Y.F.C. news.

Now for a small leak of some recent internal testing: Marvel Ultimate Alliance 3: The Black Order jumped from 19 to 51 FPS, and your enemy’s ink in Splatoon 2 works correctly, both changes improving Vulkan.

More than double the performance, for only a few liters of developer tears (Marvel Ultimate Alliance 3: The Black Order)

That’s all folks! It’s always a pleasure to have you here, hope we see you again next month!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report December 2021

GoldenX86 — Tue, 11 Jan 2022 12:00:00 -0300

Yuz-ers! Welcome to the last progress report of 2021, released in 2022 because we still haven’t figured out how to travel back in time. December brought us improved kernel emulation, fixes for driver issues, improvements to input, rendering, overall stability, and more!

We keep trying with the time machine, but we’re running out of bananas to microwave and trash to fuel the Mr. Fusion. Okay, let’s get started!

PSA for NVIDIA users: Part 2

As mentioned two months ago, NVIDIA users have been experiencing issues when using GLSL due to the changes introduced by NVIDIA dropping support for Kepler cards in the 49X series of drivers.

We’re happy to announce that we have a set of workarounds implemented by epicboy that solve all known issues. These are already available for both Mainline and Early Access.

The root of the problem in NVIDIA’s drivers seems to be in negation of integer and floating point values, and bitwise conversions of input values.

On previous drivers, you could assign a value to a variable named x, then assign -x as the value to a new variable named y. y would be equal to -1 * x. New drivers ignore this negation entirely, resulting in random spontaneous fires, security breaches, too many dogs causing a Howl, and total chaos.

The workaround is to simply subtract the value from 0. In our example, y would get the value of 0 - x.

The bitwise conversion issue is more complex, but we talked about it in the past. Back in August, we mentioned how Intel had issues in Vulkan affecting Mario’s legendary moustache.

GetAttribute returns a float value, so a conversion is needed when working with integer values.

The same issue that affected Intel GPUs now happens here on the “greener” side, but inverted. When using instance_id, old drivers accepted a float to unsigned integer conversion without issue, and you could do this conversion multiple times without losing the correct value. The current drivers, on the other hand, can sometimes return zero.

Interpreting the value directly as unsigned integers now solves this issue in both GLSL and GLASM. Since this counts as an optimization, we now apply it to all APIs.

Back to the early days (Fire Emblem: Three Houses)

Please report if you find any issues, as there could be more broken games due to yet unknown driver bugs. On a similar note, more fixes should be coming to Vulkan too, if needed. One such issue solved itself, most likely NVIDIA fixed it on the latest drivers.

Other graphical fixes

Whenever a game played multiple videos at the same time, some of them would glitch and flicker. This happened because yuzu was limited to decoding a single video stream at a time. Having multiple videos running at the same time would cause the decoder to receive frames that were sent from different video sources, confusing the interpolation algorithm and causing the aforementioned problems. To prevent this issue from happening, vonchenplus implemented a temporary solution that gives each video stream their own video decoder, sending the correct frame data only to the correct decoder.

Your browser doesn't support mp4 video. :(

It still flickers, but that's the Chozo's fault (Metroid Dread)

Morph added the missing formats R16G16_UINT and ASTC_2D_8X5_UNORM to the Vulkan API, fixing the missing graphics on Immortals Fenyx Rising and making LEGO® CITY UNDERCOVER playable, respectively. (Please note that Immortals Fenyx Rising gets in game but has broken graphics at the moment).

I brick you not (LEGO® CITY UNDERCOVER)

Blinkhawk fixed a bug in the texture cache that was conveniently ignored by the AMD driver, but would cause Nvidia GPUs to crash when using the Vulkan API. This crash happened when blitting textures with different format types, something that points to a problem in the texture cache that will be addressed in a future PR.

Blinkhawk also updated the Vulkan headers to fix an extension and implemented logical operations. Both the extension and these logical operations are used by Vulkan to describe and process data, in order to compose the frames that will later be sent to the screen. This PR fixes the sand and shadow graphical problems in The Legend of Zelda: Skyward Sword, and also the shadow problems as seen in Xenoblade Chronicles 2.

When you invert the polarity of your HDR display (Xenoblade Chronicles 2)

epicboy took a look at the issues that affected games that made heavy use of sparse GPU memory, and made the changes necessary to mitigate the problem.

Sparse memory is a technique to store data non-contiguously, which is a fancy way to say that data is broken down into small blocks and only the relevant bits are loaded into memory. There was a bug in the code used to map this data into the memory, as the offsets needed to get the right address weren’t being included in the calculations. For the sake of precaution, he also added an extra guard that prevents modifying the memory address 0, as it is used as a placeholder to signal addresses that haven’t been loaded in yet.

These changes are meant to address (no pun intended) issues related to the GPU memory management, and hopefully alleviate some stability complications related to it. Notably, the crashes on titles developed with the UE4 engine (cough, True Goddess Reincarnation V or some such, cough). The devs are still investigating any other oddities surrounding this game, so stay tuned for more updates.

These changes mitigate memory-related problems but are not guaranteed to “fix” them completely (SHIN MEGAMI TENSEI V)

Users reported crashes when playing Sonic Colors Ultimate on AMD and Intel GPUs on Vulkan after the resolution scaler was introduced. epicboy quickly jumped in to intervene and save the Blue Hedgehog.

On the AMD side, Sonic suffers from ImageView issues, causing an invalid pointer dereference when the slot_images container of the texture cache is resized. This can happen even at native resolution. epicboy found that keeping a reference of the container resolves the issue.

Intel’s turn now. The Intel Vulkan Windows driver strongly follows the specification when dealing with image blits. Khronos defines that MSAA blits are not allowed, and while most drivers let this pass, Intel is being a good boy and crashes when trying to rescale MSAA textures. Leaving aside that using traditional antialiasing on a mobile device like the Switch is a crime against humanity (you don’t waste extremely limited bandwidth on traditional antialiasing), the issue is solved by rendering directly into the scaled image when rescaling by using the 3D pipeline. The performance cost is higher (integrated GPUs like most Intel ones also hate traditional antialiasing), but it’s a price to pay to avoid crashing or losing the scaling.

Colourful (Sonic Colors: Ultimate)

The texture cache has to handle several weird situations when dealing with rendering. One aspect of the process is overlaps, when different textures compete for the same video memory space. A bug in the texture cache’s logic was found when an overlap occurs over relatively big distances in GPU memory. An overflow could happen leading to a wrongly massive texture trying to be rendered, causing VRAM to fill up instantly, and leading yuzu to a crash. This issue was common in BRAVELY DEFAULT II. Thanks to epicboy, users no longer have to suffer this sudden crash.

BRAVELY DEFAULT II

Skyline framework: Part 2

itsmeft24 submitted a patch to implement the ProcessMemory and CodeMemory kernel SVCs (Supervisor Calls), which are some of the changes needed to support the Skyline framework for modding.

Part of the ongoing work includes adding support in yuzu for all tiers of subsdk. Games can use subsdk tiers from 0 to 8, with 9 being free. Skyline uses subsdk9 to operate, so jam1garner included support for the remaining two missing tiers in yuzu, 8 and 9.

There are still a couple of things that need to be implemented before it’s ready, but things are certainly getting closer to being completed.

You can check the current progress here.

Input changes

german77 has several fixes for us and some important new additions.

Let’s kick things off with a great new feature for handheld PC users, couch players, and anyone not wanting to reach all the way to their keyboard while playing: support for gamepad hotkeys.

You can customize them

With this, users can customize button macros. For example: access or exit fullscreen, unlock the framerate, pause/continue emulation, capture a screenshot (by default conveniently mapped to the capture button of the Nintendo controllers), close yuzu, and more!

Your browser doesn't support mp4 video. :(

Sorry about the bad quality

When certain games start, some internal testing is done to ensure that things are where they should be and respond with an acceptable delay. One of those tests involves rumble. Games prod the controllers with a low frequency rumble test, but sometimes, some games never stop and the controller continues to vibrate, depleting battery and making you doubt what the original intention of the developer was. german77 forces the rumble amplitude to zero after the test, stopping unwanted vibrations for these affected games.

VR games may use the gyroscope sensor on the Switch itself (not the controllers) to feed motion data. Previously, yuzu would only give partial data to the game, causing erratic movement of the game’s camera. german77 added all missing data, including the gyro sensor, to solve this issue.

german77 also added support for the SetNpadJoyAssignmentMode series of services, removing some spam from the logs. This change also adds support for dual Joy-Con pairs with a single Joy-Con connected, which is something that some games seem to do.

After the release of Project Kraken, the input rewrite, analog triggers were accidentally broken. A simple bug slipped by, causing them to only work when the joysticks were moved. Two lines of code were changed, and the issue was made no more.

german77 has also been working on making Ring Fit Adventure playable. While working on implementing support for the pressure ring accessory that the game requires, german77 also ended up making some global improvements.

One change that ended up benefiting all games is controller type validation, which ensures that the emulator can only accept controller types that the game supports, while discarding and disconnecting anything else.

A bug in the controller type validation code caused Captain Toad: Treasure Tracker to constantly spam the controller applet when trying to launch two-player mode. Well, not any more! Again thanks to german77.

Co-op treasure hunting, what else could you ask for? (Captain Toad: Treasure Tracker)

Flatpak fixes

Following up from our previous mention last month, liushuyu continues to fight against the weirdness of Flatpak.

NVDEC requirements are now more flexible, the CUDA libraries are no longer mandatory, without actually affecting CUDA decoding support. Also, FFmpeg requirements have been raised to version 4.3 and higher. This should enable native Vulkan video support later on when there is driver support for it.

With this, decoding crashes are solved when running Flatpak builds of yuzu.

liushuyu also solved an issue affecting the prevent sleep functionality on Flatpak. Implementing XDP’s Inhibit API solves the issue, preventing the display from turning off at the worst moment while playing.

Additionally, Flatpak builds are compiled with asserts enabled, meaning that the emulator will be stopped when an assertion fails or an out-of-bound access inside a vector is encountered. Appimage and regular Mainline/Early Access builds are shipped with asserts disabled.

While this usually isn’t an issue, Flatpak users reported crashes in Pokémon Sword & Shield when trying to set their uniform number. As it turns out, the on-screen keyboard (OSK) was performing an out-of-bounds access when calling the number pad. Morph pointed the OSK to the proper array and the crashing stopped.

Thank you RodrigoTR for the pic! (Pokémon Sword)

General changes and bugfixes

bunnei continues to work on the kernel rewrite, toiling away to increase the accuracy of our implementation.

This time, by simplifying a number of functions and polishing the tracking of resources, he introduced more changes to improve the threading and scheduling kernel routines. These changes increase yuzu’s parity with recent updates to the Nintendo Switch OS, and also fix a number of race conditions and crashes, such as the ones experienced in Pokémon Sword & Shield and Dead or Alive Xtreme 3 Scarlet.

bunnei also implemented SetMemoryPermission, and updated the implementation of SetHeapSize, which are SVCs used by the kernel to manage the memory resources.

Previously, SetHeapSize only supported setting the heap size and expanding it, which was good enough for most games. But since some titles (such as Donkey Kong Tropical Freeze) may shrink this size, the implementation was updated to allow games to change the heap as needed, making it more accurate.

Both these changes were validated with hardware tests, ensuring that they behave as expected.

While working on these changes, bunnei found a bug in the service used to retrieve information of the currently executing process. Correcting this behaviour allowed The Witcher 3: Wild Hunt to boot, although there are still plenty of graphical issues to fix on this title.

Blinkhawk also made a number of changes to the building process to enforce more link time optimizations, and improve the time needed to generate the PDB (Program Database) file, which contains debug information. If this mumbo-jumbo sounds confusing, the gist of it is that the process of building yuzu should produce more efficient code and smaller binaries now. But feel free to skip the following few paragraphs if you’re not interested in the specifics.

Roughly speaking, compiler optimizations work on a “local” level per object. This optimization step will inline some functions, merge loops, put calling and called functions close in memory for better caching, etc. But if a function defined in another file is called within the file, the compiler can’t perform these optimizations, as it doesn’t know what this external function does, or how to optimize it.

Link time optimizations, on the other hand, take into consideration all the functions in the project. The linker, thus, is able to perform the same optimizations as the compiler, but more efficiently, as it is aware of the contents of all the functions defined in the project. This comes at a price, since the process needs more memory and takes more time to finish, but it guarantees that the released binaries perform better.

Along with this work, we considered enforcing SSE4.2 support, improving performance but making yuzu incompatible with 12 year old CPUs like the Core 2 Duo and Phenom II or older. While the performance results were positive, we are still debating whether we should reduce CPU compatibility or not.

When you open yuzu, the emulator has to take some time to measure the RDTSC frequency, a way to measure the clock speed of the CPU. Due to a bit of bloat in the previous implementation, 3 full seconds were needed to complete the operation. Morph rewrote the whole function and now only 0.2 seconds (200 milliseconds) are needed to get results as accurate as before, considerably reducing the boot times of the emulator itself.

As previously stated, german77 continues to work towards making Ring Fit Adventure playable. He has stubbed the SetNpadCaptureButtonAssignment, ClearNpadCaptureButtonAssignment, ListAlarmSettings, and Initialize services, and added support for the notif:a service.

With all his changes, the current Early Access build (at the time of writing this article) can boot and play the first stage of the game!

Your browser doesn't support mp4 video. :(

Ring Fit Adventure

Tatsh added NSP and XCI file association to Linux. Thanks!

Tachi107 updated cubeb and removed now deprecated functions. Cleaner is always better, thanks!

heinermann fixed a crash that would occur when the emulation was paused and the window was out of focus. Thank you!

jbeich changed the building configuration so that VA-API, one of the video decoding APIs of Linux, is enabled on Unix systems, allowing the users who want to build targeting BSD or other Unix-based systems to use hardware acceleration for video decoding.

This is just one of several PRs jbeich wrote to help yuzu work on BSD systems, thank you for your contributions!

UI changes

The favourites row in yuzu’s game list was always expanded, even if the user collapsed it. epicboy added a persistent setting to remember the user preference between launches.

One of the most common issues users face is lack of Vulkan support on their PC. Not lack of hardware support, but instead missing software support caused by outdated GPU drivers or poorly coded/outdated Vulkan injections.

Our old error popup didn’t reflect this so your writer, with his total lack of coding skills, decided to improve it.

This is a complex issue and the main reason Vulkan is not yuzu’s default API. Users of old laptops with AMD and Intel integrated GPUs tend to use the driver shipped by either the laptop vendor or Windows Update. In both cases, those drivers are most likely years old (yuzu can run on AMD GPUs from 2012) and either lack Vulkan support at all, or only support a portion of what’s needed to run yuzu. Also, since laptops, by default, connect the display directly to the integrated GPU, that’s the first Vulkan driver that will be seen, so it’s critical to have the latest GPU driver installed even if your laptop has a dedicated NVIDIA GPU running the latest driver.

While telling AMD users to manually download and install updated drivers is a viable option and works as it should, in its infinite wisdom, Intel decided to block manual installation of its own official drivers if a custom laptop vendor driver is in use (those modified drivers are usually created to cheat on battery life metrics and/or to save money on cooling).

The only alternative in those cases is to manually download the ZIP version of the driver > unpack it > Launch the Device Manager > right-click the correct GPU in Display Adapters > select Update Driver Software… > select Browse my computer for driver software > select Let me pick from a list of device drivers on my computer > select Have Disk… > then finally browse to the folder where the driver was unpacked and select the iigd_dch.inf file. What a very intuitive and user-friendly way to update a GPU driver… great job Intel.

Here’s a video tutorial for those that prefer visual aid over our rambling. Just make sure to use the iigd_dch.inf file instead of the one shown in the slightly outdated video. Other mentioned optimizations on the video no longer apply.

With this easy job done, the Intel GPU gets full Vulkan support, runs at its intended performance, and has access to all the new features, fixes, and performance improvements that the driver developers worked on. The driver is also allowed to auto-update on new official releases.

Known software that uses broken Vulkan injectors are outdated screen recorders like Bandicam, Action!, and even OBS. We strongly recommend using an up-to-date OBS, the native encoders from the GPU vendor (Radeon ReLive and Geforce Experience), or the integrated Xbox Game Bar on Windows. Overwolf and GShade are also known to break Vulkan support, so we strongly recommend avoiding them.

Future projects

Project Gaia is progressing smoothly. Heads up, SSD users will notice improvements once it is released.

Blinkhawk informs us that Project Y.F.C. will be released in smaller chunks in order to push more progressive updates instead of delaying for a big release that would require more testing time. We want to get these updates in your hands as soon as possible! We continue to plan to add several GPU features that have been pending. Here’s a screenshot as an example:

Mario Golf: Super Rush

That’s all folks! Thank you for your attention, and we hope to see you next month!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report November 2021

GoldenX86 — Fri, 10 Dec 2021 12:00:00 -0300

Hello yuz-ers! Welcome to November’s progress report. This month, we present to you a full input rewrite, UI navigation with controllers, kernel changes resulting in improved stability, and more.

Project Kraken

Oh boy, what a treat german77 has for us. As we mentioned in the previous progress report, Project Kraken, our latest input rewrite, is now available to all users.

But what does it mean? Well, Kraken has multiple goals — first of all is accuracy. Behaving closer to how the Nintendo Switch operates is our goal. Secondly, simplifying and removing old redundant code makes maintenance and scalability a lot easier. And most importantly, making all input event-based instead of polling-based. This means that instead of asking the controller what it did at regular intervals, the controller itself will report its actions the moment the user inputs an action. This applies to buttons, triggers, sticks, motion — the whole deal. The end result is reduced input lag.

But those aren’t the only improvements, Kraken also includes many bug fixes and new additions. Users can now invert or turn any button into a toggle (press again to release) in any emulated controller. Previously this was only possible on a limited variety of controllers.

Did someone say they wanted to beat Dark Souls with a driving wheel?

Buttons are named instead of numbered on non-SDL input controllers, assisting with identification.

SDL input, like native Nintendo controllers or Xbox controllers, will have numbered buttons rather than named

While we recommend using controllers without third party drivers, full UDP Cemuhook support is available at Emulation > Configure… > Controls > Advanced > Enabled UDP controllers.

Previously, Cemuhook was only used for UDP motion, but now even Android apps can connect to yuzu. Cemuhook provides a guide on how to set up UDP devices here.

There must be someone trying to play with a phone as a Joy-Con somewhere

Keyboard and mouse emulation is improved, allowing games that natively support USB mouse and keyboard inputs to function correctly.

Useful in games like Animal Crossing: New Horizons that accept an actual keyboard on the Switch

Additionally, there are hundreds of bugfixes in the backend. To list a few:

Dual Joy-Cons will now correctly reconnect instead of reverting to “any” input after a yuzu reboot.
Analog triggers are properly mapped (this includes Gamecube controllers).
Configuration parameters are shared on all emulated controller types.
Battery level is now informed when available.
Pressing a button will automatically reconnect the first player.
Rumble on the right side is fixed.

For those interested, the pull request description includes all the technical information on how Kraken now operates, including the internal changes to every subsystem.

Subsequent pull requests by Morph and german77 provided further fixes and cleanups. For example, in the past yuzu would determine automatically if the controller applet needed to pop-up, removing an annoyance in single player games. Kraken shipped with a bug causing the controllers to remain in configure mode, awaiting an applet that never came up. german77 corrected this behavior to enable the controllers in such cases.

Other input changes

A highly requested feature is controller navigation over UI elements, and that’s exactly what german77 delivered. Currently there is support for the game list and profile selector (if the user created several profiles). The feature is in its baby steps, so expect some rough edges. For example, when in the controller applet or when trying to hold the stick. We are currently working on refining it.

Here’s an example on the GPD Win 3:

Your browser doesn't support mp4 video. :(

Steam Deck hype train, here we go!

When asking for the character’s name in Famicom Detective Club: The Missing Heir, the game generated an error in Chinese and then crashed. The issue is rooted in a bad behaviour in how text is handled with the On-Screen Keyboard (OSK). There’s no need to ask for user confirmation on text that has been already confirmed. The resulting error message was corrupted due to using the wrong character encoding. Morph addressed both issues, and the game can be played now.

Elementary, my dear yuzu (Famicom Detective Club: The Missing Heir)

german77 got tired of having to constantly modify the code when testing different types of unsupported controllers, so he added a toggle to allow them. We don’t recommend enabling this setting for normal gameplay, but if anyone wants to try it out, the option is in Emulation > Configure… > General > Debug > Enable all Controller Types.

Graphical fixes

One of the missing video formats was VP8. We didn’t implement it until now because there were very few known games that used it. There are at least 3 known games using VP8 at the moment: TY the Tasmanian Tiger HD, Diablo II: Resurrected, and Pokémon Brilliant Diamond/Shining Pearl. Thus, epicboy attacked his keyboard and implemented VP8 support into yuzu. However, there are known issues with Pokémon VP8 decoding that we’re working to address.

Your browser doesn't support mp4 video. :(

Cue the fanfare (Pokémon Shining Pearl)

Textures can be divided on colour or depth formats, but everything changed when the TCR attacked.

In OpenGL, a conversion method was missing for copying “incompatible” texture formats, like colour <-> depth format copies. epicboy worked around this limitation by using the same method implemented in BGR <-> RGB conversions that we’ve mentioned in the past.

Countless glitches were fixed, two notable examples being the shadows in Luigi’s Mansion 3 and the cutscenes in Bayonetta 2.

Your browser doesn't support mp4 video. :(

You can now focus on... gameplay (Bayonetta 2)

Your browser doesn't support mp4 video. :(

No more ghost shadows (Luigi's Mansion 3)

With the release of Pokémon Brilliant Diamond/Shining Pearl, a Unity engine game, and SHIN MEGAMI TENSEI V, an Unreal Engine 4 game, we realized how much work needs to be done to solve stability and rendering issues affecting both engines. Since we don’t have that many GPU developers available (especially in finals months), we can only focus on one thing at a time, so first, Unity.

Blit detection suffered some regressions with the introduction of the resolution scaler, Project ART. Blinkhawk fixed them and added texture format D24S8 to RGBA8 conversions to Vulkan, fixing several crashes affecting both APIs in this new Pokémon remake.

Morph later included some more fixes for this pull request.

Another issue affecting Pokémon Brilliant Diamond/Shining Pearl is an interesting corruption that can happen in battles and in reflections after some time, or with certain attacks that cover the whole screen. By replacing the old “format deduction algorithm” and instead utilizing full depth conversions, Blinkhawk fixed this colourful bug.

What a trip, almost like a Disney song (Pokémon Brilliant Diamond)

One of the (many) missing texture formats is S8_UINT, an 8-bit stencil texture. Morph used a homebrew unit test to verify he was making progress. Baldur’s Gate 1 and 2 and Citizens of Space make use of S8_UINT, but as both games need other formats that are still missing and other fixes, they weren’t very helpful in testing.

While there is support for S8_UINT in both OpenGL and Vulkan now, NVIDIA is the only vendor to specify support for the format in Vulkan, meaning that any affected game running on an AMD or Intel GPU will need to stick to OpenGL to get proper rendering.

Testing homebrew

vonchenplus found a bug where image creation would include width size restrictions that wouldn’t apply to later updates and downloads, causing OpenGL to spam errors. Properly handling those cases allows the driver to calm down. Proper and cleaner code can also mean less driver overhead.

Continuing with the implementation of unsupported formats, vonchenplus added R5G6B5_UNORM_PACK16 textures to Vulkan and S8_UINT_D24_UNORM globally. Again, just like S8_UINT, AMD and Intel hardware lack Vulkan support for S8_UINT_D24_UNORM.

vonchenplus also converted all uses of legacy attributes within shaders into generic attributes, since they were not supported by some graphics drivers, improving compatibility.

These four changes improve DRAGON QUEST BUILDERS, but more work is required to make the game playable. If you’re interested in testing this game, use Vulkan, or disable Asynchronous GPU Emulation when using OpenGL. Beware, crashes may occur.

Missing graphics make the game not an optimal experience for now (DRAGON QUEST BUILDERS)

Let’s go back to the topic of fixing issues introduced by the resolution scaler. Users reported that taking screenshots at the 1x resolution multiplier resulted in saved images with a size higher than the rendering resolution of the game. A mix up resulted in the screenshot being saved at the window size instead of the game’s framebuffer size. epicboy fixed the logic and we’re back to proper screenshot resolutions.

liushuyu, our fantastic Web Admin, received reports of systems with multiple GPUs experiencing crashes while running the Flatpak version of yuzu on Linux. It seems like the bundled version of mesa and ffmpeg will not work on systems with different GPU vendors. This is caused by Flatpak’s built-in ffmpeg lacking support for NVDEC and VDPAU on NVIDIA hardware, and having broken codec detection. Just your average GNOME, who manages both Flatpak and FlatHub.

liushuyu submitted two separate pull requests addressing this problem, but more edge cases continue to appear, so the battle isn’t over yet.

While we continue to work towards winning this war on Flatpak issues, please stick to using our AppImages, or manually building yuzu. If you prefer to manually build yuzu, make sure that your ffmpeg library is capable of decoding VP8, VP9, and H.264 on hardware. It seems like the only way to solve this problem will be to just ship our own ffmpeg instead of Flatpak’s default version.

UI changes

MightyCreak has been working on changes in behaviour to the default light theme. Previously, yuzu would ignore the system wide theme, sticking to a light palette even if the system switched to a dark one. Renaming the Light theme to Default, and allowing it to match the behaviour of the system theme, makes for a more streamlined user experience. At the moment, this behaviour only works correctly on Linux, Windows’ Qt doesn’t yet support system wide themes.

Yours truly (GoldenX86) decided that the previous missing keys error screen wasn’t clear enough and fixed it right up, short and sweet.

For some reason, people seem to forget what hyperlinks are for

While working on the resolution scaler and its included filters, Blinkhawk named FSR AMD'S FIDELITYFX SR on the bottom status bar. As this was a bit too long, Morph renamed it to simply FSR. Small change, but more pleasing to the eyes.

Better, don't you agree?

Kewlan implemented a very nice addition for high refresh rate users. With the introduction of the FPS unlimiter that players can toggle by pressing Ctrl + U while in-game, a cap was introduced in the configuration to allow setting a multiplier of the native framerate as the upper limit.

For example, if a game runs at 30FPS, and the user wants to limit it to 120FPS to better match the maximum refresh rate of their display, a 4x multiplier would be needed. A 2x multiplier if the game runs at 60FPS natively.

The problem with this approach is that as shown in the example, different games will run at different framerates natively, so a global value isn’t ideal. Kewlan added support for framerate caps in the custom configuration and users can access it by right clicking a game in yuzu’s list and selecting properties. This way, the user can set their preferred cap on a per-game basis.

If you buy a new display, remember to manually increase the refresh rate!

If the user wants a value that isn’t a multiple of the native framerate of the game, they can use software like MSI Afterburner to specify a custom limit.

There has been some extensive work to improve hotkeys.

v1993 received a report that yuzu’s window will flicker if the user holds the Esc key when trying to exit fullscreen. That won’t happen any more.

german77 discovered that holding a hotkey would constantly spam the input. This was unintended, so he ensured this behaviour was no more.

heinermann modified the Menu bar as follows:

In Emulation, the Start button has been removed and Continue will now say Pause when applicable and vice versa. Restart will no longer cause a crash. In File, the Load Amiibo... hotkey was fixed. We still have issues with several games when using this function, so consider it in a beta state. TAS received its own submenu in Tools > TAS. And in exciting news, Exiting the emulator will now work while in fullscreen!

Kernel fixes

Morph fixed a compilation warning in the kernel SVC::WaitSynchronization, where the parameter num_handles was wrongly declared as an unsigned integer when it was actually a signed integer.

heinermann discovered a bug in the kernel that crashed yuzu upon exiting.

This happened because dummy threads in the kernel weren’t getting destroyed properly. When yuzu was exited during emulation or after stopping emulation, these threads stayed alive even though the kernel got destroyed, thus causing yuzu to crash.

By making the kernel own these threads, we ensure they get destroyed when the kernel gets destroyed, mitigating the crash.

OatmealDome fixed a bug that caused some homebrew to not boot. The fix was to pass default threadinfo when the kernel creates a thread, allowing homebrew to boot.

Skyline framework, Part 1

itsmeft24, jam1garner, and Morph started working on adding support for the Skyline modding framework. This will allow for more intricate code mods, such as using ARCropolis, a mod loader for Smash Ultimate made by Raytwo and blujay.

All these PRs [1], [2], [3] are part of the on-going effort to implement support for the modding framework in yuzu.

There are more juicy additions, but they didn’t make it in time to be mentioned in this article, we will continue to expand on Skyline’s progress in December’s report. See the current progress here.

General changes and bugfixes

Not much to talk about in this section this time, mostly just service stubs and implementations.

Animal Crossing: New Horizons takes the spotlight with 4 stubs to make the new 2.0.0 update playable. Thank you, german77 and Morph.

german77 also provides Just Dance 2022 with its own stub for the EndFreeCommunication service.

And finally, Morph implements the GetCompletionEvent service for Super Bomberman R Online. However, as the game requires online services, it won’t be playable for now.

Future projects

Project Gaia continues to progress and is receiving optimizations as we speak. We’re not that far away from starting internal testing on it.

That’s all folks! As always, thank you so much for your attention, and we’ll see you next time!

Special thanks to RodrigoTR and PacoA for their provided media.

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report October 2021

GoldenX86 — Sat, 13 Nov 2021 12:00:00 -0300

Hey there, yuz-ers! We’ve had quite an exciting month. Our most anticipated and highly requested feature, Resolution Scaling, is finally out! But we didn’t rest on our laurels, a host of other fixes were pushed this month and we can’t wait to tell you all about them!

PSA for NVIDIA users

Before delving further, we want to remind NVIDIA users that there are issues with the latest graphics drivers, specifically the 49X releases.

Past the last 472.XX drivers, NVIDIA removed support for Windows versions prior to 10 and the Kepler series of GPUs (mostly 600 and 700 series cards). Additionally, OpenGL GLSL and Vulkan rendering were affected, with GLSL becoming virtually unusable and Vulkan exhibiting minor glitches.

While NVIDIA works to resolve the issues, and we work on alternatives to mitigate the problems, we’ve configured NVIDIA GPUs on affected drivers to only use GLASM when OpenGL is selected. This seems to workaround most of the GLSL errors we’ve been seeing on these latest drives. Thanks to toastUnlimited for the quick update.

GLSL will still be available for version 472.XX and older drivers. If someone wishes to use GLSL on recent 49X series drivers, turn on Enable Graphics Debugging in Emulation > Configure… > General > Debug. Keep in mind this will reduce performance, as it is only intended for debugging.

With the PSA out of the way, let’s get into the good stuff!

Project A.R.T.

Advanced Rendering Techniques or was it Aristotle’s Rescaling Technology? I think there’s another name I’m forgetting. Maybe the Pull Request will have more information for those curious.

Anyway, Project A.R.T. is out in the wild! Blinkhawk, BreadFish, epicboy, and Rodrigo are to thank for this incredible release.

As explained in its dedicated article here, this is a complete rewrite of our old resolution scaling implementation from 2019. Before we jump into the end-user benefits, let’s first cover some terminology. The correct terms for the scaling process are Upsampling and Supersampling, which can also be more commonly called Downsampling. In layman’s terms, downsampling means taking a big frame and reducing its size to fit a smaller display. Downsampling is rendering the game at a higher resolution than your display’s native one.

In contrast, upsampling means taking a smaller frame and stretching it to fit a bigger display. It results in a lower quality image, but users with low-end GPUs, particularly users of integrated graphics, may prefer to have better framerates over image quality.

A work of art (read left to right)

There seems to be a lot of confusion about this. Remember, improving the visual quality of the game is downsampling, not upsampling. Games look their best when they have a 1:1 ratio between rendering and display resolution, or when downsampling.

With that out of the way, let’s get started. All new options can be found in Emulation > Configure… > Graphics

yuzu Graphics configuration window

Starting with Resolution, this option is the Scaling Multiplier being used. It will double the width and height of whatever resolution the game is rendering at. At the moment, we offer two upsampling multipliers: 0.5X and 0.75X, and five downsampling multipliers: 2X, 3X, 4X, 5X, and 6X.

Here’s an example, Super Mario Odyssey displays a 1920x1080 frame in docked mode but actually renders at 1600x900, and at 1280x720 in undocked mode. Applying a 2X resolution to Super Mario Odyssey gives us a rendering resolution of 3200x1800 in docked mode and 2560x1440 in undocked mode. 3X would give us 4800x2700 and 3840x2160 respectively, 0.5X would be 800x450 and 640x360, and so on. Keep in mind that games can reduce graphical details in undocked mode, not only their resolution.

With high resolutions comes increased texture sizes. This has a significant impact on both video memory (VRAM) and other available graphical resources, like memory bandwidth. The user must consider the available VRAM and the performance of the GPU they are using when deciding which resolution multiplier to use. For integrated GPU users, RAM overclocking becomes critical, as faster RAM means faster “VRAM” for your iGPU.

If the GPU runs out of VRAM faster than the emulator or graphics driver can manage resources, yuzu will close, so follow our recommended values in the picture below.

We recommend 2GB and lower users to use 1X on graphic intensive games

Small, low-end GPUs (like our recommended GT 1030, RX 550, or any integrated GPU) will see considerable performance benefits when upsampling as the reduction in 3D load and the lower VRAM utilization will provide higher framerates.

People with current mid to high-end GPUs can benefit from the surplus of computational capabilities and available VRAM. Actual performance will be determined by each specific game, but it’s safe to assume that good hardware can use a 2X or 3X multiplier with little issue most of the time. We personally don’t recommend going higher than 3X as not even the best consumer hardware available at this moment can provide a perfect experience when rendering at very high resolutions, but the options are there to experiment with.

Light or very well optimized games like Super Smash Bros. Ultimate and Metroid Dread can make for great experiences on 4K or 8K displays. On the other hand, particular games like Astral Chain should not be downsampled, as they already use 3840x2160 textures. Trying high resolution multipliers with games like this will result in your GPU’s VRAM not being very happy.

We strongly recommend using Vulkan for downsampling as VRAM use will be considerably lower as compared to OpenGL.

Let’s move on to the second option, Window Adapting Filter.

When using a display with a different native resolution than your rendering resolution, you need some way of deciding which pixels will be shown in the final image. Filters are used for that!

Currently, yuzu offers 6 filtering options, each recommended for different scenarios, and with different performance costs. We plan to expand this section in the future, adding sliders to let users customize the filters to their own tastes. And yes, on GPU limited scenarios, the filter in use can affect framerate.

Tested on Mario Kart 8 Deluxe, filtering ain't free!

While an integrated GPU will suffer the performance cost, even a low-end dedicated card will handle the increased computational load with ease.

Here are some recommendations and comparisons of all current options against the default bilinear filter.

Nearest Neighbor is ideal for pixel art style games like UNDERTALE or OCTOPATH TRAVELER, it can also provide the best results when the game’s rendering resolution matches the window or display’s resolution. It and Bilinear have the lowest performance cost of all the options.

OCTOPATH TRAVELER (Bilinear Vs. Nearest Neighbour)

Bilinear is our combat tested default option. It’s very good for downsampling and like Nearest Neighbor, it has almost no performance cost. It’s a great all-rounder. If you have a 1080p display, we recommend Bilinear with a 2X resolution multiplier.

Bicubic can produce better downsampling results than Bilinear, but at a slightly higher performance cost. We recommend it for 2X or 3X multipliers on 1080p displays.

The Legend of Zelda: Breath of the Wild (Bilinear Vs. Bicubic)

Gaussian is intended for extreme cases, like when the user wants to test a very high multiplier. It also has a high performance cost. When very high values are used, the image can, ironically, start to become pixelated again. The gaussian blur produced by this filter will help provide a more pleasant image. Recommended for 4X to 6X multipliers on 1080p displays.

Metroid Dread (Bilinear Vs. Gaussian)

Scaleforce was invented by BreadFish. It is a great downsampling filter for 3D games and a fine upsampling filter for 2D games, while also only requiring a moderate performance cost. A true jack of all trades.

OCTOPATH TRAVELER (Bilinear Vs. Scaleforce)

AMD Fidelity FX™ Super Resolution, or FSR for short, is in AMD’s own words “…an open source, high-quality solution for producing high resolution frames from lower resolution inputs.”

This means that it is particularly useful for low-end users trying to restore some of the missing details lost when upsampling a game to gain performance. It is NOT recommended for downsampling, as the output resolution is used as part of the process. A perfect pick for people forced to run 0.5X or 0.75X multipliers for performance reasons.

Super Mario Odyssey (1X Bilinear Vs. 0.75X FSR)

If the user tries FSR while downsampling, they will be reducing image quality and will end up only seeing the sharpening aspect of the filter, negating any advantage of increasing the rendering resolution while incurring the full performance cost of it.

The Legend of Zelda: Link's Awakening (2X Bilinear Vs. 2X FSR on a 1080p display)

So, in short, if the rendering resolution is higher than the display’s resolution, FSR should be avoided. If the rendering resolution is equal or lower than the display’s resolution, FSR is an excellent shader-based filtering option, but with the highest performance cost on the list.

As a way to cheat around this limitation, AMD and NVIDIA Windows users can fake higher display resolutions with the use of Virtual Super Resolution and Dynamic Super Resolution respectively. This way, for example, a 1080p display can fake a 2160p (4K) maximum resolution, giving FSR a lot more information to play with.

The Legend of Zelda: Link's Awakening (2X Bilinear Vs. 2X FSR on a 4K display)

Finally our current last option, Anti-Aliasing Method. Pixels are almost squares and squares aren’t great for displaying curves. Anti-aliasing methods are used to smooth out this undesired effect. At the moment we only offer FXAA, which can help reduce the excessive sharpening shown when using FSR. In the near future, we plan to add more options like MLAA/SMAA

Luigi's Mansion 3 (FSR Vs. FSR + FXAA, both on a 4K display)

Both the filters and anti-aliasing options can be changed while in-game using the buttons on the bottom left of yuzu’s window. Changing the resolution multiplier in-game is not possible at the moment.

As an additional note, A.R.T. also reimplements our Anisotropic Filtering! This option can be accessed from the Advanced tab in the graphics settings. In the past we recommended skipping this option as not all games are particularly fond of forcing values higher than they specified, but this new implementation is smarter, avoiding previous drawbacks.

At a low performance cost, it will increase the quality of textures at oblique angles, particularly ground textures, most noticeable in first and third person view games. It should now be safe to set at 16x and forget about it.

Pokémon Sword (default Vs. 16X Anisotropic Filtering)

One last note, AMD users should ensure that Radeon Image Sharpening is disabled before using the scaler, as it can affect the quality of some filters, especially FSR which includes its own sharpening already.

At the time of writing this article, Resolution Scaling remains in Early Access for testing and regression finding, but be sure that it won’t take long to be merged into Mainline. Check the progress in the pull request previously listed, code review is usually the main reason for delays on merging.

Graphical and general bugfixes

Metroid Dread has been a very important release both for the series and for the console, giving us the first main entry for the series in years.

This game is heavily optimized and well polished all around, part of that is thanks to using very clever tricks to render. Dread doesn’t shy away from using pre-rendered videos for backgrounds, displays, manuals, and the intro menu. Such videos were using an unsupported frame format, RGBX8, which epicboy implemented.

There's no need to introduce more dread into this game (Metroid Dread)

While this solves the rendering of a single video on screen, some areas of the game can play multiple streams simultaneously, causing glitches on screen. yuzu’s decoding needs to be improved to handle those cases, something we’re still working on.

While Blinkhawk was working on Project A.R.T, he also doubled the counter of cached pages in the rasterizer.

yuzu uses these counters to keep track of the number of GPU objects stored in a cache within a CPU page. Previously, this counter would account for pages whose addresses were up to a size of 38 bits. Some games, however, can use memory addresses of up to 39 bits.

By doubling the counter, the rasterizer can effectively keep track of these addresses now, allowing certain games that did not work with the old counter to boot, such as Final Fantasy X.

Listen to my story, the story of the worst laugh ever recorded (FINAL FANTASY X/X-2 HD Remaster)

epicboy investigated the graphical issues present in Mario Party Superstars. Following the lead from this initial research, Blinkhawk found the problem and submitted a patch that improves the performance of the backtracking algorithm used by the shader cache to find the handlers of a bindless texture.

Old school minigames are the best (Mario Party Superstars)

yuzu’s window can be freely resized, but users may want some presets to return things to accurate 16:9 proportions. In the past we offered 720p and 1080p options, but now epicboy adds a 900p option, useful for both people with 1080p displays wanting some free space on their screen, and for getting a 1:1 ratio on 3D games that render natively at 1600x900.

A simple way to make good use of nearest neighbour

Blinkhawk has been investigating an issue affecting Catherine: Full Body, Hyrule Warriors: Definitive Edition, and an unknown number of other games.

NVN, the graphics API most Nintendo Switch games use, will skip fences (ways to synchronize rendering) if a certain amount of time has passed. This is a sensical design choice on native hardware, where a long wait could mean a TDR from a malfunctioning game or faulty hardware. In the emulator, on the other hand, long wait times can be caused by shaders being built, textures being downloaded or uploaded, background processes hogging the system, etc.

If those delays are not taken into consideration, games can experience graphical glitches and bad frame pacing. The solution is forcing the GPU to wait until the system responds with all tasks finished.

Almost a Nice Boat protagonist (Catherine: Full Body)

vonchenplus is back with more fixes! This time a couple of stubs helping in-game stability or rendering.

Stubbing IHOSBinderDriver::TransactParcel and GetBufferHistory help to boot Luigi’s Mansion 3, which is notorious for refusing to load at random. While this helps mitigate the issues, they are not fully solved. It seems the small delay introduced by shader building can affect the stability of this game too. We need to investigate this issue further.

It’s time to add some love to yuzu-cmd again, our command line alternative to the default Qt-based yuzu. toastUnlimited added the option to select the network interface to use, providing LAN support to terminal-loving users.

Some videos in Touhou Genso Wanderer -Lotus Labyrinth R- and Tsukihime -A piece of blue glass moon- would render completely black. v1993 figured out the cause of the problem, which happened because the height of the video frame that needed to be decoded was smaller than the surface where it was supposed to be drawn upon. In order to avoid writing outside of bounds, there is a check that ensures these two dimensions are equal, or it will not draw the frame. v1993 changed this check to allow the surface to be higher than frame, so that videos with this issue can render their frames.

But this was a transient solution, as epicboy later addressed the problem by implementing a general solution that uses the minimum between these two sizes when writing the decoded image into the GPU, while keeping the aforementioned check in place to ensure no out-of-bounds memory is compromised.

These changes affect all titles with size disparities, allowing them to render their videos even if the height of the frame and the surface differ by a couple of pixels.

Your browser doesn't support mp4 video. :(

That piano really hits with nostalgia (Tsukihime -A piece of blue glass moon-)

Speaking of good music (Touhou Genso Wanderer -Lotus Labyrinth R-)

epicboy also made changes to the SPIR-V emitter, so that implicit LOD sampling behaves the same way as the hardware on all GPU drivers during non-fragment stages of the pipeline.

It is possible to specify how detailed things can appear on the screen based on the LOD (Level of Detail). So, for example, objects further away from the camera will use lower-quality textures, saving computation power and also preventing other problems, such as Moiré patterns. The programmer is able to specify in the shader whether they sample from the original texture (level 0), or from these lower-quality textures (level 1, 2, 3…, etc.). In case the LOD isn’t specified in non-fragment stages of the pipeline (i.e. implicit LOD sampling), the LOD level is considered zero in the Nintendo Switch. Since other GPU drivers don’t necessarily behave this way, epicboy simply ensured that this always happens.

While this change doesn’t necessarily translate as a performance or graphic improvement, it guarantees the code ran among different GPU vendors matches the behaviour of the console.

Morph updated the dynarmic external dependency to use the CPU cache invalidation fixes submitted by Blinkhawk to perform ranged invalidations when unmapping code memory.

Memory usually gets invalidated when unloading from memory NROs (Nintendo Relocatable Object), which are dynamic libraries utilized by a variety of titles. These changes should alleviate (but not completely solve) the crashes that occur when titles swap NROs in-and-out of memory, such as the case of Super Smash Bros. Ultimate.

Some games would crash if the user had a profile picture set in yuzu. german77 discovered that this happened when the image’s dimensions were greater than 256x256. To avoid the crash, he made it so that yuzu now resizes big profile pictures to fit the allowed dimensions instead.

On Linux, opening the Configuration Window and pressing the OK button would lead consistently to a crash. MightyCreak found the cause of this problem and submitted a patch to solve it.

Another linux-only crash would happen when inputting text on The Legend of Zelda: Breath of the Wild. Morph investigated the problem and found it was caused by an out-of-bounds access in the string buffer, so he added the necessary checks to prevent it.

UI changes

On the way to achieve better high DPI support, Morph updated the version of Qt used by yuzu. This will allow in the near future to finally have legible UI elements on high DPI settings.

MightyCreak has arrived with several internal changes, most helping with the build process of yuzu. One of them is enabling mouse cursor auto-hide by default, a very welcome quality of life change, especially now that more users will be playing their games in fullscreen. Thanks!

Linux gamepad users will no longer have to periodically tap their mouse to avoid the screensaver from taking over their screens! toastUnlimited properly disabled the screensaver while running yuzu.

Moonlacer continues polishing the text strings in the UI, this time helping new users understand what our NVDEC (video decoding) options do.

Some users tend to think that NVDEC means that video decoding will only work on NVIDIA GPUs, this is not the case. NVDEC is the name of the module in the Nintendo Switch, which uses the Tegra X1, an NVIDIA SoC (System on a Chip). This SoC uses the NVDEC module to decode videos, and the work yuzu has to do is emulate it to work on any compatible system, including systems without NVIDIA GPUs on them. We have a full explanation here.

So, for the sake of clarity, the options were renamed to better convey the intended result:

No Video Output will result in a black screen every time a video wants to render, nothing is displayed, no fun.
CPU Video Decoding means processing videos using the CPU. This can be useful for AMD Windows users, since the AMD driver is notorious for having bad VP9 video decoding performance on Vega and newer GPU series, and using the CPU to render could be both faster and more accurate.
GPU Video Decoding means actually using the GPU’s decoding capabilities to process videos. This is considerably faster than CPU decoding and is the default option. If a video format is not compatible with the user’s GPU, yuzu’s NVDEC emulation will automatically fallback to CPU decoding.

For some time, we were wondering why the Switch had an open spot in its language selection. Turns out, with the release of Mario Party Superstars, Nintendo added support for Brazilian Portuguese! Morph rushed to add support for it in yuzu. Our game language selection menu can be found at Emulation > Configure… > System > System > Language. Jogo bonito on your gameplay sessions!

The text on the TAS configuration window looked cramped, so Behunin edited the UI file and reformatted the text to make it easier to read. Later, Moonlacer added to these changes by fixing some grammar nits and adding a hyperlink that links to the guide on our site.

Moonlacer also fixed a problem with the per-game configuration window, where scaling the monitor over 100% would squash the window.

Input changes

When german77 added auto-centering support all the way back in July, the range of the new center wasn’t considered, making the analog sticks overpass 100% in a direction while failing to reach it in the opposite way. Scaling the value of the range depending on the offset applied when centering solves this issue.

Future projects

With the resolution scaler finished, our GPU devs have space to breathe, and they can focus back on work that was reserved for later. Project Y.F.C is an example. In Blinkhawk’s words, “there’ll be Chicken Nuggets for everyone soon, a.k.a. it will cover many different things.”

Lifelight intensifies (Super Smash Bros. Ultimate)

Project Gaia is advancing very well, and Project Kraken (our Input Rewrite) is out but didn’t make it in time for this progress report. Don’t worry, we will discuss it next time!

That’s all folks! Thank you so much for your attention and see you next month!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

New Feature Release - Resolution Scaler

CaptV0rt3x — Sun, 24 Oct 2021 07:12:00 +0530

Hey there, yuz-ers! For those of you eager to go beyond the limits of Switch hardware and experience the full potential of Switch games, the wait has finally ended. Our most requested and anticipated feature — the Resolution Scaler — is finally here!

This new and massively improved Resolution Scaler is now available in the latest yuzu Early Access builds.
We will be working diligently towards bringing this exciting new feature to our Mainline builds as soon as it’s ready for a full release.

Latest Nvidia drivers are causing rendering issues with OpenGL. Please make sure to use the last known good driver: 472.12

All following images have large file sizes when expanded. Please consider if on a Metered Connection.

What is Resolution Scaler?

Resolution Scaler is a new yuzu feature, which scales the dimensions of textures that Switch games render to, and then renders the games at the scaled resolution. This allows games that were designed to render at lower resolutions (720p/900p/1080p), to go far beyond what was intended and be played at much higher resolutions (2K/4K/8K) in the same window!

The massive undertaking to reimplement this complex feature was only possible thanks to the combined efforts of our talented developers Blinkhawk, BreadFish, epicboy, and Rodrigo.

Metroid Dread (4x)

Old Scaler

Blinkhawk implemented the original Resolution Scaler back in July of 2019. However, the approach he took to achieve that was a bit different. It was inspired by Cemu’s graphic packs, but rather than having a manual graphics pack developed for each title, it would automatically generate scaling profiles as the user played.

The generation algorithm used a database that recorded texture types and whether they were scalable or not. The database was initially empty and, as the game ran, the algorithm would keep learning which textures to scale and which not to. This approach was necessary, because of how yuzu was initially designed.

Originally, yuzu’s memory reads were reactive — meaning textures were downloaded only when games tried to read them and hence it wasn’t possible to know which textures were going to be downloaded.

Although these memory reads were fixed a few months later, the Scaler still needed changes to be made to the management of uniform buffers, so that it would be supported on drivers other than Nvidia. However, the planned rewrites of the Texture Cache, Buffer Cache, and the massive GPU emulation overhaul with Project Hades further delayed developers from working on the Scaler, resulting in it never getting merged.

Hyrule Warriors: Age of Calamity (1x Vs. 3x)

Enter Project ART

Once all of the heavy lifting subsided, Blinkhawk quickly went back to working on the Resolution Scaler and instead of continuing work on the original scaler, he decided to rewrite it from the ground up.

Learning from the experiences of the original, Blinkhawk designed and created the new scaling system, which took a significant amount of time and effort. He initially researched and experimented with a lot of different design approaches and learned their challenges, before finally landing on this new scaling system.

The Legend of Zelda: Breath of the Wild (Bilinear Vs. FSR @ 2x)

Unlike the original scaler, which was inspired by Cemu’s profile-based scaling, Project ART uses a rating system. The meticulously designed rating system works by having a set of rules dictating which render targets can be scaled and having a rating for each texture. We couldn’t simply use a binary “YES/NO” system because, unbeknownst to us, some games may render textures only once. Scaling these is pointless and has the potential to break them.

For the uninitiated, render targets are just textures that the game renders to. Textures can only earn 1 credit per frame. And to earn that 1 credit, the texture itself as well as any other textures in that renderpass, all need to satisfy our set of rules. After accruing 2 or more credits, the texture will be scaled and now all rendering will be done in the scaled resolution for that texture.

The textures keep earning more credits as frames pass. But if in any frame, even a single texture within a renderpass fails to satisfy the set of rules, all texture scores will be reset to 0. If a texture interacts with other textures, its new rating will either be based on the current rating of those textures or will be increased to the maximum possible rating, if one of those textures is already scaled.

Metroid Dread (Bilinear Vs. FSR @ 2x)

The Rest of the Puzzle Pieces

After the scaling system was ready, Rodrigo helped implement the shader patching required for scaling. This was needed to ensure shaders behaved properly when textures were scaled.

While Blinkhawk was working on improving scaling in Vulkan and the texture cache, epicboy was working in parallel to add scaling support on the OpenGL side. But little did they know, their bug squashing crusade was just about to begin.

As scaling is intrusive, bugs can occur in a myriad of ways. Scaling occurs when games load in textures, which is usually during loading screens, but the visual bugs tend to happen later during gameplay. This makes it quite hard to figure out where the bug originally manifested.

Super Mario Party (1x Vs. 3x)

Fast-forward a few weeks, and thanks to continuous iterative internal testing, our developers were finally able to fix most of the bugs they came across.

With much of the scaler work nearly being done, Blinkhawk ported some texture filters from Citra and adapted those to be scaling filters for yuzu. BreadFish later tuned them and also added a little something extra, AMD’s FidelityFX™ Super Resolution (FSR)!

Super Mario Odyssey (1x Vs. 3x)

Benefits of Project ART

The feature-set of Project ART includes the following:

Native Resolution Scaling:
- Upscaling (2x, 3x, 4x, 5x, 6x) and Downscaling (0.5x, 0.75x).
FXAA Pre-filtering Pass
Fixed various bugs introduced from the Texture Cache Rewrite (TCR).
Window Adaptation Filters

Mario Kart 8 Deluxe (Bilinear Vs. FSR @ 2x)

What to expect from Project ART

The Resolution Scaler requires much more VRAM as compared to games running at their native resolutions. Here are some minimum and recommended values based on our testing:

Upscaling works with most games! We currently know of two games that don’t upscale - Paper Mario: The Origami King and Crash Bandicoot 4: It's About Time. These games are incompatible because they use a compute shader to render an image, which is challenging to work around. However, thanks to mods, Paper Mario: The Origami King can be upscaled with a workaround discussed below.

Downscaling, surprisingly, turned out to be more stable than we thought. With this, you can gain 20% or more performance at the cost of reduced quality. It works for most of the games we tested, but our testing has been limited. We currently know of one game that doesn’t downscale (but upscales) — Sonic Colors: Ultimate.

Animal Crossing (1x 30FPS vs. 0.5x 36FPS)

Some games that have their own FXAA need a mod to disable their built-in FXAA. This is because the games use hard coded texture dimensions in their FXAA filters, which leads to poor anti-aliasing quality or artifacts. Pokémon Sword/Shield needs the No Outlines mod for optimal picture quality, as the outlines don’t scale correctly.

Kirby Star Allies is known to have an additional performance cost when upscaled. This is caused by the need to downscale textures before upscaling in order to bypass some crashes and issues in the game.

Special thanks to our community member and modder theboy181, who created new mods that help with upscaling some of the games listed earlier.

Conclusion

As we couldn’t fully test the Resolution Scaling with the entire Switch game library, we look forward to all the user feedback we will receive. Your reports will be important in fixing bugs and polishing the Scaler to be the best experience possible.

If you encounter any issues, bugs, or crashes, please reach out to us via our Discord Patreon channels. We hope you love this new feature and will be back with more exciting news in the future! Happy emulating!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report September 2021

GoldenX86 — Mon, 11 Oct 2021 12:00:00 -0300

Hi yuz-ers! Welcome to the latest entry of our monthly progress reports. We have even more GPU rendering fixes, TAS support, 8 player mayhem, input and UI changes, some preliminary work for future big changes, and more!

Yet more AMD specific changes and other graphical fixes

Certain AMD and Intel GPUs were unable to utilize yuzu’s unlock FPS feature with the Vulkan API, due to the lack of driver support for the VK_PRESENT_MODE_MAILBOX_KHR presentation mode. They, however, support VK_PRESENT_MODE_IMMEDIATE_KHR, another mode that allows Vulkan to present at a higher framerate than the screen refresh rate, so epicboy made the necessary changes in order to unlock the FPS on these GPUs. Due to the nature of this presentation mode, this may cause visible tearing on the screen, so bear that in mind if you try this out.

And this is with just an RX 550 (Metroid Dread)

Booting a title in Linux with the Vulkan API using the Intel Mesa driver resulted in a crash due to a device loss error. The problem was in the synchronization between the rendering and subsequent presentation of frames.

Previously, yuzu would issue the Vulkan Present command, then wait for the frame to be rendered before continuing with the process. While this was fine for other drivers and vendors, ANV (Intel’s Vulkan driver) expected to have the frame already rendered before this command, causing this error.

epicboy fixed the synchronization behaviour so that yuzu now waits until the frame is fully rendered and ready before presenting it.

With the release of AMD’s Windows driver version 21.9.1, and its equivalent AMDVLK and AMDGPU-PRO Vulkan Linux counterparts, users started noticing crashes in most games right at boot. We rushed once again to blame AMD for breaking another extension, as it wouldn’t be the first time. We even singled out Int8Float16 as the culprit, providing an alternative path that reduced performance on all AMD GPUs running non-RADV drivers.

We were wrong.

Turns out, it was our fault. epicboy found out that during the process of initializing Vulkan, the emulator assigned Int8Float16’s values after its memory was freed. Surprisingly, this only started affecting official AMD drivers recently, after their periodical Vulkan version update. So we had to lay down the pitchforks, this time. Performance returned to normal after the introduction of this PR.

AMD Windows users are also familiar with certain stages in Super Smash Bros. Ultimate turning completely white or ghosting, akin to when applications would freeze back in the Windows XP era. Those were the good days.

Ahem, anyway, AMD Radeon GPUs lack support for fixed point 24-bit depth textures, or D24 for short, a relatively common texture format. To bypass this hardware limitation, yuzu uses D32 textures instead, which can cause precision issues during the conversion process. By adjusting the Depth Bias and Polygon Offset of yuzu’s D24 emulation, Blinkhawk solves the issue for good.

Fair play, please (Super Smash Bros. Ultimate)

Yet another AMD Radeon specific issue is visible when playing The Legend of Zelda: Breath of the Wild. Terrain textures were colourful and corrupted, like when a PC gamer dials up the RGB to 11.

This issue affected our regular suspects, GCN4 devices (Polaris, RX 400/500 series) and older, running on the Windows and Linux proprietary Vulkan drivers. GCN5 (Vega), RDNA1, and RDNA2 devices were unaffected. The problem resided in how we guessed the textures were being handled by the game.

Some information first: there are several ways to handle textures, and in this particular example we need to focus on two, Cube Maps and Texture Arrays.

Cube maps are a cube with its six faces filled with different textures. The coordinate used to fetch the data, unlike the regular X and Y values, is a single versor originating from the center and pointing to the surface of the cube.

Texture arrays on the other hand are just as the name implies, an ordered array of textures one after the other, with X and Y used for positioning information inside the texture, and a Z axis used to determine which texture of the array is in use.

TL;DR, one is a sphere and the other is a list.

Vulkan allows for textures to be marked for conversion into cube maps if later needed, but the sampling (reading) is determined by the texture type specified by the game’s shader instructions. This type is then passed to the graphics API. We do just this and the game decides to keep its textures as arrays, which is its own decision. However, the AMD driver decides that the textures should be sampled as cube maps, ignoring what the texture view determined just before.

While this should not be a problem on its own, as coordinates can still be pulled out from the wrong texture type, the driver can end up reading the wrong texel. This can result in happy rainbow ground in The Legend of Zelda: Breath of the Wild, or as dark and evil terrain in Hyrule Warriors: Age of Calamity.

By disabling Cube Compatibility on GCN4 and older devices running the official AMD proprietary drivers, epicboy returned proper sense to the devastated land of Hyrule.

I prefer no RGB, thanks (The Legend of Zelda: Breath of the Wild)

But not THAT dark! (Hyrule Warriors: Age of Calamity)

Speaking of RGB, as discussed back in February, yuzu has to use compute shaders to convert most BGR texture formats in OpenGL to avoid mismatched colours. While this can work fine on most current GPUs, there’s a performance cost that can affect older and slower products.

Users of Kepler series Nvidia GPUs (usually GTX 600/700 series, with several renamed 800 and 900 series too) could experience those performance penalties while also producing rendering corruptions. Instead of using compute shaders to swizzle textures, epicboy figured we could just use Pixel Buffer Objects (or PBO for short) for all affected texture formats instead. This has many benefits: it solves Kepler BGR issues, improves performance on weak devices from any GPU vendor, and is also a required change for A.R.T. (the resolution scaler in development).

A Hat in Time

On the subject of changes needed for the resolution scaler, Blinkhawk implemented fixes to queries and indexed samplers. The result is fewer crashes while playing Luigi’s Mansion 3 on Intel and AMD GPUs, be it on Windows or Linux. This PR helps improve stability for A.R.T. as well.

Another issue affecting Luigi’s Mansion 3 is related to its use of Tessellation Shaders on Vulkan. The Vulkan specification requires the input-assembler topology to be PATCH_LIST in the tessellation stages. Not all games follow this, so manually forcing it solves crashes experienced in some drivers, more specifically, as you may have guessed it, AMD’s proprietary ones. All thanks to our fishy epicboy.

epicboy has also fixed some minor bugs with the StencilOp, a type of data buffer intended to help limit the size of the rendering area. Thanks to this, WarioWare: Get It Together! properly renders its models.

Waa! (WarioWare: Get It Together!)

vonchenplus added support for the legacy GLSL gl_Color and gl_TexCoord attributes into our Vulkan backend, so that any game that uses them can render properly when using this API.

Both these attributes are part of a set of attributes with specific definitions and uses. But they were deprecated in newer versions of OpenGL in favour of “generic” attributes that the programmer can freely define as they want, based on their needs.

While OpenGL is still able to run shaders that use this legacy feature for the sake of backwards compatibility, they were already considered obsolete by the time Vulkan was created, which means that this API lacks a fallback.

What vonchenplus did is use generic attributes in Vulkan to emulate these features, so that they behave exactly as the legacy GLSL attributes.

After that, vonchenplus corrected the definition of the values in an enum used for blending textures.

Both these changes affect DRAGON QUEST III: The Seeds of Salvation, fixing the graphical bugs present in this game.

DRAGON QUEST III: The Seeds of Salvation

Tool-assisted speedrun

MonsterDruide1 has added TAS support to yuzu! This means precise input commands can be recorded and replayed in-game. The format used to store them is the one TAS-nx implemented, and we have a guide on how to enable and use this feature here.

You can access TAS configuration by going to Tools > Configure TAS…

TAS Configuration window

Other input changes

Let’s start with a nice addition by german77 that will make Super Smash Bros. Ultimate players happy, and Parsec users especially so. There’s now an option to enable 8 player support for XInput devices, at the cost of disabling the Web Applet. A small price to pay for epic fights with your friends.

You can find the option in Emulation > Configure… > Controls > Advanced > Enable XInput 8 player support (disables web applet).

yuzu Controls configuration window

v1993 later hid the option for non-Windows OSes, as this limitation doesn’t apply outside the Windows SDL builds.

Linux kernel drivers for Joy-Cons use a different naming convention than the ones we use on Windows. Properly following this convention makes the Dual Joy-Con input show up in the device list. german77 thinks of the penguins.

UI changes

With the release of Project Hades, yuzu started using a full Pipeline cache instead of single stages of the graphics pipeline, both in Vulkan and OpenGL. This means parts of our UI were outdated, so your degenerate writer decided to simply update the context menu entries from Shader cache to Pipeline cache.

Following suit, Moonlacer helped replace Use disk shader cache with Use disk pipeline cache. ¡Gracias!

Later on, Moonlacer removed the toggle for Enable audio stretching from the audio settings, as it no longer had any purpose. As a general rule, the fewer options available, the better.

Morph decided to eliminate a 2 year old feature, boxcat.

BCAT is a network service used by the Nintendo Switch to add content to its games without needing constant updates. Our old BCAT implementation only added some “gifts” our developers placed into games that were playable at the time. It was unable to support real use cases, like the game updates Animal Crossing: New Horizons regularly pushes.

While the plan is to add support for this in the future, major changes to the file system emulation need to come first.

behunin implemented much needed clean ups to our debug configuration window. View the results below:

Before and After, Debug configuration settings

General bugfixes

epicboy noticed a memory leak that would grow progressively after stopping and restarting the emulation, which was caused by yuzu’s main_process not being cleaned up. By destroying this process when stopping emulation, the resources are properly freed now, fixing the leak.

Additionally, epicboy also mitigated the crashes that happened when emulation was stopped by using std::jthread for worker threads.

std::jthread is a new implementation of the thread class that was recently introduced in C++20, which alleviates their management and usage, since they simplify some of the synchronization challenges inherent to multithreading.

With this change, the number of crashes caused by race conditions between working threads upon shutdown was supposed to decrease, but it also introduced a new bug that would cause yuzu to hang when the emulation was stopped.

This problem was caused by the order in which objects were being destroyed, which epicboy fixed in a follow-up PR.

bunnei also introduced std::jthreads into the cpu_manager, in favour of using this more efficient implementation of the class for yuzu’s host threads.

He also made changes so that the KEvents used in the nvflinger service and queue are owned by these services, instead of being owned by the process for the emulated game, which makes the implementation more accurate.

We’ve been trying to focus on improving our homebrew support, as this isn’t just a powerful tool that only developers use. For example, modders have very powerful homebrew apps that the Switch community enjoys. One important example is UltimateModManager, or UMM for short, which refuses to work on yuzu for now.

To counter this, ogniK allowed homebrew running in yuzu to also create subdirectories instead of just the parent directory, resulting in UMM managing to at least start. This is a temporary solution until our much needed filesystem rewrite is finished. Additionally, Morph pushed a partial implementation of the GetFileTimeStampRaw function, removing several warnings.

This isn’t enough to allow full UMM compatibility, but we’re getting there.

Moving on to a quality-of-life change, some games pop-up a confirmation window when trying to stop emulation.

Like this, End emulation confirmation window

This kind of redundant question is generated by the game itself and while we always had a toggle to skip it, it wasn’t working properly. epicboy comes to the rescue, fixing the toggle for good and saving us precious seconds in quitting our games.

If you wish to change this behaviour, the option is in Emulation > Configure… > General > Confirm exit while emulation is running.

v1993 moved all QtWebEngine data to a more organized centralized folder, improving consistency and reducing clutter from the user’s storage. Instead of a separate folder in %localappdata%, information is now saved in yuzu’s directory, %appdata%\yuzu\qtwebengine by default.

toastUnlimited performed his first stubbing surgery with the audio input services Start, RegisterBufferEvent, and AppendAudioInBufferAuto. This way, Splatoon 2 can now be played via LAN without requiring the use of auto-stub. Happy splatting!

german77 stubbed SetTouchScreenConfiguration and implemented GetNotificationStorageChannelEvent to make Dr Kawashima's Brain Training for Nintendo Switch playable.

Dr Kawashima's Brain Training for Nintendo Switch

He has also stubbed Match to make Cruis'n Blast playable. This game experiences some crashes, so there’s more work to do.

Cruis'n Blast

ogniK implemented the EnsureTokenIdCacheAsync function, making Death Coming go in-game, albeit with some graphical bugs that we have to sort out in the future.

Death Coming

Morph has been working on implementing what is needed to get Diablo II: Resurrected working. Initially, the Read socket service was implemented, but this mandates also implementing more complex services like Select and EventFD. EventFD is particularly tricky as there is no native support for it on Windows, so a considerable amount of work is needed to properly emulate it in the most popular OS.

As a temporary alternative, Read was just stubbed, allowing the game to boot.

Diablo II: Resurrected

Future projects

For anyone wondering about Project A.R.T., the following image speaks for itself.

Xenoblade Chronicles Definitive Edition

Regarding works in progress, there are more rendering fixes underway, and we’re already starting plans on what to focus on after A.R.T. is finished.

That’s all folks! Thank you for your attention and see you next month!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report August 2021

Honghoa — Sun, 12 Sep 2021 12:00:00 -0300

Welcome, yuz-ers, to our monthly report of developer perseverance and other happenings! In this recap, we’ll discuss Radeon fixes, Reaper v3, LAN support, smooth video rendering, and more!

Another Terrible Implementation, and other graphical fixes

This month was certainly a happy one for AMD users, as our developers managed to fix a number of graphical bugs present for those with AMD graphics cards.

epicboy pushed a fix for the wireframe issue affecting various 3D models when playing Pokémon Sword and Shield while using an AMD GPU on Windows. Unfortunately, some games, like Super Mario 3D World + Bowser's Fury, have similar bugs which were not improved by this fix. Also, do note that, in some rare cases and conditions, the issue can still occur.

Best character (Pokémon Sword)

The cause of the problem boils down to the drivers of a certain vendor (AMD) not properly reading shader attributes near a demote or discard instruction.

Among the many programs that run on the GPU to render graphics, fragment shaders are in charge of calculating the colour of every pixel written into the frame-buffer that will be sent to your screen. In some cases, these shaders are used to perform subordinate calculations instead, such as derivatives.

This is a problem, however, as fragments shaders are always expected to write into the frame-buffer. When used like this, the colour data of these shader instances remains uninitialized, which is undefined behaviour that will most likely result in rainbow-puke graphics being sent to your screen.

This is where the demote and discard instructions come in to the rescue. They are used to mark these fragment shaders, so that the colour of every shader instance that is demoted is ignored, keeping the thread alive to perform calculations while the frame-buffer remains untouched.

Whenever the driver tried to read attributes (i.e. data such as positions, normals, etc.) in the proximity of these instructions, it would misread them, causing the infamous graphical glitch.

Thankfully, this was fixed by simply delaying the demotion of these fragments to the end of the shader program, which has a slight impact on their performance, albeit not one big enough to be concerned.

Next on epicboy’s list, we have a fix that solves the brightness of sRGB graphics when rendering from a secondary GPU, since they looked much darker than they should.

Free HDR! (Super Mario Odyssey)

This occurred when the rendering was performed by an AMD GPU, but the presentation of images from the swap chain (the virtual buffers used by the GPU to prevent tearing and stuttering when updating your screen) was done by an Intel or Nvidia GPU. The swap chains that were being rendered on the AMD GPU, which contained images in sRGB format, were being read as Linear on the secondary GPU, causing them to be presented with erroneous intensity levels. This is because the scales used in these formats are incompatible, and their values do not automatically map to an equivalent value on their counterpart space, resulting in a quality degradation of the image when using the wrong format.

As a solution, the Linear colour space format is now preferred when presenting frames from the swap chain. This alleviates the wrong interpretation of the frame’s format, allowing all frames to display properly in the linear colour space.

Another annoying Windows-only AMD GPU bug gone for good thanks to epicboy is the horrible bright squares that would appear in the shading of a number of titles: most notably, Fire Emblem: Three Houses.

Your browser doesn't support mp4 video. :(

Not so psychedelic any more (Fire Emblem: Three Houses)

The cause of this problem lies at the hardware-level differences between the GPU of the Nintendo Switch, and that of AMD cards.

In graphics programming, it’s extremely common to perform the same operation over a considerable number of elements — such as vertices, pixels, etc. GPUs were, thus, designed to operate over large amounts of data at the same time (i.e. in parallel), using instructions that exploit this principle, known as SIMD (Single Instruction, Multiple Data). This method of parallel computing, combined with multi-threading, is known as SIMT (Single Instruction, Multiple Threads).

In the case of the Tegra X1 (the GPU of the Nintendo Switch), these instructions operate on bundles of 32 threads (called workgroups), all of which run the same code — although they do not necessarily operate on the same data. The SIMT instructions in AMD cards post the GCN architecture, however, only work with workgroups of 64 threads. This presented a challenge, as yuzu had to divide these workgroups of 64 threads and make them behave as two workgroups of 32 threads in order to properly emulate the guest GPU on these devices.

epicboy addressed this problem and fixed these instructions, so that by using the thread’s invocation ID, it’s possible to tell whether any thread is part of the “lower” or “upper” 32-thread group, effectively allowing AMD cards to emulate the behaviour of the Nintendo Switch GPU.

Blinkhawk has also contributed a number of fixes for bugs affecting AMD, starting with disabling a vulkan extension (VK_EXT_SAMPLER_FILTER_MINMAX) in their GPUs prior to GCN4 (Polaris), which do not have the necessary hardware to support the extension. Notably, this fixed the psychedelic graphics in The Legend of Zelda: Skyward Sword HD, one that many of us will miss, for sure.

This was originally a video, but it could have triggered epilepsy (The Legend of Zelda: Skyward Sword)

On a similar vein, he increased the number of sets per pool on AMD (a feature used in Vulkan to manage the memory of resources), fixing the random crashes that occurred when booting Xenoblade Chronicles 2.

K0bin is back again, fixing another major issue. This time, yuzu was not following the official Vulkan specification correctly, leading to overlapping information for textures and buffers on Nvidia graphics cards.

bufferImageGranularity specifies the size in bytes at which textures and buffers can be aligned. AMD and Intel GPUs allow for pretty precise values of 1 or 64 bytes depending on the hardware, but Nvidia on the other hand is hard limited to a 1024 byte block.

yuzu didn’t take this alignment into consideration, leading to data corruption primarily shown by Super Mario Odyssey with and without the GPU cache garbage collector enabled. But the same issue could affect any game that handles small textures at any time, as any buffer could corrupt any texture, and any texture could corrupt any buffer.

Properly respecting this hardware set value fixes unheard instabilities when running games in Vulkan with an Nvidia GPU, and allows Reaper, the GPU cache garbage collector, to work on all games.

There was a bug that made Mario’s moustache appear to be light-brown (instead of the classic dark shade we are used to seeing) when using an Intel GPU with the Vulkan API. The problem was a simple one: yuzu was returning the wrong data type when querying the gl_FrontFacing attribute — an unsigned integer, instead of a 32-bit floating-point value. The solution was equally simple: epicboy changed the code so that the queried attribute returned with the correct data type.

Finally, that hair dye was on discount (Super Mario Odyssey)

v1993 has been using PVS-Studio to catch logic errors in the code with good success so far. For example, a small clean up in SPIR-V was possible thanks to this.

LAN party time!

Work on Local Wireless continues, but in the meantime, yuzu is proud to announce that LAN (Local Area Network) support has been added for all users! This is all thanks to work done by spholz.

This means that a small selection of games can now be played with a Switch or any other computer running yuzu while connected to the same network (be it wired ethernet, or via WiFi). With a service like ZeroTier (hamachi has not worked so far) or by manually configuring a VPN (Virtual Private Network), this can be extended to global gameplay!

Games with LAN support so far are:

ARMS
Bayonetta 2
Duke Nukem 3D: 20th Anniversary World Tour
Mario & Sonic at the Olympic Games Tokyo 2020
Mario Golf: Super Rush
Mario Kart 8 Deluxe
Mario Tennis Aces
Pokkén Tournament DX
Pokémon Sword & Shield (limited game functions by design)
Saints Row IV®: Re-Elected™
SAINTS ROW®: THE THIRD™ - THE FULL PACKAGE
Splatoon 2 (works with auto-stub enabled)
Titan Quest

At the moment, not all of the listed games work due to missing services or not having the best compatibility with yuzu, but gameplay proved stable in all working cases.

It just works! (Mario Kart 8 Deluxe)

Keep in mind that some games require certain button combinations to switch between LAN and Local Wireless modes. For example, Mario Kart 8 Deluxe requires the user to simultaneously hold L + R and depress the left analog stick (L3) in the main menu to be able to create or join a LAN room.

Morph later followed with network interface cleanups.

Smooth and glitchless videos for the win

Thanks to the introduction of VA-API by yzct12345 back in July, epicboy made it possible to use hardware video acceleration to decode videos with FFmpeg for all other compatible GPU and driver combinations. Furthermore, yuzu will gracefully fall back to software decoding in case none of the combinations are supported.

This considerably speeds up the decoding process, improving the performance of the emulator when playing videos.

Currently, the following GPU decoders are implemented:

GPU	WINDOWS	LINUX
NVIDIA	NVDEC/D3D11VA	NVDEC/VDPAU
AMD	D3D11VA	VA-API/VDPAU
INTEL	D3D11VA	VA-API

Please note that, since the GPU used to decode videos isn’t necessarily the same as the one used for rendering, NVDEC is preferred on Windows over D3D11VA, as the performance experienced with the latter when it defaults to using the iGPU for decoding was lower.

Next on the list, we have had reports of noisy artifacts appearing in the videos of some games. Notably, those that were encoded with the VP9 format. epicboy investigated the problem and solved it by stubbing UnmapBuffer, a driver command that is, as you could guess, used to free GPU memory held by a buffer. But what was exactly the problem behind this? I’m afraid that this will get a tad bit technical, so bear with me for a while. I promise it will not hurt… much.

The VP9 codec defines, among other things, a number of frames in the video to be used as references, which are in turn employed to reconstruct the frames in-between these key-frames. That means that, to properly interpolate these “in-between” frames, one must rely on the information from both the key-frames, and previous inter-frames. key-frames, on the other hand, are decoded completely on their own, without relying on any reference. Decoding a frame like this is a slower process, but it guarantees that the frame will be as clean of errors as possible, which is why they can be used as references.

As was previously mentioned, FFmpeg is used to decode videos. In the case of the VP9 format, yuzu needs to send FFmpeg the raw bytes that will be decoded (i.e. the actual images that you see in the video), along with a header that contains metadata, such as the dimensions of the frame, whether it is a key-frame, or, if it isn’t, what frames are used as references when processing it, etc.

The information that constitutes this header is mapped to a buffer in memory. And now, here’s where things turn a bit funny. For some reason, the information in this buffer — namely, that part of the header that specified what key-frames should be used as reference, would change inconsistently among inter-frames. This led to a degradation of the quality of the video, as every interpolated frame would reference a different key-frame, leading to the creation of these infamous garbled noise artifacts.

By stubbing the UnmapBuffer command, the addresses of these reference frames now remain constant for as long as they are needed, allowing yuzu to pass to FFmpeg the correct information and decode the videos without any problems.

Your browser doesn't support mp4 video. :(

Both glitch free and smoother (The Legend of Zelda: Link's Awakening)

On a related note, epicboy fixed another VP9 problem: the first frame of the bitstream was missing its frame data, so he changed the logic to ensure the first frame is complete, silencing a runtime error thrown by FFmpeg.

As previously mentioned, yuzu reads the header information directly from the NVDEC registers contained in a buffer. Unfortunately, one key flag that needs to be passed to FFmpeg, is_hidden_frame, was not actually held in this buffer.

To circumvent this problem, our implementation also buffers the next frame, and then, based on another flag that holds the same information (is_previous_frame_hidden), informs FFmpeg whether the previous frame should be displayed or not. This means that yuzu would always decode one frame late, and since that was already the case, yuzu wasn’t sending the header information for the very first frame, as it needs to know the value of is_hidden_frame beforehand.

What epicboy did was simply copy the first frame in the bitstream, so that essentially the first and second frame are the same, and thus, exploiting this fact, the header information can be passed to FFmpeg so it stops complaining.

Alas, the joys of software development are fleeting in this world.

General bugfixes

You can’t predict how a bug will show up, sometimes they pop out like daisies. With the addition of Brazilian Portuguese as a language for the user interface, Paper Mario: The Origami King started to run only in Japanese, ignoring any user setting.

Fixing the copy amount of GetAvailableLanguageCodes was enough to solve this issue. Thanks Morph!

True native gameplay (Paper Mario: The Origami King)

sankasan gave yuzu-cmd, our command-line SDL2 alternative to the regular Qt yuzu, some additional love. By correctly implementing SDL_ShowCursor, yuzu-cmd can now properly hide the mouse cursor while in fullscreen. Thank you!

Also relating to yuzu-cmd, in the past, while button mapping and other settings were working correctly, the toggle to enable the controller was being completely ignored. Reading the connected value as a boolean was all it took to get past this misstep, thanks toastUnlimited!

toast also found an issue in the logic of how per-game profiles were handled: only the default user profile was ever selected. Some code changes, and now the currently selected user profile will be used.

gidoly opened his first ever pull request, fixing a small but arguably very important description.

Use Fast GPU time, one of the options in the Advanced Graphics tab, is a hack intended to improve compatibility with games that use dynamic resolution as a way to keep steady performance on the Switch.

By lying and informing the game/application that performance is always good, the emulator avoids unnecessary destruction and reconstruction of textures, saving both performance and VRAM. As an added benefit, some games use this totally-not-adulterated information to constantly render at their highest supported resolution.

For both these reasons we recommend users to keep this option always enabled, as no regressions have been found when using it, and the stability benefits on some particular titles like Luigi’s Mansion 3 are more than worth it.

So, by calling a spade a spade, gidoly now informs us that Use Fast GPU time is indeed a hack. Al pan, pan, y al vino, vino.

Stubbing the NGCT:U service allows Boyfriend Dungeon to boot. Good catch by german77.

Boyfriend Dungeon

epicboy flipped the positions of Limit Speed Percent and Framerate Cap in the configuration window. Tidying the user interface never hurts.

Are there any developers tired of having to wait over 3 minutes to compile each change done to the texture cache section of the code? Well, yzct12345 split out the definitions, reducing the build time to only 30 seconds.

yzct12345 also found a deadlock in our Single-Producer, Single Consumer queue, and submitted a fix to address this problem. The work to rewrite this queue and make it Multi-Producer, Multi-Consumer has also been started, so hopefully we might see a follow-up next month. If you’re confused about these “Producer-Consumer” terms, just know that they basically describe how to tackle the access to a resource in a multi-core system, so that the processes that write into (produce), and those that read from (consume), a shared resource, are properly synchronized — in this case, the queue.

This adventurous developer also optimized the UnswizzleTexture function, yielding a sweet speed gain. Swizzling refers to a technique used to optimize how textures are stored in memory to minimize cache misses. The opposite operation, thus, would be to take a swizzled texture and reorganize it so it makes sense to humans.

Some time ago, toast detected a potential out-of-bounds access, which is a bug that occurs when the program accesses memory that is outside the range where it should be operating at that given moment. The code in question is also part of the function used to unswizzle textures. epicboy noticed that the root of the problem laid in the calculation of the frame buffer size, used to limit where the code should operate, and fixed it in this PR, effectively eliminating the bug.

While inspecting yuzu manually and with the help of analysis tools, v1993 also found a number of small bugs in different parts of our codebase, such as a misplaced break statement in the kernel function GetThreadContext() — a human error that changed the logic of the algorithm, preventing it from behaving as intended. In a similar vein, he also corrected a copy-paste error affecting the code of the software keyboard.

v1993 also found another bug in the GetSubmappedRange() function, used to obtain the CPU memory segments from a GPU memory address. Blinkhawk went ahead and fixed it.

Another noteworthy change by Blinkhawk is that he changed the logic of the Garbage Collector (Reaper), so that it uses a Least-Recently Used (LRU) cache instead.

Previously, the cache of the GC (Garbage Collector) would iterate over n textures every frame, checking whether they should be cleaned from memory or not. It also used certain heuristics that would make the cleaning more aggressive towards certain kinds of textures, cleaning them without synchronizing with the host memory.

The LRU scheme, however, orders the textures based on how recently they were used. Once the memory is full, the GC starts iterating over the elements of the LRU cache, eliminating the textures that haven’t been used in the longest time. Additionally, the GC now prioritizes eliminating textures that do not need to synchronize with the host memory, and only considers other textures once these have been emptied from the cache. These changes make the new Garbage Collector more stable, so we can safely enable it by default for all users.

Meanwhile, BreadFish64 found that yuzu spent considerable CPU time running GetHostThreadID() — a function of the kernel used to manage threads — while profiling Fire Emblem: Three Houses, and submitted a patch that optimized the generated code, providing a small performance boost.

Input improvements

german77 implemented a few input changes this month.

First of all, when mapping and moving an analog stick, the previous implementation used to only show a blue dot representing the relative position of the analog stick. A new green dot is now present, representing the emulated position of the stick, considering range and dead zones values. It’s useful to know if the stick actually reaches the whole input range.

Your browser doesn't support mp4 video. :(

Remember to test and set both Range and Deadzone

Next, the usual update to SDL, which always brings some goodies. In this case:

The ability to send effects to DualSense triggers (not implemented at the moment).
Better sensor data rate for Switch and PlayStation controllers.
Added support for the Amazon Luna controller.
Added rumble support for the Google Stadia controller.
Improved rumble for the Pro Controller.

And finally, the Web Applet can cause the SDL process to die, disabling an unnecessary feature solves the issue.

Future projects

4K beach episode (Xenoblade Chronicles Definitive Edition)

Progress on Project A.R.T. is going well, most major problems have been addressed. Morph had several eureka moments with Project Gaia. And now other secret recipes are in the oven, waiting their turn.

That’s all folks! Thank you for your attention — happy playing, and see you next time!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report July 2021

GoldenX86 — Thu, 12 Aug 2021 12:00:00 -0300

Bienvenidos, yuz-ers, to our latest monthly progress report! We have a lot to talk about this month, so buckle up, ‘cause this will be one good ride!

Project Hades

Why Hades? Well here's why!

Kept you waiting, huh? After being in development for six months, and spanning almost 50,000 lines of new code, Project Hades has finally been released. This massive rewrite of the shader decompiler is brought to you by Rodrigo, Blinkhawk, and epicboy.

Fixing an innumerable amount of rendering bugs, reducing shader build times, improving compatibility, and increasing performance by over 30% for all GPU vendors, Hades is easily one of the biggest changes made to yuzu to date.

We have a dedicated article explaining the process in technical detail, so we will be focusing only on the end user changes and some recommendations to help you get the best experience out of this new feature that both Early Access and Mainline users can enjoy.

While we keep OpenGL as the default graphics API for compatibility reasons (outdated drivers won’t affect it as much, and it lets Nvidia Fermi GPU users run yuzu out of the box), we strongly recommend testing your games with the Vulkan API first. Vulkan performance and compatibility have improved significantly (especially if paired with the Texture Reaper, the GPU Cache Garbage Collector), additionally, rendering and shader build performance almost always beat OpenGL. This applies not only for AMD and Intel GPU users, but also Nvidia users.

There is an exception, however. The Intel Linux Vulkan driver is not stable at the moment, but we’re investigating the cause of the issue. For now, Intel Linux users should stick to OpenGL.

Integrated GPU users benefit the most from Hades

Hades implements a Pipeline Cache for both Vulkan and OpenGL, meaning that regardless of which API you are using, all shaders are now stored and reused the next time the game is started. This functions similarly to how the old OpenGL Shader Cache behaved. Needless to say, this means that all previous Shader Caches are no longer valid, and will be discarded if someone tries to use them.

The difference in terminology lies in the fact that the whole Graphics Pipeline is now stored, not just a specific set of Shader stages. An important detail, the OpenGL pipeline cache is not interchangeable with the Vulkan pipeline cache and vice versa. Two separate sets of shaders are generated if you use both APIs.

Vulkan now also benefits from parallel shader building, meaning all CPU threads will be able to handle all upcoming shaders in a parallel fashion, instead of asynchronously, avoiding graphical issues and building faster. The end result is the shortest build times of all API and shader backends (more on this later). Thus, on a fresh game with no previously built cache, more CPU threads will provide a smoother experience, with no imposed limit. Someone should test running Super Smash Bros. Ultimate on a big server CPU!

Your browser doesn't support mp4 video. :(

First time gameplay has never been smoother!

All CPU threads, save for one, are used to build shaders. The remaining free thread either handles shader saving to the pipeline cache, or continues the rendering process, depending on if all shaders have been dealt with at the moment. This decision was made not only to improve performance, but also to improve overall system response times while building several shaders simultaneously, and to avoid certain “gaming” laptops from overheating the CPU while keeping all threads busy.

Note that this is a hardware design flaw by the laptop vendors, not an issue with the emulator. The product should provide enough cooling performance to keep its components cool enough even at full demand, not just for reaching advertised turbo clock speeds in short bursts. (Writer note: basically, if you want good gaming performance and longevity, buy thicc laptops.)

Now, not all games will perform or render the best in Vulkan, some will still show better results with OpenGL instead. For the old API, we have some changes too.

When selecting OpenGL, new options show up!

We have introduced a new drop list option in the Graphics settings. Replacing the device selection of Vulkan when using OpenGL, Shader backend shows up, giving three different options to choose from.

Out of the box, yuzu uses GLSL, the default backend for OpenGL. On good performing OpenGL GPU drivers (only Nvidia and the Linux Mesa drivers as of now), it has the best performance, but also takes the longest time to build shaders, resulting in noticeable stuttering when accessing new areas or performing new attacks. This is the recommended option for Nvidia users with a previously built cache searching for the highest performance. While it has its uses in some edge cases, we recommend Windows AMD and Intel users to run Vulkan instead. Linux Mesa users don’t have this limitation and can enjoy GLSL without issues, thanks to far more mature drivers.

Next up is GLASM, what in the past was called Assembly Shaders. This is an Nvidia only feature, it provides lower performance than GLSL or Vulkan, but the second fastest shader build times, only behind Vulkan’s parallel shaders. We recommend Nvidia users interested in using OpenGL to first run games in GLASM in order to build their pipeline cache, and once done, move to GLSL to get the best performance without suffering the shader stuttering associated with GLSL. Any other GPU vendor will skip GLASM and default to GLSL.

Finally, SPIR-V, the default backend of Vulkan, which is a valid option in OpenGL since the release of version 4.6. Originally, we wanted OpenGL to use this backend, discontinuing support for GLSL.

Reality always hits back like the laws of thermodynamics, delaying the release of Hades for several months. Driver support for SPIR-V in Windows is very bad (especially for Nvidia), with only the Linux Mesa drivers having a correct and fast implementation. So we decided to keep the option as an experimental feature, focusing on the old GLSL and GLASM backend first. We plan to improve SPIR-V rendering and performance later. Ideally, SPIR-V in OpenGL should be a jack-of-all-trades, a mix of the performance of GLSL and the shader build times of GLASM.

So to ease our user’s decision on what to choose, here’s a chart of all possible options for the most common GPU vendors.

Another important change is in how GPU accuracy operates. In the past, certain games like Pokémon Sword & Shield required using High GPU accuracy to get the best performance. This is no longer the case. Now, Normal consistently produces the best performance, at a low cost in accuracy, while High produces better particle effects and lighting, at a low performance cost.

We removed values that should be enabled by default from the bottom left action buttons of the user interface, like Asynchronous GPU shaders and Multicore. In their place, users can now switch between Normal and High GPU accuracy while playing. A fast and easy way to test what’s better for each game, GPU vendor, and API.

Old (top) vs new (bottom)

Thank you, Captain Obv — er, I mean, Captain Vortex

Communication is vital for any project, and it is essential that we make our configuration options even more explanatory than they already are.

We want to thank our fellow developer, Vortex, for the marvelous change of rewording the explanation of GLASM. This change was made in order to elaborate that it is, effectively, a shorthand for OpenGL Assembly Shaders.

This is critical

Fear not, my fellow yuz-ers, for we always have the most serious and capable people doing only the best work for your benefit. Rest assured that if a similar situation were to arise again in the future, Vortex will have your back. I salute you, my dear friend, and pray that you may ennoble yuzu even further with your future contributions.

Graphical fixes

epicboy was very busy during the development of Hades, and continues to be busy after it was finished.

World 1-5 of Super Mario 3D World + Bowser's Fury used to crash when loading on AMD and Intel GPU equipped systems running Vulkan. A depth image was being cleared as a regular colour image and, while OpenGL is totally fine with this, Vulkan is more strict which lead to a crash. By only clearing valid colour images, epicboy resolved the issue.

Affected world in Super Mario 3D World + Bowser's Fury

As a way to limit the maximum framerate a dynamic FPS game can run at, epicboy implemented a multiplier based cap. So, for example, if a game natively runs at 30 FPS, but can be run without issues at 240 FPS, setting an FPS cap of 8x will limit the FPS unlimiter to that value. Ideal for high refresh displays!

To avoid confusion with the FPS unlimiter, the old Frame limit was renamed to Speed limit.

You can find the new options here

From before the release of the texture cache rewrite, a regression has existed that caused users’ screenshots to save in the wrong directory. Turns out a single directory separator was missing in the code. Now, screenshots will work correctly by either pressing the Ctrl + P hotkey, or via selecting the Tools > Capture Screenshot… menu option, and save in the selected folder.

epicboy also added support for taking screenshots in the Vulkan API, solving an old issue from way back when Vulkan was first implemented two years ago. How time flies…

Finally, before being dragged against his will to work on Hades, epicboy was working on improving the performance of our compute shader accelerated ASTC decoder. By reducing the size of the workgroup, making some code simplifications, moving some look up tables, and other changes, performance increased by 15% on average. Astral Chain and similar titles that madly love ASTC should see more consistent frametimes with this change.

Blinkhawk has also been working constantly lately, not only on Hades and several other improvements, but also in some top secret projects we will mention later.

Koei Tecmo games are usually quite special, they never fail to give our developers headaches thanks to… unique decisions the studio makes. It’s not an exaggeration to say that Project Hades’ main motivation was improving how these games run in yuzu.

One of the remaining issues with Hyrule Warriors: Age of Calamity, Fire Emblem: Three Houses, and similar Koei games was instability caused by running them in High GPU accuracy when loading specific levels. In Blink’s own words, a simple fix, and the problem was solved.

Another old regression introduced by the Buffer Cache Rewrite affected particles in games like The Legend of Zelda: Breath of the Wild, the rendering of the BowWow in The Legend of Zelda: Link’s Awakening and caused vertex explosions in Unreal Engine 4 games like Yoshi’s Crafted World, BRAVELY DEFAULT 2 and similar. Tuning how to handle high downloads and not fully waiting for command buffers to finish solved these issues. To make the best out of this change, High GPU accuracy needs to be enabled.

Your browser doesn't support mp4 video. :(

High GPU Accuracy is recommended (The Legend of Zelda: Breath of the Wild)

When Blinkhawk introduced the new fence manager while working on improvements for Asynchronous GPU Emulation two years ago, some frame delays came with it, causing stuttering in gameplay even if the framerate counter showed a solid 30 or 60 FPS value. To counter this, Blink starts pre-queueing frames, providing a smooth gameplay experience, especially noticeable if the user’s hardware can’t sustain perfect performance constantly.

Your browser doesn't support mp4 video. :(

Smooth as butter (Xenoblade Chronicles Definitive Edition)

Rodrigo has also been hitting those keycaps without rest.

Hyrule Warriors: Age of Calamity suffered from very dark environments due to unprepared images that were used as render targets. When their dirty flags were not properly set, a desynchronization happened on the texture cache, causing the issue shown below. By correctly preparing such images, the game renders correctly.

That looks like the Dark World to me (Hyrule Warriors: Age of Calamity)

By optimizing shaders doing FMA operations, yuzu gains an extra 4% of performance overall.

By flipping the viewport in Y_NEGATE, Rodrigo matches in Vulkan the correct behaviour OpenGL has, resolving the “flipping” issues for the following games: Katana ZERO, UNDERTALE, DELTARUNE, Shantae, Fire Emblem: Shadow Dragon and the Blade of Light, and others.

Fire Emblem: Shadow Dragon and the Blade of Light

Xenoblade Chronicles 2 experienced crashes with the Vulkan Mesa drivers due to them lacking null buffers in its transform feedback bindings. Rodrigo had to emulate the lack of this function in order to solve the crashing.

AMD Radeon Linux users may have noticed that The Legend of Zelda: Skyward Sword would run at very slow framerates in stable versions of the OpenGL Mesa drivers. This is caused by a driver level bottleneck resulting in very slow PBO (Pixel Buffer Object) downloads. While the current mesa-git has this bottleneck solved, a solution is needed until those fixes reach the stable release versions. By specifying the GL_CLIENT_STORAGE_BIT flag, an alternative faster path can be used, increasing performance from around 8 FPS to a solid 60 FPS. Mesa drivers are the best drivers.

Morph also contributed with some graphical fixes.

New Super Mario Bros. U Deluxe provides video tutorials accessed via the web applet. Prior to his fix, trying to access that list would only result in the game returning to the previous menu. By implementing how to handle Nintendo CDN URLs in the web applet, this section of the game can now be accessed.

Video playback is still a work in progress (New Super Mario Bros. U Deluxe)

Morph also solved a quite specific render issue affecting users with multiple displays. If two or more monitors were in use and the user started a game from any display besides the primary, black borders would appear in the rendering window. To solve this, Morph needed to tell Qt to create a dummy render widget.

Sonic Mania, in proper pixelated format

Newcomer yzct12345 arrived like a sonic boom, implementing critical improvements at impressive speeds!

By ignoring an invalid texture operation, an early crash affecting Pokémon: Let’s go, Eevee! & Pikachu! in Vulkan was solved. No more crashes when catching your first Pokémon. Gotta catch ’em all!

yzct12345’s work on optimizing UnswizzleTexture resulted in up to double the performance for video decoding, and it also improved general gameplay! This results in far smoother video playback and a considerable reduction of the CPU performance needed to get a pleasant gaming experience. Thanks!

toastUnlimited is our specialist in Linux testing and bug reporting. He noticed that the rune teleporting animation in The Legend of Zelda: Breath of the Wild wasn’t working correctly on the Iris and RadeonSI Mesa drivers, the default OpenGL drivers for recent Intel and AMD GPUs, respectively.

Thanks to instructions the Mesa driver team gave us in how to properly use BindImageTexture, toastUnlimited was able to implement the needed changes in yuzu, making the animation render correctly.

Well excuse me, Princess (The Legend of Zelda: Breath of the Wild)

K0bin arrived to give us a hand, fixing an important screw up we made.

Prior to the introduction of full support on Resizable BAR in modern GPUs and systems, the PCI-Express standard is limited to a buffer of 256MB in video memory to communicate to the CPU at a time. yuzu uses this small portion of VRAM for allocating its staging buffer, but if the user has GPU intensive background applications, there may not be enough space to allow the allocation to happen, and yuzu would refuse to create a Vulkan instance, failing to boot any game. OpenGL is, as usual, excluded from this issue thanks to letting the GPU driver handle those allocations on its own.

K0bin fixes this issue by performing the allocation in system RAM if there isn’t enough free space. Many thanks!

Stop This Sound!

Maide has been dedicated to improving the audio side of yuzu this month. By introducing some missing PCM formats, the missing audio present in Ys IX: Monstrum Nox was finally fixed.

PCM stands for Pulse-Code Modulation, an encoding technique used to represent analogue audio signals digitally. These signals have two basic properties: The sample rate (how many samples of the signal are taken per second), and the bit-depth (how many bits are used to represent the “loudness” of the signal’s samples at any given point in time).

In this PR, Maide introduced a number of methods to process formats that were missing in the current implementation — namely, the ability to decode PCM files encoded with a bit-depth of 8-bit, 32-bit, and also floating-point values. Since previously none of these formats were being decoded by yuzu, any audio file that made use of them was not being reproduced, causing this behaviour.

Tales of Vesperia was another title with sound problems, in which audio would be played monaurally through the left channel — far from a pleasant experience, as you can hear here:

Download the audio instead

This game in particular would request the available number of active channels and cap its output based on this information — in other words, the game would not output audio to more channels than what yuzu reported. Since yuzu was always returning a value of 1, the game ended up outputting all the audio into the left channel. Thus, this problem was fixed by reporting two channels as active instead of one, which is now mixed properly:

Download the audio instead

Not satisfied with just this, Maide also went on and changed the downmixing logic, which improved the audio in titles such as The Legend of Zelda: Link's Awakening, New Super Mario Bros. U, Disgaea 6: Defiance of Destiny, and Super Kirby Clash.

Simply put, downmixing refers to the process of combining multiple audio channels so it is possible to reproduce them in a system with a lower number of available audio channels. There is some mathematics involved here and there, but the general idea behind it is to balance the volume of these individual channels so that the resulting signal sounds centred.

In the case of the Nintendo Switch, many games report six audio channels as available to the system, even though they end up providing data for only two channels (stereo sound). Consequently, yuzu would think the games used all these channels and then “downmix” them to stereo, affecting the volumes of the left and right channel in the process, which would end up being much quieter than needed. While the math used by yuzu is valid when used to downmix six channels to two, it certainly was not a desirable effect in this case. Therefore, Maide changed the code to preserve the volume of these channels if the audio in a game is already stereo, which now reproduces with the correct levels.

On the same page of volume problems, there was also a bug with the volume in certain areas of Xenoblade Chronicles 2, where it would occasionally spike out of proportion. Maide tracked down the cause of this behaviour, and discovered that the gain of the samples sent by this game to yuzu had their values set as NaN.

A NaN is a type of placeholder used by computers to represent numeric values that can’t be defined otherwise — hence, the acronym Not a Number. Particularly, the problem at hand lies in the fact that, in order to operate over the samples of the audio signal, these gain values must be converted into integers. But in this process, the NaN values, in turn, become obscenely large positive and negative integer values.

As these samples were further processed by yuzu before sending them to your sound system, these gains would distort and cap the volume of the audio samples to their maximum or minimum value, causing this bug. To prevent this problem, Maide added a check that changes the gain value from NaN to zero in such cases, so that no error is propagated along the mixing.

This is mostly a workaround, as it still remains under investigation why the game is yielding these NaN values, but at the very least, it should help prevent a number of bleeding ears here and there.

Input changes

Along with some miscellaneous quality of life changes, german77 also changed the behaviour of recently enabled controllers in yuzu. In order to provide the most precise experience, now sticks will be auto-centred the moment the device is detected by yuzu. Surprisingly, this happens with almost every game controller, sticks are always slightly off-centre, and if the dead zone value is small enough, users would experience slight drifting during gameplay. No drift in this emulator!

Thanks to internal changes on how settings are stored, the default values of mouse panning were affected. german77 restored the previous values and additionally solved an issue where the emulated stick would always look down if the user had multiple screens. No drift, not even with the mouse!

UI changes

A silent change that has the potential to improve performance considerably for users of old or low-end CPUs has been made by toastUnlimited. In the past, we recommended our users to manually select the Unsafe CPU accuracy option if their CPU lacked the FMA instruction set. This is not only confusing for users, as it required them to know if their specific CPU model was compatible with FMA, but also relied on communication channels and guides properly explaining this to as many people as possible. This, of course, resulted in several users not even knowing why games performed so poorly.

Additionally, it was later discovered that using the whole Unsafe preset can cause precision issues affecting things like the shape of the character hitboxes in Super Smash Bros. Ultimate. A better solution was needed.

In response, toastUnlimited implemented the all new Auto CPU accuracy setting! Enabled by default for all users, this setting determines the need to use the Unfuse FMA value automatically by reading if the FMA instruction set is supported by the CPU in use. It also sets other values, for example Faster ASIMD instructions, to boost the performance of 32-bit games. Auto CPU accuracy has the potential to more than triple the performance of users running old or very low end CPUs!

Thanks to work done by Morph, now all default six Miis are available to the user in games that request them.

We're still far away from offering full Mii customization, but at least more options are available now (Mario Kart 8 Deluxe)

lioncash, our silent optimizer and code cleaner, found an issue with the new strings that report if a game is 32 or 64-bit. Languages that read from right to left had issues with the initial implementation, and translating this string was disabled. Now both issues are resolved!

After gathering more information on the behaviour of the FPS unlimiter, epicboy discovered that some games will crash when attempting to boot them unlimited. Simply force-enabling the limiter at each game boot is enough to solve the issue. Remember to unlock the framerate manually after you start a game!

vonchenplus is back with another nice addition! Certain game dumps contain several games inside them, and yuzu would default to only launching the first one in the list. This change makes the necessary modifications so all games are properly listed.

Command-Line Shenanigans

toastUnlimited performed a general update to the settings of the command-line version of yuzu, yuzu-cmd.

The previous implementation had many options that were originally carried over from Citra and later deprecated, as well as others that were not read properly from the ini file, or were read but not written into the ini file, etc. In other words, there were a lot of things wrong with it, and some updating was in order to properly synchronize everything back with the settings present in the main executable of yuzu.

Since toastUnlimited was already working on yuzu-cmd, he also went on and fixed some problems related to Vulkan on Linux. When this executable was launched, it wasn’t able to detect the window manager, and would proceed to exit instead of booting a game.

The cause behind this problem lies in the fact that we recently updated how the SDL external library is being fetched for our Linux binaries, which came with a dummy configuration file with invalid settings. toastUnlimited made it so that we manually include the correct generated configuration file for building SDL instead of this dummy, while also adding some new logging information to report when support for a window manager was not compiled.

In a follow-up PR, toastUnlimited also added support for the full-screen mode settings to yuzu-cmd. Concurrently, he also fixed a bug that caused yuzu to render with the wrong resolution when in full-screen.

Some time ago, we made it possible for yuzu to run in different full-screen modes, but these options were never added to the command-line version of our executable, which is addressed in this PR.

Technical Changes

Meanwhile, bunnei was busy improving the management of kernel objects, drastically reducing the amount of objects that kept dangling in memory after closing the emulation session.

A dangling object refers to a stale object in memory that still has references, even though the object is no longer in use.

In yuzu, kernel objects are implemented so that they keep track of themselves through a reference counter, which keeps the object alive for as long as they’re needed. In other words, whenever a process needs an object, the reference counter is increased, and conversely, the reference is decreased when the object isn’t needed any more.

Once this value reaches zero, the object is automatically deleted. Previously, yuzu wasn’t doing a great job at maintaining this reference counter, as these kernel objects can be called by more more than just one process — i.e. the “owners”, who are responsible for freeing the resource once they’re done with it. In some cases, some of these owners weren’t properly freeing the object at all, which meant that the reference counter never reached zero, leaving this object “dangling” in memory, even though the information became basically useless at this point.

One of the many jobs of the kernel in the OS is to keep track of all the resources available in the system. For this reason, these dangling objects were a problem, as the kernel calculates the number of resources that can be spawned based partly on the number of active objects in memory. With dozens of different kernel objects being created thousands of times between emulation sessions, this easily saturated the amount of objects that could be spawned due to yuzu hitting the resource limits much earlier than expected. What’s more, since these objects stick around even after the emulation session is closed, this is a memory leak that would gradually increase for as long as the emulator is running a game — in other words, it would persist even if you stopped the emulation and started it again.

bunnei took a long look at the problem and improved the situation, but there’s still ongoing work to make our implementation more robust and accurate.

Blinkhawk also had his share of bug-fixing work, as he revisited the texture cache code related to 1D-to-2D texture overlaps, which fixes problems in Monster Hunter Rise and both the the trial and final versions of Monster Hunter Stories 2: Wings of Ruin.

Similarly to how two-dimensional textures are mapped to three dimensions, one-dimensional textures are a simple type of texture that is mapped as two-dimensional when rendered on the screen. The problem here lies in the fact that the GPU is unable to tell the difference between a one-dimensional texture and a two-dimensional texture with a height of one.

As such, it was necessary to add support for them, so that they can be processed correctly by our texture cache. With the changes in this PR, Blink made it so that they can be copied seamlessly, fixing this faulty behaviour.

From Zero to Hero (MONSTER HUNTER STORIES 2: WINGS OF RUIN Trial Version)

If you’re interested in a more technical explanation about textures and their types, we recommend reading the D3D11 documentation provided by Microsoft.

Future projects

Project A.R.T., the designated name for our revival of the resolution scaler, has started, and early results look very promising!

Getting blue-shelled at 4K doesn't really help with anger management (Mario Kart 8 Deluxe)

There are many bugs to fix, optimizations to make, and tons of testing to do before we can confidently release this feature. So for now, know that the scaler is returning!

toastUnlimited started the preliminary work to get an operational Linux installer to accompany our current Windows one. This also means offering precompiled builds for both Mainline and Early Access. Once it is finished, Linux users will no longer need to be forced to build from the source (if they so prefer)!

That’s all folks! As a certain AI singer would say, thank you for your kind attention. See you next time!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report June 2021

GoldenX86 — Fri, 16 Jul 2021 12:00:00 -0300

Heya yuz-ers! Welcome to June’s progress report. This past month, we’ve had impressive CPU performance gains, the release of Project Reaper v1, critical audio fixes, an “unlimited” FPS toggle, tons of kernel changes, UI improvements, and more!

Project Texture Reaper

An old debt we owed since the release of the Texture Cache Rewrite was Project Texture Reaper, a GPU Cache Garbage Collector, originally started by Rodrigo and finished by Blinkhawk with new and very important optimizations.

This garbage collector has the task of freeing VRAM space by removing the least used resources (textures and buffers), targeting a range of 2 to 4GB of total used VRAM. This range has been decided by Blinkhawk after extensive testing.

It’s worth mentioning that GPUs with 2GB of VRAM or less will be handled by either the driver (in OpenGL) or yuzu (in Vulkan), diverting resources to shared VRAM (a portion of system RAM) as needed. For performance reasons, we strongly recommend a GPU with 4GB of VRAM or more.

While this is a critical feature for our Windows AMD Radeon and Intel GPU users that suffer from bad OpenGL performance and rendering, all GPU vendors benefit from it. This makes it a safe option to use in most games going forward, with the exception of a few outliers: most notably Super Mario Odyssey running in OpenGL.

The end results speak for themselves. Games like Xenoblade Chronicles 2 can now be played perfectly fine in either OpenGL or Vulkan. In the following graphs, you can see the effects of Reaper in action. Our test system is running an Nvidia GeForce GTX 1650 SUPER with 4GB of VRAM, and the API in use is Vulkan (in order to avoid any possible driver-level garbage collector).

Before

The above (Before) result has Reaper disabled just after starting the game. VRAM utilization quickly rises to the maximum 4GB available on the testing graphics card. Once the available VRAM is consumed, the GPU driver will start to use system RAM as a fallback, continuing to pile up resources until the application crashes.

After

The above (After) result has Reaper enabled. You can see how the GPU keeps a steady 2.5-2.6GB of VRAM utilization after several minutes of gameplay, until a sudden spike in use happens. Reaper intervenes and VRAM utilization quickly returns to the average idle of 2.5GB.

Reaper is available to all users in Emulation > Configure… > Graphics > Advanced > Enable GPU Cache Garbage Collector. Due to some issues found in Super Mario Odyssey, the option is disabled by default. We plan to introduce a more robust version in the future. It is expected to be enabled by default then.

While previous Disable Dynamic Resolution mods can now be disabled, we recommend keeping them, not only for picture quality purposes, but also to reduce unnecessary resource use by avoiding creating new textures after each resolution change.

One does not simply fastmem into Windows

This was a very exciting month as we were able to implement fastmem, a technique that provides a considerable performance boost by reducing the CPU load when accessing memory within yuzu. Instead of emulating the Nintendo Switch’s Memory Management Unit (MMU) through software, yuzu is now able to use the host PC MMU to decode memory addresses. This reduces the latency and size of the code of this operation, allowing for a more efficient use of the instruction cache (used to store instructions within the CPU and speed up the fetching stage).

Originally, implementing fastmem in yuzu wasn’t considered an option as there was a technical limitation in the Windows OS, but thanks to some changes in the API introduced in Windows 10 version 1803, it finally became viable. However, due to a lack of documentation of this feature (thanks Microsoft), our devs didn’t know they could use it. We’d like to thank BreadFish64 for informing our devs about this change, and bylaws for updating Microsoft’s documentation regarding this behaviour. As previously mentioned, this feature is incompatible with Windows versions older than 1803. Using an older Windows version will cause yuzu to fallback to the old MMU implementation — although this requirement could change in the future. If you are interested in a more detailed explanation of how it works and the limitations that prevented its implementation, feel free to read the dedicated article for fastmem.

Some of the measured performance gains, in FPS

Shortly afterwards, toastunlimited noticed there was a bug in our MinGW builds, resulting in fastmem not working. This was because the defined constant MEM_RESERVE_PLACEHOLDER, a mask value used for reserving virtual memory as a placeholder, was manually imported for these builds, but incorrectly declared. Thankfully, the fix was as simple as redeclaring it with the correct value, which Toast did in this PR.

Core changes

Meanwhile, Merry tweaked dynarmic to add a new unsafe CPU option. This new option optimizes performance for the 32-bit ASIMD instructions, improving the performance in titles such as Mario Kart 8 Deluxe and Megadimension Neptunia VII.

Floating-point numbers are represented as an exponent in base 2, and a fixed number of significant bits. But there’s a limit to how small a number can be represented as a float, which depends on these significant bits, and the numbers that fall below this threshold are called Denormal Numbers. Depending on the CPU architecture or the instruction performed, these numbers may be ignored and considered zero (called FZ mode, “flush to zero”), while others are capable of operating with these denormal values. This is the case with these ASIMD instructions, whose logic for floating-point operations is different from other instructions in the ARM architecture. To properly emulate the behaviour of these ASIMD operations, which ignore the FZ flag, it is necessary to modify the MXCSR register — which is a very expensive operation — not only once, but twice (to set and unset this flag before and after every instruction). With this change, it’s now possible to toggle this option on and lose some precision in favour of performance.

A few days later, Merry followed up with the affirmation that yes, Apple is indeed a POSIX system.

bunnei continues to work on our kernel, and the highlights this month are related to fixes for a number of bugs in some Pokémon games.

By allocating ServiceThreads per service handler instead of per session, a race condition that resulted in crashes and softlocks in Pokken Tournament DX was fixed.

In the same vein, a crash affecting Pokémon Sword/Shield — also caused by a race condition — was fixed by removing the service thread manager and refactoring the code to use weak pointers. But this wasn’t the only kernel change solving a problem with this game. bunnei investigated our session code and fixed another crash caused by disconnected sessions trying to overwrite a cloned session’s handler. The sessions were also being reserved more times than needed, causing yuzu to run out of available sessions. For this reason, he made sure to remove these redundant reservations to solve the problem.

bunnei also noticed that the error check for CancelSynchronization — used to manage threads — was missing and added it on this PR. This change allows yuzu to avoid a potential crash now, while also making the implementation more accurate.

On top of these kernel changes, bunnei has also been implementing more of the changes introduced by version 12.X.X of the Switch’s firmware, allowing DOOM Eternal to boot with its update 1.5 installed — although the game still requires more work in order to start rendering correctly.

Audio changes

Maide investigated the cause of the crackling and popping in the audio of some titles, and came to the conclusion that not enough audio samples were being fed into the sink in order to be played out in your headset or speakers.

All games call the RequestUpdateImpl() to send samples into the sink and also to pass other information, such as the sampling rate of the audio signal and the sample count (number of samples to be processed). Some titles — particularly those running at fixed frame rate of 30 FPS — would call this function less frequently than their 60 FPS counterparts, which resulted in not enough audio samples being processed in time and sent into the sink, causing the aforementioned annoying popping.

This is how Hellblade: Senua's Sacrifice sounded with the old implementation:

Download the audio instead

By decoupling the processing and sending of audio samples from the update function, the games now will be able to call the update function every time they need it (a process that yuzu can’t control), while a separate audio thread will process the sample data and send it to the sink. With this new implementation, yuzu is now capable of scheduling the rate at which it will be sending this audio information based on the sample rate and the sample count. For example: if a game is using a 48 kHz sample rate with a sample count of 240, yuzu will now send the audio data to the sink at a rate of least 200 times per second — enough to keep the buffers full and prevent these problems with the audio.

And this is Hellblade: Senua's Sacrifice again, now with the current implementation merged:

Download the audio instead

This change fixed the slow audio in titles such as ARK, Bulletstorm, and Megademension Neptunia VII, while also — on top of improving the quality — solving the audio softlocks in Donkey Kong Country: Tropical Freeze and Xenoblade Chronicles 2.

Better audio and stable gameplay! (Xenoblade Chronicles 2 & Donkey Kong Country: Tropical Freeze)

Graphical improvements

Let’s start with something nice, Unlimited FPS! Epicboy implemented a toggle that allows the rendering service, nvflinger, to disable the buffer swap interval limit, allowing the GPU to process frames as soon as they are available, resulting in no FPS limit on games that allow this behaviour.

Beat my framerate!

A default hotkey for toggling the FPS limit was also added, say hello to Ctrl + U! For the best results, Vertical Synchronization (or vSync) should be disabled in the GPU driver control panel, otherwise games will be constrained by the refresh rate of the monitor. Keep in mind, not all games like the setting, some will ignore it, some will not behave well (running faster for example), and some will outright break. Case-by-case user testing applies.

Some examples of games that have full dynamic FPS support are:

Hollow Knight
DRAGON QUEST BUILDERS 2
Dragon Quest XI S: Echoes of an Elusive Age - Definitive Edition
WORLD OF FINAL FANTASY MAXIMA
FINAL FANTASY XV POCKET EDITION HD
Hungry Shark® World
MONSTER HUNTER STORIES 2: WINGS OF RUIN
NEO: The World Ends with You demo
MISTOVER
Crash™ Team Racing Nitro-Fueled
Crash Bandicoot™ N. Sane Trilogy
…and many more

ASTC texture decoding is a complex topic when it comes to emulation, as no desktop graphics card has the required hardware support needed to process these heavily compressed textures. The only exception is Intel with their integrated HD Graphics and UHD Graphics series.

In the past, epicboy implemented a way to accelerate ASTC texture decoding via the use of Compute Shaders, improving decoding performance considerably thanks to taking advantage of the great computing power of modern GPUs.

The issue is that in some games, Astral Chain for example, a synchronization issue caused yuzu to try to access a texture before its decoding was finished, resulting in driver panics and application crashes. Implementing various optimizations and enhancements to the GPU accelerated decoder solved those crashes, even on a simple GT 730, a card 41.5x times weaker than an RTX 2080 SUPER in compute performance.

Now that Project Hades is finished, there are plans to implement performance optimizations on the ASTC GPU accelerated decoder.

Prior to this work, a toggle to disable the GPU accelerated decoder was added for debugging purposes. It’s no longer needed, but if anyone is curious about how much of a difference decoding with the CPU makes, the option is in Emulation > Configure… > Graphics > Accelerate ASTC texture decoding.

By avoiding creating image views for blits for different bytes per block, Rodrigo solved crashes experienced with Unreal Engine 4 games on Vulkan.

Speaking of blits, vonchenplus found that our previous way of handling out of bounds texture blits wasn’t accurate enough, causing rendering glitches in games like DRAGON QUEST III The Seeds of Salvation. Adding an offset to the source texture address puts this bug to rest.

No more acne! (DRAGON QUEST III: The Seeds of Salvation)

Some games running in Vulkan, like Super Smash Bros. Ultimate or A Hat in Time, can cause loops decoding textures, resulting in Out of Bounds access on an array, potentially leading to a crash, and breaking our Flatpak support. As preemptive work, toastUnlimited added a break safeguard, and now Flatpaks work as intended. Having less crashes is always better, right?

General changes and bugfixes

discord-rpc, the submodule in charge of handling Discord’s Rich Presence “Now Playing” feature, was updated by Vortex to the last version before it was deprecated in favour of a closed-source alternative named GameSDK which, of course, we can’t use. Since discord-rpc still is compatible with Rich Presence, this update should provide more stable reporting in your Discord Status.

Vortex also updated httplib, removing the need for previous fixes, solving issues with token verification and Compatibility Report uploading.

We previously mentioned Flatpak support. liushuyu requested that Flathub add yuzu to their repositories, officially providing another installation option for our Linux users.

Maide implemented the GetAudioOutPlayedSampleCount service, making Ninja Gaiden series games playable!

Ninja Gaiden series

german77 has been having fun rewriting how analog input is handled by yuzu. The old method handled each analog joystick in a separate thread, periodically updating the angle held by the user. This is not only imprecise, but also slower and was found to cause data races, eventually leading to random crashes.

By removing the need for separate threads, and using timestamps the game can consult at its own request, the data race is avoided. This eliminates the crashes, results in considerably smoother movement, and lowers resource utilization, helping performance. A victory in all scenarios!

Thanks to changes made upstream, toastUnlimited was able to update the SDL version in use, resolving crashes experienced by Linux users right when opening yuzu.

kilaye has been giving us a hand in an often forgotten area of yuzu, the yuzu-cmd binary, which is intended as an SDL2 alternative to the most commonly used yuzu Qt interface binary. OpenGL wasn’t rendering due to recent changes applied, and a bad initialization of touch_from_button was causing crashes. All were fixed thanks to kilaye’s work.

While on an SDL2 rush, kilaye also implemented an SDL2 audio backend as an alternative to our default cubeb backend. More work is needed to refine its performance and end-results, but having an easy-to-maintain, multi-platform backend is never a bad idea.

Filesystem changes

toastUnlimited has been working along with morph to improve the experience of using the Ultimate Mod Manager application with yuzu — a tool that allows one to mod Super Smash Bros. Ultimate. First, toast added an option in the context menu of a game to support dumping the RomFS to the SDMC subdirectory, while morph made the necessary changes for this setup to work.

New users intending to use UMM only need to right click the game in yuzu’s game list and select Dump RomFS > Dump RomFS to SDMC.

While working on new debug options for the filesystem emulation, Morph also fixed certain DLCs that used to make Xenoblade Chronicles 2 fail to load at boot with the previous implementation. You can now run the game without major issues, even when fully updated.

When dumping RomFS to disk, there has to be enough free space. Morph added a check to avoid users trying to dump without enough room.

Due to a bug in the Microsoft Visual C++ (or just MSVC) compiler, a crash could happen when trying to access folders recursively in order to load game dumps in yuzu’s game list. Morph fixed it by replacing the recursive_directory_iterator class with the directory_iterator class.

UI changes

Some changes have been done to the title bar by epicboy. To begin with, games will now display if they are built for the 32-bit or 64-bit instruction set. This will help determine when Unsafe CPU should be used to get the previously mentioned performance optimization.

Additionally, the GPU vendor will now be displayed too. This is not only for debugging purposes or providing better support to users, it also clarifies which driver is in use on systems running multiple GPUs. One would think there are only 3 vendors per API, but that’s far from reality. By checking the list, you can see there are many different reported vendors for different needs, including CPU software rendering drivers.

For their first Pull Request with yuzu, OZ corrected the size of the Per-Game configuration window and removed the useless “help” button in the top right corner.

Thanks OZ!

toastUnlimited added a new option to the right click context menu on any game in yuzu’s game list. You can now right click a game and launch it with any custom per-game configuration you may have, or with the current global settings.

Quick way to test two different sets of settings

Column sizes in the game list used to constantly resize during updates or DLC installation to NAND, resulting in an extreme width that made the game list uncomfortable to use. Maide put a stop to this, improving the quality of life of our UI.

Kewlan is back at it, this time preventing users from inputting invalid characters in text windows, for example when creating a new Input Profile.

No more 1337 talk

Future projects

With Project Hades (our new shader decompiler), Rodrigo continues with his crazy experiments, bunnei has yet more kernel changes in the oven, and german77 and Morph continue to work on their top secret projects.

More GPU related optimizations are underway, and users should keep a keen eye on the horizon.

That’s all folks! As always, we hope you keep enjoying yuzu. See you next month!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

New Feature Release - Shader Decompiler Rewrite

CaptV0rt3x — Sat, 10 Jul 2021 03:40:00 +0530

Greetings, yuz-ers! The long awaited day is finally here. We are very excited to present to you, Project Hades, our shader decompiler rewrite! This massive update includes huge performance improvements, countless bug fixes, and more. Let’s get started!

Project Hades is now available in the latest yuzu Early Access build. As always, we ask that you test various games with these builds and if you encounter any issues, bugs, or crashes, please reach out to us via the Discord Patreon channels.

Notice

The entire shader generation process has been redesigned from the ground up, thus existing shader caches have been invalidated. Users will need to build their shader caches again, from scratch, with Project Hades.

What is Project Hades ?

Project Hades is the codename for our shader decompiler code rewrite, although at this point it’s become much more than that.

For those who don’t know what a shader decompiler is, you’ll need to understand the process of how games render (show/display) anything. Shaders are special programs that are coded to perform various tasks on GPUs, typically relating to rendering graphics on display. Shaders are usually written in high-level shader languages compatible with the graphics API in use - e.g. OpenGL Shading Language (GLSL), Standard Portable Intermediate Representation - V (SPIR-V), and OpenGL ARB Assembly language (GLASM). Games often use hundreds or thousands of these shaders to tell the GPU what to render and how to do it.

yuzu Shader Generation

In the case of Switch games, they also use shaders to render graphics on the Switch itself. However, since these shaders are precompiled for the Switch’s GPU, yuzu cannot use them directly to render graphics using the host GPU (User’s GPU). Therefore, yuzu first decompiles these shaders into something called IR, or Intermediate Representation, which is then used to generate the high-level GLSL/SPIR-V/GLASM shaders used by the graphics APIs and drivers to render games on the host GPU.

Shader decompilation is the process of translating the guest (in this case, the Nintendo Switch) GPU machine code to a representation that can be compiled on the host (User’s PC) GPU. Shader compilation is the process of taking that representation and sending it to the host GPU driver to get compiled and then executed on the user’s GPU.

Goals

The main goal of Project Hades was to redesign the decompiler and shader generation code with a focus on simplicity and accuracy. It aimed to make both decompilation and compilation faster overall, thus improving the performance. Rewriting the decompiler would allow us to audit it through unit testing, following a design similar to dynarmic, allowing proper program analysis and optimizations over fast-to-emit intermediate representation.

Dark Souls

Dragon Quest XI

Taking a leaf from dynarmic’s book, the developers opted to use an SSA representation, as it would work very nicely with the SPIR-V IR used for shaders, thanks to its native support for SSA. As for the unit testing, Rodrigo wrote homebrew tests for the hardware which helped the developers accurately emulate hardware behaviour.

But this was just the beginning. Over the course of a few months, the developers would go on to face and overcome many hurdles with the code rewrite and the Project’s goals would expand to accommodate much more.

Overview of changes

Project Hades was a collaborative effort from developers Rodrigo, Blinkhawk, and epicboy. They distributed the required work among themselves and spent countless hours in coding, unit testing, game testing, and performance validation.

Blinkhawk mainly worked on implementing miscellaneous instructions, including texture sampling instructions required for decompilation. He added support for Nvidia’s VertexA shader stage, a non-standard shader stage available on Nvidia hardware that is executed before the regular VertexB shader stage.

This allowed games such as Catherine: Full Body, Bravely Default 2, and A Hat in Time to render graphics for the first time. Blinkhawk also fixed an issue in yuzu’s texture cache relating to the texture streaming used in Unreal Engine 4 (UE4) games, resolving many of their rendering issues.

Note: Due to a race condition in our GPU Emulation, to render Catherine Full Body correctly, you may need to disable Asynchronous GPU Emulation.

Catherine: Full Body

A Hat in Time

Bravely Default II

epicboy implemented almost all of the arithmetic, logical, and floating-point instructions, as well as developing the entire GLSL backend. GLSL is the default backend, when the OpenGL API is selected in the yuzu configuration settings.

The GLSL backend rewrite was not part of the initial plan for Project Hades, as the developers only intended to work on GLASM and SPIR-V, but it was later included due to how buggy and slow some OpenGL SPIR-V compilers are. That said, some OpenGL drivers benefit greatly from the use of SPIR-V shaders, so the choice of using SPIR-V on OpenGL is left as an experimental setting.

Mario and Rabbids

Monochrome

Rodrigo designed the overall structure to support these changes, and developed multiple optimization passes to improve performance wherever possible. In addition to that, he rewrote the entire GLASM (GL Assembly) backend, and integrated the existing frontend rasterizers with the new backends.

The GLASM backend is a special path where the decompiled shaders (assembly language) skip the shader compilation steps on the host GPU, thus improving the performance. Unfortunately, GLASM is only supported by Nvidia GPUs, limiting the scope of this performance boost.

Crash Bandicoot 4

World of Final Fantasy

While these were the major changes, there were also many other minor improvements. Changing how the shaders are generated also meant changing the way shader information is presented to the renderers. This was overhauled for simplicity, which led to some new features, and ease of caching.

Vulkan Pipeline Caching

All the information required to generate pipelines from scratch now gets cached to disk, thereby removing shader stutter almost completely on Vulkan. In contrast, OpenGL can still encounter shader stutters due to unpredictable or undocumented state changes. Vulkan still can have minor stutters when new shaders are detected, but it hasn’t been noticeable during our testing.

Asynchronous Pipeline Creation

yuzu already supported Asynchronous Shaders, where draw calls are skipped (rendering is paused) until the shader, or in Vulkan’s case, the pipeline, is compiled. This is nice in some cases because it allows for more consistent play sessions, minimizing stutter from shader compilations. But this also has a big drawback: it introduces graphical glitches, which are sometimes persistent throughout the play session. While this is not an issue after restarting emulation and having the shaders cached, it’s not optimal.

A better way to implement this for Vulkan was to build pipelines in parallel without skipping draw calls. In other words, continue processing GPU commands while the pipelines are being built. This allows building one pipeline per CPU thread (minus one) in parallel while the game is executing. This results in reduced stutter that is, in a way, similar to skipping draw calls.

How does this work?

To understand why this is possible, it's necessary to explain how yuzu's Vulkan command recording works. Commands are recorded and deferred to a separate thread for processing (sometimes called the "Command Submission (CS) thread").

This thread runs in parallel to the main GPU thread. This means the CS thread can build the pipelines sequentially while the main GPU thread continues its execution, periodically pushing new commands to the CS thread.

Sadly, this is not possible at the moment on OpenGL, because drivers wait more often for their CS thread than yuzu on its own CS thread. It may be possible if we optimize the whole OpenGL backend to avoid "glGen*" and "glGetSynciv" calls within a draw call.

Even more!!

On top of these big improvements, we also have many minor optimizations. Some notable ones are listed below:

Project Hades keeps track of the number of bytes used in constant buffers and passes this information to the buffer cache. This reduces the number of uploaded bytes on some titles, thus improving performance.
Vulkan command submission to the GPU now happens on the separate CS thread, increasing performance by 1 to 2 FPS in Super Mario Odyssey, although presentation to screen is still being synchronized.
Synchronization for texture buffers between the texture cache and the buffer cache, fixing some crashes on Koei Tecmo games.
Generate specialized Vulkan descriptor pools, sharing pools within similar pipelines. This reduces memory consumption and boot time on most drivers, saving ~700 MiB of VRAM on AMD compared to the previous approach.
Usage of VK_KHR_push_descriptor when available. Reduces the overhead of updating descriptor sets on Nvidia by 57% and by 10% on Intel (measured on Super Smash Bros. Ultimate 1v1 on Final Destination). It also reduces memory consumption but this hasn’t been measured.
Usage of VK_EXT_conservative_rasterization and VK_EXT_provoking_vertex when available.
Use specialized “pre-draw” functions per pipeline to reduce unnecessary work.
Texture Reaper, which cleans the least used resources in your VRAM to reduce VRAM usage. We will cover this and others, in detail, in our next progress report.

Graphical fixes

Thanks to the redesign and reimplementation of our entire shader generation code, the developers were able to investigate and identify the causes for graphical glitches in many games. In fact, some games like Yoshi's Crafted World, Trials of Mana, Minecraft Dungeons, and many others, now render almost perfectly. The Legend of Zelda: Breath of the Wild is now fully playable on Vulkan.

Breath of the Wild (fixed runes in Vulkan)

The Legend of Zelda: Breath of the Wild (EA Vs. HADES)

Yoshi's Crafted World

Bravely Default II

Minecraft Dungeons

The broken bloom, causing sand and fog in Super Mario Odyssey to render incorrectly, is now fixed!

Super Mario Odyssey (EA Vs. HADES)

Thanks to the implementation of tessellation shaders, the sand in Luigi's Mansion 3 is no longer broken!

Various graphical glitches, crashes and general stability issues in Fire Emblem: Three houses, Hyrule Warriors: Age of Calamity, Marvel Ultimate Alliance 3, Persona 5 Strikers, and Xenoblade Chronicles were also fixed.

Fire Emblem: Three Houses

Hyrule Warriors: Age of Calamity

Marvel Ultimate Alliance 3

Hyrule Warriors Definitive Edition

Persona 5 Strikers

Xenoblade Chronicles (EA Vs. HADES)

Hollow Knight's issue with transparent textures has been fixed.

Hollow Knight (EA Vs. HADES)

Kirby Star Allies, Mario Kart 8 deluxe, Tony Hawk Pro Skater, Story of Seasons, and Clubhouse games, were among many other titles that saw graphical glitches fixed. Rune Factory 4 renders perfectly now and Rune Factory 5 has improved rendering.

Kirby Star Allies (EA Vs. HADES)

Mario Kart 8 Deluxe (EA Vs. HADES)

Tony Hawk Pro Skater (EA Vs. HADES)

Story of Seasons (EA Vs. HADES)

Rune Factory 4 (EA Vs. HADES)

Rune Factory 5

Trials of Mana

Clubhouse

Farming Simulator 20

And many more!!

Densha de Go

Final Fantasy XII

Hellblade: Senua's Sacrifice

Spyro Reignited Trilogy

Alright! Let’s talk numbers now!

Project Hades rewrote a vast majority of the GPU code and made tons of improvements and optimizations to boost the performance. Since the changes touched on many areas of the GPU emulation, we observed performance improvements in many titles.

Below are some performance comparison charts between yuzu Early Access (1860) and Project Hades on our recommended specifications using Vulkan API. Please note that at the time of comparison, EA 1860 was almost equivalent to yuzu Mainline, with no changes that would significantly affect performance.

Recommended Specs (* is OpenGL)

That’s not all. The improvements made to the Vulkan backend in Project Hades have greatly improved performance for AMD GPU users on Linux (RADV).

Linux AMD (RADV)

These are just a small testament to the performance improvements that Hades brings. We will be sharing more performance charts with our next progress report.

Fin

Our development efforts were massively accelerated by our testers, who tested dozens of titles for bugs, fixes, and performance regressions. Since our testing couldn’t realistically cover all titles, we request that you test and play your favourite games in yuzu and experience the improvements yourselves. While testing, if you come across any regressions, glitches, bugs, or crashes, please reach out to us via our Discord Patreon Channels. This will assist us in identifying and fixing any potential issues Project Hades might present.

That’s all we have for now, until next time! Happy emulating!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report May 2021

GoldenX86 — Thu, 10 Jun 2021 12:00:00 -0300

Hola yuz-ers! It’s time yet again for another progress report! We have dozens of changes to discuss: Kernel fixes, input and UI improvements, graphical updates, the saga of the legendary dot, and even a method to procure extra VRAM!

Pokémon Snap, but it’s New

New Pokémon Snap’s release resulted in tons of work needed to make the game playable. For starters, Snap experienced crashes during gameplay, an issue epicboy was not happy about. The buffer cache rewrite introduced an optimized fast path for uniform bindings, but the conditions to take advantage of it are that buffers must be both small and non-null. Turns out, null buffers were not being explicitly checked for, causing instabilities along the way. Properly checking for those zero sized buffers fixed the stability issues the new Snap was facing.

New Pokémon Snap

Morph has been working hard on implementing much needed fixes in yuzu’s file system emulation. In this particular case, improving the accuracy of CreateFile fixes the saving and loading issues Snap was experiencing. Unexpectedly, the error codes of conditions like “parent directory doesn’t exist” or “path already exists” were incorrect, causing havoc in the file system emulation.

Snap also revealed flaws in our touch screen gesture emulation. Thanks to work done by german77, yuzu now properly supports multiple fingers.

GPU emulation related issues stop this game from being perfectly playable. In its current status, photos are not recognized when they are evaluated at the end of a stage. Like mother, like daughter. This can be partially solved by using High GPU accuracy in OpenGL with Assembly Shaders enabled, or for non-Nvidia users, using Extreme GPU accuracy on Vulkan.

Graphical fixes

Texture blits (bit block transfers, a combination of bitmaps) can sometimes work out of bounds by interleaving copy regions, by design. yuzu has to be able to properly emulate this behaviour and return the correct portion, something epicboy had no problem properly implementing for us.

Here’s a beautifully detailed example of the old out-of-bounds incorrect behaviour in red, and the correct result in blue, with the affected area moving to the next row, as it should

The result is quite noticeable in games that use this blit technique, such as Shantae and Pixel Game Maker Series Werewolf Princess Kaguya, which we mentioned in the previous progress report.

Textures and text rendering correctly, notice the stairstepping on the right side of the left image

Thanks to user reports, it was brought to our attention that our FPS counter in the lower right corner of yuzu’s window was not accurate. The readings were previously accurate when the GPU thread was synchronous with the other services. Now that asynchronous GPU emulation is implemented, this is no longer the case.

The solution epicboy came up with is, instead of letting the nvflinger service handle the counter, let the graphics API inform the counter after it finishes drawing the frame. This way, the value is far more accurate and stable on performance oscillations. Additionally, the update frequency of the counter was changed from 2000 ms to 500 ms to allow for more frequent and up-to-date information to be displayed.

And now for a big update for Vulkan users waiting for Project Reaper to leave the development board. The previous Vulkan memory allocator used local memory as top priority (that’s the physical VRAM on your dedicated GPU), and only used host memory in certain applicable cases. These cases varied depending on how the GPU driver informed the different memory heaps available to yuzu, primarily in keeping critical required information closer to the CPU.

Rodrigo implemented a new method (solving some issues with the old one) that allows yuzu to access all the available host memory. Up to 50% of the total system RAM is available to the GPU as host memory, or as Windows calls it in the Task Manager, GPU shared memory. This change means that the GPU effectively has more RAM available to use with Vulkan, helping delay our sadly infamous out-of-memory issues with this API.

For those that can’t wait, want to test an in-development partial solution, and have experience with git, Maide has been working on what can be called a “light Reaper”. This is a simpler version of what Rodrigo plans to release in the future, working as a garbage collector on a configurable fixed timer. For anyone interested and with the time to spare in building yuzu manually, the PR is open to be tested. We don’t plan to merge it for now as it needs as much refinement as the regular Reaper to provide a pleasant user experience.

bunnei removed the risk of an overflow in the rasterizer cache by doubling the size of the responsible array.

The Nintendo Switch shares its RAM with both the CPU and GPU, so games are free to assume any information in VRAM will be the same in RAM (since it physically is). As PCs don’t allow this (even on integrated GPU systems), yuzu has to keep track of any memory pages in use by the GPU to ensure that all information is also reflected in system RAM. The previous limit of 255 references was observed to be surpassed in some rare instances during testing, resulting in utter chaos, so this PR increases it to a maximum of 65535.

All of this costs the user 2MB of RAM instead of the previous 1MB. Such a heavy price to pay for the additional peace of mind, Google Chrome would be proud of us.

Core changes and improvements

bunnei migrated our old implementation of kernel objects to KAutoObjects, which is part of the newly written implementations that have been added in the past months to match more closely to that of how the kernel of the Nintendo Switch works.

Previously, our kernel objects, such as condition variables, events, threads, processes, etc., used the C++ std::shared_ptr (a type of smart pointer) in their implementation. Whenever a new instance of a shared pointer reference is made using one of these pointers, a counter is automatically increased to keep track of them. Similarly, whenever one of the references isn’t needed anymore, the counter decreases its value and the reference is discarded. However, the implementation doesn’t necessarily reflect the way the Nintendo Switch’s kernel deals these objects and their reference counters. Thus, the advantage of implementing these KAutoObjects is that it allows yuzu to manage when these objects are created and destroyed, accurately.

This was a big change that involved refactoring the codebase for consistency and fleshing out the implementation of various existing kernel objects and their definitions to match the new behaviour correctly.

Part of the work also involved improving some system calls (the so-called SVCs) by implementing missing calls such as UnmapSharedMemory, and making the implementation of other calls more robust (e.g. better error checking, etc.). These SVCs are functions used by games to communicate with the rest of their system, in order to create events, manage them, or send information to other services such as audio and graphics. They are essential for the communication between processes and the OS, so their correct functioning is imperative, as they are the programs that run whenever a game needs the kernel to perform operations that require elevated permissions.

With the introduction of the firmware version 12.0.0, the protocol of Inter-Process Communication (IPC) has also been updated. bunnei worked on various improvements to the IPC and session management with the aim to support TIPC — the new protocol.

IPC is a mechanism provided by the OS and used by processes to communicate between themselves, usually to manage or cooperate in the processing of some shared resource — such as a memory region, a file, etc. A session in this context refers to an object that is created to manage the information exchange between a client (i.e. games) and a server (services that the game uses to render graphics, play audio, get user input, etc.). With these changes, the code in charge of session management has been updated to support the new IPC protocol, additionally fixing a number of inaccuracies in some of the error-checking functions. bunnei has also greatly simplified the original IPC code, which should improve the memory usage and performance of these operations.

As a consequence of the changes introduced in the previous KAutoObject PR, the maximum values for many of the kernel objects have started to be enforced. This resulted in crashes in games that open and close sessions often, such as Nintendo Labo, Pokémon Sword, and Pokémon Shield, due to yuzu not managing sessions correctly. The root problem was also the cause of small memory leaks that hadn’t been noticed until now, since the sessions weren’t being properly closed and remained in memory. For this reason, bunnei implemented mechanisms for moving and closing objects in a follow-up PR, which corrected the way the session counter and its opening and closing operations worked.

There are still many other kernel objects to migrate and, for this reason, bunnei introduced a PR to make the KSlabHeap use both guest and host allocations, as this will facilitate the process while missing functions and other structures are being implemented.

Simply put, the slab heap is a structure used to store kernel elements more efficiently in memory in a linked list, based on their size. All the slots in a slab of memory have the same size, and there can be lists of different sizes to store different objects too. Instead of allocating and deallocating memory, the kernel marks the nodes on the list as “used” or “free,” so when it needs to store a new object, it looks for a free slot and overwrites the data there. On the other hand, if an object is not needed anymore, the node where it’s stored is marked as “free” so that it can be used to store a new object. This way, the kernel will find frequently-requested memory sizes available more quickly, providing a small optimization to the whole process.

As of yet, yuzu doesn’t emulate the complete memory structure of the Nintendo Switch. The emulated memory space only provides enough functionality to run a single process (i.e. a game), while every other service, such as the kernel, is allocated outside of the virtual memory. This implementation works because the games aren’t allowed to access kernel memory, and so, when yuzu switches from executing a game to running some kernel procedure, it just handles this internally through the High Level Emulation (HLE) implementations, with the games completely oblivious to where any of said procedures are stored. However, there are certain elements that the games actually need to access, and so, they must be inside the emulated memory. One such case is the Thread Local Storage (TLS), a memory region used by the emulated threads to store variables that only they see, but none of their peers have access to — because a thread can access only its own TLS region. Since these entities can be allocated in the KSlabHeap, along with other entities that don’t need to be inside the emulated memory accessible for the games, bunnei introduced this hybrid method so yuzu is able to manage the slab list for all kernel objects, regardless of whether they need to be HLE’d, or stored in the virtual memory.

Of course, there are still many other things to flesh out and implement. The kernel is an essential part of the system that makes it possible for everything else to work. Any improvements and additions to this component make the emulation experience more robust and solidify the accuracy of how the emulator works.

Morph has also been paying attention to the kernel, refactoring part of the IPC code and adding a function to pop the ID of a process, fixing a small bug where a wrong value was being returned, and stubbing a function for the memory manager.

However, the real poyo-pearl of this month has been his rework of yuzu’s Common File System Interface to make use of the std::filesystem library introduced in C++17, as a continuation of the work done by the maintainer lioncash.

The file system interface is the code that controls how yuzu accesses files (e.g. the creation of save files, or how yuzu loads DLC and update files for a game, etc.). Since yuzu originally started as a fork of Citra, there were many functions inherited from that project that weren’t as new as the ones included in this newly added library, or weren’t compatible with the new Virtual File System that yuzu uses, or simply weren’t used at all.

With this huge PR, after Morph reversed-engineered the file system in order to bring yuzu’s behaviour closer to how it works on the Nintendo Switch, he removed the clutter in favour of simpler code and rewrote the whole implementation, fixing some problems that the old code had in Windows builds in the process. As a bonus, he also documented all of yuzu’s file system functions.

While these changes don’t necessarily result in a performance increase for end-users, they have certainly tackled some long-standing problems with how yuzu handled files, besides simplifying the codebase notably, making it much easier to read and maintain for our developers.

On-Screen Keyboard changes

Morph has been working hard on fixes for the software keyboard.

Games received the text string of the inline keyboard instead of the regular one, resulting in empty fields being sent which could cause games to panic, as it would mean an invalid entry was sent. Fixing this only required sending the correct information from the right keyboard type.

Users reported crashes when pressing Enter after naming a ruleset or controller layout in Super Smash Bros. Ultimate. As it turns out, the QLineEdit::returnPressed signal generated a race condition, resulting in the crashes. Switching to Qt::QueuedConnection solved the issue.

Additionally, testing confirmed that games can leave regions of memory uninitialized if a text check is performed and doesn’t result in either Failure or Confirm, causing, once again, crashes. This is fixed by reading only the text check message.. Thanks to gidoly and OZ for all the help in finding this!

Lastly, there was an issue where the mouse input is captured by the software keyboard until the user moves to the next event. german77 fixed this by releasing the mouse input when yuzu is out of focus.

General bugfixes

Let’s begin this section with an obituary. Keen-eyed users may have noticed that old builds used to have a single . dot at the end of the title bar. A suspicious dot whose purpose was unknown.

The Legend

When resuming an old quest that was previously left unfinished, epicboy, while working on displaying the game version on the title bar, found the code related to the existence of the dot, and decided to slay it.

Of course, the dot wouldn’t be gone without a fight, and removing it caused the yuzu version info to disappear from logs and even the “about us” window! Morph was the next hero of light selected by the king to slay the monster, and so he did.

And thus, the saga of the mysterious dot ends, for now.

Speaking of sagas, ogniK works in ways beyond our comprehension. An open PR about allowing yuzu to set a nickname for the emulated switch and implementing the DisableAutoSaveDataCreation service are some of the surprises The Shark left us. By the way, that last service? It’s used by Mii Edit.

Morph stubbed the ´ImportClientPki´ and ´ImportServerPki´ services, making JUMP FORCE Deluxe Edition boot. Project Hades will help make this game playable.

Thanks, Ghost, for the pics! (JUMP FORCE Deluxe Edition)

bunnei fixed a hang on shutdown in the NVFlinger thread (used for compositing), fixing hangs when stopping emulation while playing Super Mario Odyssey. You not only have to let’s-a go, Mario, but also let’s-a stop sometimes.

While yuzu allows users to install anything to NAND, be it updates, DLC, or even the base game, we recommend that only updates and DLC be installed, leaving yuzu to find the base game with the user provided locations of the game dumps. Morph properly blocked this, and added a warning that accompanies it.

Besides what was mentioned earlier in the article, Shantae took a bit of extra work to become playable. Another case of an emulator inside an emulator. epicboy solved a softlock at boot by creating layers when queried but not found in the compositting service NVFlinger and ogniK fixed the crashes by stubbing the emulation of nvhost-prof-gpu.

Your browser doesn't support mp4 video. :(

Atta girl! Thank you OZ for the gameplay! (Shantae)

Linux deserves some love too, and toastUnlimited shall give it. linuxdeploy introduced a regression that caused any file open dialog to crash yuzu if you ran one of our official AppImages. toast solved it by downloading our own version hosted as one of our externals, allowing us to have better control on changes to linuxdeploy, as well as fixing the crashes. Users can enjoy the ease of use of AppImage releases again.

An old limitation we faced with Linux Distributions that decide to “stay on their old and trusted packages” is outdated versions of the Qt binaries. By setting up version 5.12 as the minimum requirement and adding 5.15 to our externals, we can ensure that no problems are faced when building yuzu with any of the valid compilers, be it MSVC, GCC, Clang, or even MinGW.

UI and other Quality of Life improvements

Users have the option to customize the game list via Emulation > Configure… > General > UI, and the Add-Ons column can be disabled there. Previously, if the user disabled it, the game list was not being refreshed, forcing the user to find inventive ways to manually do it. Thanks to Kewlan’s work, the game list now properly refreshes itself with no need for manual intervention!

Add-Ons shows which update, DLCs and mods are installed and enabled

toastUnlimited reluctantly added the CPU tab to per-game settings. At the same time, Custom RTC (Real-Time-Clock) was removed to force it as a global value.

Totally not a hint of anything

While we’re on this subject, some things need to be clarified about the CPU settings tab. Unsafe was originally only intended for CPUs that lacked the FMA instruction set, which causes games to run at very low framerates. Later on, a fix was discovered that could boost the performance of Luigi’s Mansion 3 by reducing precision. This was described in January’s progress report.

As a result, we recommend users of CPUs that do have FMA to stick to Accurate and only force Unsafe for Luigi’s Mansion 3. Using Unsafe is known to cause precision issues, for example, exaggerating the hitboxes of characters in Super Smash Bros. Ultimate. Users with old or low-end Intel CPUs that lack FMA, feel free to keep Unsafe enabled all the time.

We provide some examples in the following gorgeous and totally perfect table:

CPU series	FMA support	Recommended setting
Intel Core 4000 to 11000 series	Yes	Use Accurate, Unsafe for LM3
Intel Core 500 to 3000 series and older	No	Use Unsafe
Intel Atom, Celeron and Pentium series	No	Use Unsafe
AMD Ryzen series	Yes	Use Accurate, Unsafe for LM3
AMD FX and A 4000 to 9000 APU series	Yes	Use Accurate, Unsafe for LM3
AMD Phenom, A 3000 APU series and older	No	Use Unsafe

*LM3 = Luigi’s Mansion 3

toastUnlimited also gave us the option to apply settings while games are running. This can allow users to more efficiently test settings while playing. Keep in mind that settings that require a reboot to take effect won’t be affected by the apply button.

Continuing with the per-game setting improvements, toast also added an exception for homebrew. Since most homebrew use a game-ID of 0000000000000000, using the ID to save the per-game settings would have been useless, so instead, yuzu will use the name of the homebrew file.

And finally, toast, continuing work from german77 and Tobi, added a button to reset yuzu settings to default.

Simple as that

This is sometimes needed in very rare cases, for example, when being unable to boot Super Smash Bros. Ultimate.

Shake it, baby

german77 has been working on implementing SDL motion, with the purpose of removing our dependency on third party programs to get motion input from valid controllers like Dual Sense, Joy-Cons, or Pro Controllers. With this PR, users can simply pair their controllers via Bluetooth and yuzu will pick them up as a valid input device, auto-mapping and enabling motion support, effectively removing the need to use betterjoy, ds4windows, or other third party software in yuzu.

A separate PR adds detection of two separate Joy-Cons as a single input device.

And to provide motion support on the Linux side, v1993 enables the use of HIDAPI within SDL2.

Work continues to fine tune how the sensor data is interpreted, specially from non-Nintendo devices. For example, PS3 controllers operate motion on a single Z axis, but report the remaining 2 axes to the operating system with useless NaN values, making any motion calculations useless. By replacing the X and Y axis values with zeros, german77 solved the issue.

Games don’t always check for obvious physical limitations. For example, in the past, it was possible to use handheld controller emulation while the game was in a docked status. Doing this can break games like Xenoblade Chronicles 2, as the game expects the console to disable input when the Joy-Cons are connected to a docked Switch’s rails. german77 solves this by forcing an emulated Pro Controller instead. No more weird Frankenstein input monstrosities, please.

Finally, it could sometimes be difficult to map analog sticks in yuzu due to a bug in how the event was handled. While fixing this, german77 also fixed a crash caused by controllers not listed in the controller list disconnecting.

Future projects

Now, I know we keep teasing Project Hades, but we have good news! SPIR-V is finalized, GLASM is in its final testing, and GLSL is not far behind. Few regressions remain to be squashed. Once the shading languages are done, previous features like the old asynchronous shaders are reimplemented, and the fine tuning is finished, it will finally be released. We’re trying to release it alongside Reaper, but time will tell.

MARVEL ULTIMATE ALLIANCE 3: The Black Order, WORLD OF FINAL FANTASY MAXIMA, Yoshi's Crafted World

That’s all folks! Thank you so much for staying with us until the end of this month’s progress report. See you in the next one!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

New Feature Release - Fastmem Support

CaptV0rt3x — Tue, 08 Jun 2021 04:00:00 +0530

Hey there, yuz-ers! While all of you wait eagerly for the release of Project Hades, our shader decompiler rewrite, we thought we’d bring you a nice little surprise to keep you occupied. We present to you, the newest addition to yuzu’s ever-improving features list - Fastmem (Fast Memory Access)!

This is now available in the latest yuzu Early Access build (1759 or newer) and we intend to make this available in Mainline builds very soon. As always, we ask that you test various games with these builds and if you encounter any issues, bugs, or crashes, please reach out to us via the Discord Patreon channels.

Note: This feature is enabled by default.

What is Fastmem?

Fastmem or Fast Memory Access, is a well-known feature among emulator developers and emulation enthusiasts. Emulators like Dolphin and Citra Android have implemented this in the past.

All modern Operating Systems have this concept of “virtual memory,” where addressable memory (from the running process) is a space of memory addresses that are only “known” to that process, e.g. Discord on your PC, or Super Mario Odyssey on your Switch — and the addresses are translated by the Switch’s MMU (Memory Management Unit) to the physical location in the Switch’s physical RAM as the game runs.

Illustration of an MMU (By Mdjango, Andrew S. Tanenbaum)

In yuzu, we emulate the Switch’s virtual address space for the running process. But, that means for each time the game tries to read/write memory, which happens millions of times per frame, we need to basically “decode” where that Switch virtual address maps to our “emulated” Switch memory (RAM allocated for yuzu). This adds a lot of overhead when you consider how much the game reads/writes to memory.

The idea behind Fastmem here is to map the emulated Switch game’s addressable memory on the host (Windows / Linux), at offset addresses. The offset is a constant.

The Technical - HOW?

On the Switch, we have 4GB of memory. The hardware supports a virtual memory size of 48bits (just like x64); however, the Switch kernel limits this to only 39bit to save some memory for storing page tables. This results in a 512GB virtual address space (2^39) for use. (A page table is the data structure used to store the mapping between virtual addresses and physical addresses.)

To emulate this, we allocated a HUGE page table, which had an offset for each memory page addressable in the virtual memory region of the Switch. This table alone was 1GB in size! And whenever a game wanted to access the memory, we looked up this table, which resulted in roughly ~10 x64 CPU instructions and twice the memory latency. That latency being: first read the table’s value, then read the correct memory.

Fastmem, however, uses the host MMU to rebuild the same 39bit virtual memory arena. Here, we’re lucky that Nintendo limits the memory to 39bit. We cannot allocate 48bit because that’s the entire virtual address space on the host.

This cuts the effort to access the memory down to 3+1 x64 CPU instructions with a single memory latency. 3 instructions to check if the pointer is smaller than 39 bit, and one memory load instruction. We need this size check to ensure out-of-bounds memory access won’t return any physical address.

The Challenges

Implementing Fastmem required two major things in Dynarmic, our JIT recompiler.

First: A64 Fastmem support on Dynarmic.

Dynarmic has had support for A32 Fastmem (see Citra Android) for a while now. A64 Fastmem support was originally worked on a year ago by MerryMage and vdwjeremy but it never got merged to the master branch.

degasus worked with MerryMage to clean up and get these changes merged to the master branch so that yuzu could benefit from this.

Second: To generate the 512GB virtual address space with the same mappings as on the Switch.

degasus proved last year that this was easy to implement on Linux as the POSIX mmap call provided very similar features to the Horizon OS. But it was a huge challenge for Windows, as the Windows Virtual Memory API is larger with a few missing features. Moreover, while Windows page tables were 4K aligned, Windows memory management was 64K aligned for outdated reasons.

The Solutions

Turns out, Microsoft had realized this too and frequently patched their Virtual Memory API. With the release of Windows 10 v1803, their new API supported new “placeholder” memory which didn’t suffer from the previous limitations.

Thanks to Breadfish64, who used this new API in their Gameboy emulator and showed us that it was now indeed possible to support Fastmem on Windows. Unfortunately, this makes the feature usable only on Windows versions 1803 and higher.

Since we already met the base requirements for our new Fastmem implementation long ago, our devs were able to quickly address the missing pieces. bunnei implemented the much-needed kernel rework changes in yuzu, degasus cleaned up their original proof-of-concept code for Linux, and Rodrigo implemented the Windows Fastmem support. Blinkhawk provided valuable advice and coordinated these efforts to get the feature release-ready.

The Results

As an added bonus, game booting/loading times have been improved thanks to these changes. Thanks to developer Rodrigo, Normal GPU accuracy no longer triggers a myriad of exceptions on the Smash character selection screen, improving its performance from 10-20 FPS to a full 60.

Super Smash Bros. Ultimate

For all game benchmarks, we utilized a PC built to our own recommended hardware spec. In this testing we observed performance improvements ranging from 15-60% in some of the most demanding areas of gameplay. Please note the marked titles that were tested with the processor limited to 2.4Ghz, to synthetically make it slower than usual and highlight the improvements.

The * indicates titles tested at 2.4Ghz

That’s all we have for now, see you soon with exciting news about Project Hades and more! Happy emulating!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report April 2021

GoldenX86 — Sun, 09 May 2021 12:00:00 -0300

Howdy yuz-ers! Another month gone, another progress report written. From new firmware versions to Vulkan fixes, we have quite a bit to talk about, so let’s get right into it!

Project Eleuthia

As described in its own dedicated article, Morph and Rei have been very busy reimplementing the applets yuzu uses.

This first step implements the On-Screen Keyboard (or OSK) that games use, and the Error Display yuzu uses to alert the user to bugs, missing data, or crashes.

Examples of the different kinds of keyboards games request

Another major advantage is adding gamepad support! No need to get off the couch to grab a keyboard anymore.

An error example

Part of the effort included working around Qt’s quirks, so as a by-product users now have the option to select either the old Exclusive Fullscreen (recommended and used as default on Linux), or the new Borderless Fullscreen (recommended for most cases and to have OSK properly working).

Borderless not only gives us better input support for gamepads, but also reduces screen tearing and improves clock management related performance issues on some AMD GPUs.

Input improvements

A feature lacking from our Stereo Vision implementation was support for the Switch’s motion detection, and by this we don’t mean Joy-Cons, but rather the actual console. This is commonly used for moving the camera with your head when the Switch is in the Labo goggles.

german77 implemented SevenSixAxis and ConsoleSixAxisSensor, continuing from previous work done by Morph, allowing your configured motion device to freely let you look around in compatible games.

Please don't use it like this...

Both the left and right Joy-Cons map their buttons to different memory locations, as german77 found out. He discovered that we had the wrong location for the SL and SR buttons. One fix later, and everything is as it should be.

A long standing bug when trying to play Mario Kart 8 Deluxe in local split screen multiplayer was a freeze that occurred when confirming all connected players. Morph fixed this crash by sending the focus state change message on applet state changes.

Thank you EmulationFanatic and riperiperi for the help!

Your browser doesn't support mp4 video. :(

Better to crash other players than crash the game!

Taking inspiration from RPCS3, Morph sets the default keyboard input to something more suitable for PC users. You just can’t beat WASD movement, especially when combined with mouse aiming.

Rip and tear, press and click until it is done

Gamecube controllers connected to an adapter sometimes reported the joystick off-center due to invalid data being sent during the connection. german77 solved this by taking 4 measurements during initialization, ensuring that the controller finds its center, like any warrior should.

User interface changes

Kewlan is back with more UI improvements!

To start off, they’ve added a favourite option in the context menu, so you can force some of your games to the top of the list.

Just right click them!

Additionally, they updated the results from a filtered search after you remove a directory. This fixes incorrect behaviour if the user decides to modify the game folders while doing a filtered search.

And lastly, they fixed a random bug that caused folders to expand or collapse when moving them in the game list.

Several users reported that Super Smash Bros. Ultimate may get stuck when loading our web applet, making the whole game softlock. Turns out the URL used by the applet was getting deleted before being used. Morph got around this bug by extending the lifetime of the URL.

It’s 12 o’clock and it’s time for a new firmware!

A big challenge made its entrance last month: the Nintendo Switch’s firmware version was finally updated to Version 12.X, which has kept our developers quite busy figuring out what has changed and what needs to be implemented.

Thanks to joint efforts of german77, epicboy, lioncash, and Morph, yuzu was able to update many system call ID tables (PR #6153, PR #6154), services and function tables (PR #6157, PR #6158, PR #6159, PR #6160, PR #6161, PR #6164, PR #6171), as well as some system values (PR #6155).

Firmware updates generally aim to improve the stability of the hardware and patch exploits, but they might also add support for new features under the hood, which usually requires changes to services, their structures, and other monsters lurking within the OS. Since future games could make use of any of these things, it’s imperative to integrate and support these changes as soon as possible.

General bugfixes

Recently, toastUnlimited caught some bugs using Sanitizers: a number of tools present in some compilers, which are used to analyse the source code and alert the programmer about memory-related problems (leaks, overflows), undefined behaviour (code that works in one environment but might fail in another), data races (a synchronization problem that appears when dealing with multiple threads accessing the same data), etc. This led to a series of PRs implementing fixes in yuzu’s code, such as: Prevent stack-use-after-scope, which ensures that data that used to be accessed indirectly through pointers cannot be accessed again once the reference is lost (possibly corrupting the data that was being pointed to), Avoid reference binding to misaligned address, as well as a number of undefined behaviour bugs that occurred when copying memory from one address to another (PR #6143, PR #6145, and PR #6146).

toastUnlimited also reported an overflow that occurred when he tried playing Pokémon Sword and Pokémon Let's Go Pikachu’s demo, which was related to some of the operations realized by the clock. This helped Morph notice a problem in the implementation of the CalculateStandardUserSystemClockDifferenceByUser function, and promptly submit a fix.

Different processes communicate through mechanisms known as IPC (Inter-Process Communication), and they can send data by using data buffers, typically used for large data transfers, or raw arguments, which are usually composed of smaller data sets. In the case of the clock service of this function, this information has to be sent through the aforementioned data buffers, but it was being extracted as raw arguments instead. This caused the function to operate using uninitialized data (in other words, junk), since it retrieved the wrong values. What should have been generally reported as a couple of milliseconds was instead being reported as a time span of trillions of years — approximately, 320 000 times the calculated age of the universe! Thankfully, the fix only required a small change, so now the values are retired from the proper buffers, and yuzu won’t try to dilate time any more (relatively speaking, if you catch my drift).

epicboy made a follow-up of previous work that aimed to improve the accuracy of how the values for resource limits are used in the kernel.

By nature, all resources in any piece of hardware are limited. The amount of memory, the number of I/O devices, and even the number of processors, just to name a few examples, have a fixed value that cannot be changed at whim, without changing the hardware first. One of the many functions of the kernel in an operating system is to manage and distribute these resources to the processes that request them — and for this, it must know the availability and limits of these resources. Whenever a process is created or deleted, the hardware calculates the amount of memory that is free to use and being used by checking and updating the variables that keep track of these resources.

Previously, yuzu created processes in such a way that each instance of a process had their own value for resource limits. This was a work-around to ensure that, whenever a process queried the kernel for the amount of memory available, a correct value was always returned. This, however, is not how the hardware works. Memory is a resource that is shared system-wide among all the processes, and the task of the kernel to coordinate how these resources are shared among the processes in the system.

With this PR, processes don’t “own” their own instance of resource limits, and they now use the global kernel instance instead.

Dynarmic — yuzu’s JIT, used to translate the Switch’s ARM CPU instructions — was recently updated again in order to increase the size of the code cache (where yuzu stores the translated code), and add support for some unimplemented instructions from the thumb32 set, expanding the amount of code that can be translated.

degasus found that the code cache size was too small when testing The Legend of Zelda: Breath of the Wild, and alerted merry, the chief maintainer, about the problem.

No items, The Best only, Final Destination

Surprisingly, this simple change fixed a very obnoxious problem in a completely different game: the strange slowdowns in Super Smash Bros. Ultimate. It turned out that these slowdowns were unrelated to the power of the computer running yuzu, nor were they neither related to building the shader cache. Dynarmic was just translating code again, simply because the cache where the translated code was stored was too small. But now, with the new size value in place, Dynarmic has no need for any recompilation, and the emulation can proceed smoothly.

Continuing with previous Super Smash Bros. Ultimate Spirit Board’s fixes, Morph synchronized the network clock to the local clock, solving the game timers getting reset.

Morph also fixed GetClockSnapshotFromSystemClockContext. This PR allowing Super Kirby Clash and Yo-Kai Watch 4 to boot.

Poyo!

Morph stubbing SetRequestExitToLibraryAppletAtExecuteNextProgramEnabled and german77 adding the ectx:aw service made Pixel Game Maker Series Werewolf Princess Kaguya boot!

Right picture is from a more recent PR that will be mentioned in the next progress report (Pixel Game Maker Series Werewolf Princess Kaguya)

The game currently has rendering bugs especially affecting Nvidia hardware. AMD users will have a better experience in this particular game for now.

Graphics improvements

For our ~~thermonuclear~~ laptop users and heavy multitaskers, the legendary degasus has a treat for you. By avoiding spin loops in the video core, more idle time is achieved with no performance loss. This means the GPU can enter sleep state more often, resulting in lower temperatures/power consumption, better battery life, and allows the scheduler to take on other tasks waiting in the background, improving system responsiveness. No more burned thighs while on the pause menu, laptop users!

Joshua-Ashton, the Frog Master from DXVK, brought us a few Vulkan fixes and improvements.

First on the list is avoiding a device loss (GPU locks up and the driver restarts it) by checking the return value of vkAcquireNextImageKHR.

Joshua also enabled the individual features from VK_EXT_robustness2, instead of just enabling the extension.

And finally, fixing a wrong offset for null vertex buffers to properly follow the Vulkan specification. You never know when a driver will behave in erratic ways. Fixes like this allow developers to report bugs to the vendors’ driver development teams, thanks to confirming everything is within specs. Any resulting error falls under responsibility of the driver teams.

OpenGL wasn’t the only API to have BGR issues, it turns out Vulkan can also suffer from “blue madness” when a game uses the A1B5G5R5_UNORM texture format.

epicboy swapped the Red and Blue channels of this format, fixing colours in games like Pokémon Let’s Go Eevee/Pikachu, Shantae: Risky’s Revenge, and many others! You can see the result in the following pictures, before (left) and after (right).

I didn’t want Pokémon Blue! (Pokémon Let's Go, Eevee!)

That’s definitely not Vivi (Shantae: Risky’s Revenge)

Linux Build System

toastUnlimited has been periodically improving yuzu’s build system for our Linux user base. Not all our users want or are able to use the official AppImage, so not only did our build instructions need to be improved, but it was also equally important to refine the environment necessary to get yuzu running — namely, the dependencies, build process, etc.

The first step was to make SDL2 an external dependency. This would allow us to ship the latest version without having to face Linux distributions’ incompatibilities due to different build flags (different characteristics being enabled), or outright outdated versions that aren’t able to support all of the required features that our input asks for.

The changes to SDL2 introduced an incompatibility with the Conan-provided Boost version. Downloading it as an external dependency ensures compatibility, as most of the time the local packages provided by the distribution won’t be enough. This change also makes our external download script cross-platform with Windows and other distributions that used to require special workarounds.

As a special bonus, due to all of these changes, Red Hat Enterprise Linux 8 and its derivatives can build yuzu in a much more user-friendly way.

For anyone interested, we keep updated build instructions on this page.

Future projects

This section has lately turned into Project Hades teasing, but we won’t apologize for that! Here’s more info/teasing:

While working on implementing SPIR-V for OpenGL, we discovered that Nvidia decided to take the lazy way out and just convert SPIR-V back to GLSL, which is then compiled again to GLASM. This not only destroys any benefit we expected to gain when switching to SPIR-V by default, it also causes huge delays and rendering problems. We are forced to also implement GLSL in Project Hades, introducing a considerable amount of extra work that wasn’t expected.

Your browser doesn't support mp4 video. :(

The best use of Tessellation Shaders ever

This will provide better compatibility for Nvidia hardware, saving Fermi once again from the gutter.

Regarding other project news, Morph’s Project Gaia is growing. german77 is working hard on Project Kraken. bunnei has more kernel changes in the oven.

That’s all folks! Thank you for sticking with us and see you next month!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report March 2021

GoldenX86 — Sat, 10 Apr 2021 12:00:00 -0300

Hi yuz-ers, we’re here with the March progress report to offer you our latest news! We continue to update the Kernel, some considerations have been made for specific hardware, we have several changes and fixes to discuss, and we have a sneak peek at the progress on Project Hades.

General bug fixes and improvements

Morph to the rescue! Fixing CalculateSpanBetween allows Super Smash Bros. Ultimate’s Spirit Board to work! A separate PR improving ClockSnapshot fixes the timers.

More work is needed to make World of Light playable, we continue to fight for it! (Super Smash Bros. Ultimate)

Those who have paid attention to our previous progress reports will notice that we sometimes write about when a service is stubbed (ignored, basically) to allow a game to progress further. This process requires manual intervention each and every time a game update or new game uses a new unimplemented service. To mitigate user frustration, epicboy implemented Auto-Stubbing, continuing previous work from ogniK.

With this toggle, games will just ignore any unimplemented services and continue running, allowing developers to focus on the services that need urgent, proper implementations. This is not a new invention by any means. Several emulators in the past have used this feature to great benefit, reducing the load on developers and providing a better experience for the end user.

Keep in mind that auto-stub will be always disabled by default on each boot, so it has to be manually enabled for each session by going to Emulation > Configure > General > Debug > Enable Auto-Stub.

You can find it here, at the bottom of the picture in the Advanced section

Morph took it upon himself to update the emulated Switch firmware version to 11.0.1, and the NgWord version, improving compatibility with recent games, and solving some odd bugs. For example, Disgaea games no longer require a firmware dump to be playable.

We now have some new additions to our command line arguments thanks to german77. Users can select which user profile to load by adding the -u # argument to their command, with # being the profile number. For example, by using yuzu.exe -u 1 -g "path_to_game", the second profile will be selected.

In an attempt to reduce file size when downloading yuzu and also reduce the download size when building it from source, toastUnlimited reworked how FFmpeg is linked. This way, only what is needed for yuzu is built, reducing the size and build time required for this module, and as an added bonus Linux users will avoid problems with possible outdated versions included in their distributions. Data capped users rejoice!

ivan-boikov fixed an issue where pressing Cancel would result in the wrong destination folder in the file system configuration. Nothing beats quality of life fixes!

Microsoft Visual Studio, by default, will compile applications with the character set corresponding to the region of the local developer’s PC. This limitation can cause issues for certain regions like Asia when trying to build our source. Morph bypassed this limitation by forcing the UTF-8 character set. As an added benefit, some UI elements like up and down arrows started rendering. Free bonus.

There's nothing like a good arrow icon.

While a ton of work is needed to make MONSTER HUNTER RISE run, including finishing the shader decompiler rewrite and implementing the asynchronous software keyboard, that doesn’t mean ogniK can’t start some preliminary work. In this particular case, the focus is to improve Parental Control emulation, bringing it closer to the Switch’s native hardware implementation.

Graphic improvements

Since the introduction of Asynchronous shaders, we noticed that not all drivers like the feature. In particular, Intel Windows OpenGL, and the proprietary AMD drivers (for both Windows with Adrenalin, and Linux with AMDGPU-PRO) despise the setting, with Intel ignoring it at a driver level, and AMD outright skipping frames, resulting in massive stuttering.

toastUnlimited added a blacklist for our red and blue GPU users, ensuring no performance or graphical regressions occur while attempting to use a feature that their drivers can’t support in OpenGL anyway. It’s worth mentioning that Asynchronous shaders work as intended in Vulkan and all free Linux OpenGL drivers, be it for AMD or Intel. Nvidia works as expected on any combination of API or OS with their proprietary drivers. Thanks to theboy181 for the suggestion!

bunnei implemented an optimization that affects all graphic caches (texture, buffer, shader). By using a flat array, cache performance is improved slightly, with the bonus of some memory bandwidth saved due to better resource allocation. A small but measurable 5% performance bump can be experienced, for example, in Super Mario Odyssey.

Technical fixes, continued

The dynarmic submodule has been recently updated in this PR, merging the latest changes with yuzu. Thanks to the efforts of merry and lioncash, many thumb32 instructions (a subset of ARM instructions) were implemented, increasing the amount of instructions supported for 32-bit games on yuzu.

Additionally, all floating-point instructions received minor optimizations, and a couple of bugs in the implementation of AVX-512 extensions were fixed too. There was also a problem with AMD CPUs, where previously dynarmic disabled the use of the BMI instruction set (used for bit manipulation), due to being extremely slow in those processors. However, on Zen 3 and newer, the performance of these instructions has increased considerably, so now dynarmic allows these AMD processors to use BMI instructions if the detected CPU is fast enough to perform them.

All of these changes were possible thanks to the contribution of Wunkolo to dynarmic (which eventually made it to yuzu), so shoutouts for the great work!

Going back to kernel updates, bunnei reworked and cleaned the kernel memory management code. As the name implies, this is the part of the OS that allocates memory resources for games when they request them. With this change, the implementation matches more closely that of the Nintendo Switch. As always, these changes make it easier to support any future hardware revisions, along with all other kernel changes that are currently ongoing.

Bunnei also fixed a memory leak caused by dummy threads. These dummies are used by yuzu to interact with our emulated kernel. Every “real” emulated thread has a dummy associated with it. As explained in the previous progress report, yuzu utilizes fibers in order to emulate threads. However, these dummy threads don’t actually use fibers. With this change, bunnei removed some unnecessary memory overhead by removing the creation of fibers (which would only be needed for “real” emulated threads), thus reducing the memory usage by a bit.

Another bug that was also fixed by bunnei was related to how JIT states are saved between page table changes. A page table is a scheme used to map physical memory into virtual memory, used to give processes the impression they’re working with a unique, contiguous section of memory, regardless of where and how this memory is actually stored. Due to the way dynarmic is coded, whenever yuzu changes the page table that is currently in use, it needs to recreate the CPU JIT. But, until now, yuzu wasn’t saving and restoring the state of this JIT properly when this happened. However, with this change, all the context needed by the JIT is now stored and retrieved correctly.

Input improvements

Not all devices can do N-key rollover, meaning pressing many keys/buttons at the same time without some inputs being missed. For this, german77 implemented a toggle to hold a button for you. This way you can ask yuzu to keep pressing a button, freeing your hand and devices from it, while you move to something else! To access this feature, right click the Modifier button in control settings, and select Toggle button.

Right click any button or modifier

For those using Cemuhook to provide motion via an Android device, german77 has a nice stability improvement for you! Each individual socket connection now needs its unique client ID.

In a separate PR, german77 tests using a single UDP connection per server instead of per controller, reducing the error rate thanks to simplified communications. The end result of this work is more stable connections for motion devices.

Xbox 360 and Xbox One controllers were incorrectly displayed as just Xinput Controller in our device list, causing confusion to our users. Additionally, the default Pro Controller mapping had its face buttons swapped by mistake. german77 fixed both issues. Bad defaults are bad.

Future projects

Project Hades, our rewrite of the shader decompiler, is taking shape. On the games that can be booted now, we can already measure performance increases and countless bugs fixed.

Here’s a sneak peak, fresh from the source.

You can say it's one hell of a rewrite!

While our graphics devs continue to rewrite all shader instructions, we can inform everyone that the new pipeline cache for Vulkan is fully working, storing and loading just as well as OpenGL’s shader cache, while even being faster!

No more hard crashes (Fire Emblem: Three Houses)

On top of that, Rodrigo also implemented a new kind of asynchronous shader “secret technique” that scales better with the number of threads available, and produces zero graphical glitches!

The Bokoblin Slayer (Hyrule Warriors: Age of Calamity)

We will expand this information once Hades is out and has its own dedicated article.

That’s all folks! Thank you so much for allowing us to take some of your time, and see you next month!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

New Feature Release - Applet Overlays

CaptV0rt3x — Sat, 03 Apr 2021 01:00:00 +0530

Hey there, yuz-ers! Have you ever thought of enjoying yuzu on your TV, relaxing on your couch, but found our user interface cumbersome? Thanks to the efforts of our developers Morph and Rei, yuzu has taken a massive step forward in making couch gaming comfy. Let’s dig in!

What is this about?

For a while now, users have complained that yuzu’s couch setup (full-screen, TV, controller) experience isn’t as comfortable as it could be. One pain point was that pop-ups of any kind can’t be addressed with a controller. On top of that, these pop-up windows were separate background processes that wouldn’t appear until you exited full-screen mode. As you can guess, you always had to have a keyboard and mouse handy.

Old error applet

New controller friendly error applet

To fix this once and for all, Rei started work on eliminating all pop-up windows and to make it possible to control all system messages with a controller. It was during this time that Morph began working on rewriting our software keyboard applet. And since the software keyboard applet wasn’t controller friendly either, they both collaborated and redesigned it from the ground up.

Old software keyboard applet

Your browser doesn't support mp4 video. :(

New controller friendly software keyboard applet

The Software Keyboard

As many of you might know, the Switch has a software keyboard that allows players to input text into games. What you might not know is that there are multiple variants of keyboards implemented within the Switch’s Horizon OS. For example, there is the full-screen keyboard, which pauses games and allows input, and there is the inline keyboard, which allows input while the game is running.

Our old software keyboard implementation was just the bare minimum required by the full-screen variant and, due to its design, was difficult to add support for the other variants. It also quickly became outdated due to the newer revisions of the applet that shipped with later Switch firmware updates. Equipped with the knowledge and expertise from previously rewriting two other applets - namely, the browser applet & the controller applet - Morph set out to rewrite the entire software keyboard applet from scratch.

Rei had meticulously designed the new overlays for the keyboard applet and they turned out to be absolutely stunning. Now, all that was left was to implement the keyboard applet backend and connect it to the frontend — but then came the challenges.

The new software keyboard layouts for each yuzu theme

Challenges

As mentioned earlier, our old implementation was not designed with multi-variant support in mind. With the rewrite, our foundational goal was to ensure all keyboard variants were supported. A major challenge was figuring out how the inline keyboard variant worked. In contrast to the full-screen variant, this one worked asynchronously.

Applets run as separate processes on the Switch, but games have a habit of pausing their processes, invoking the keyboard applet, and making it seem synchronous. There are several more applets that work asynchronously in addition to the inline keyboard variant. As such, Morph spent a lot of time and effort on testing how the applet worked on original hardware — figuring out how all the pieces fall into place, making optimizations, and thus slowly perfected the backend implementation.

Your browser doesn't support mp4 video. :(

Monster Hunter Generations Ultimate - Inline Keyboard in action

Your browser doesn't support mp4 video. :(

Pokémon Sword/Shield - Numeric Keyboard in action

With the backend in place, a new set of challenges arose due to yuzu’s frontend library, Qt. Qt has a lot of annoying quirks, such as window positioning, transparency, and more. These took several days of testing to track down and resolve. For the frontend, Morph and Rei also had to plan and account for various other things like game specific keyboard scaling, high DPI displays, and higher resolutions.

The final and most important challenge was figuring out how to make the applet controller friendly. Thanks to the efforts spent in planning and testing at various stages of development, our devs were able to overcome these challenges.

Extra

Although the overlay dialogs were initially designed with the keyboard applet in mind, the devs soon discovered its potential as a replacement for pop-up windows. Thanks to this, the error applet has now joined the list of controller friendly applets, with more to come soon. The error applet is used by games to crash and report back error codes to the user in various scenarios, which was previously done via a pop-up window.

The new error applet overlays for each yuzu theme

Fin

Both the new keyboard applet and the controller friendly error applet are now available in the latest Early Access build. Since these are currently still under development, we would like to hear more about your experiences and any bugs/issues you might encounter. Please don’t hesitate to reach out to us on our Discord server’s Patreon support channels to report any findings. That’s all we have for today but, we’re sure to be back with more exciting news soon!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report February 2021

GoldenX86 — Wed, 10 Mar 2021 12:00:00 -0300

Welcome back yuz-ers, welcome to ~~City 17~~ February’s progress report! This time we will talk about Vulkan performance improvements, audio changes, how to make good use of compute shaders, new input additions, and more kernel rewrites.

New minimum requirements

Thanks to progress in Linux’s mesa drivers, we’ve recently modified our minimum graphics requirements.

yuzu now requires OpenGL 4.6. However, any previously compatible hardware reaches this requirement with its latest GPU drivers installed, even old Fermi or GCN 1.0 series products. Laptop users, like desktop users, should visit the GPU manufacturer’s site (AMD, Intel, and Nvidia) instead of the laptop vendor’s site (HP, Lenovo, Asus, etc.), as it will provide compatible and up-to-date drivers. Thanks Morph for the change!

On the flip side, while the requirement of Vulkan 1.1 hasn’t changed, as stated in previous articles, Rodrigo made VK_EXT_robustness2 a hard requirement. This means that updated drivers are critical now, as lacking this extension will stop yuzu from booting games while on Vulkan. AMD users still require to install the latest Optional driver version to get support for VK_EXT_robustness2. At the time of writing, the latest version is 21.2.3, but yuzu will work with drivers as old as 20.12.1.

Multi-GPU systems must have all their drivers updated, even for integrated graphics that are functional but not in use.

Technical bugfixes

Merry recently caught a bug in the implementation of yuzu’s SPSC ring buffer and fixed it by removing the granularity template argument. What does this mean exactly? Let’s explain!

A buffer is a data structure that reserves space in memory as slots to store information temporarily: for example, an audio buffer. In particular, a ring buffer is a special type of buffer where the slot next to the final one is the first slot in the buffer (so the start and the end are connected). Once it’s full, no new data is added until some information has been extracted from the buffer and processed.

SPSC stands for “Single-Producer/Single-Consumer,” and is a model that comes from the Producer-Consumer problem proposed by computer scientists to deal with the problem of proper synchronization when various simultaneous processes write and read from the same buffer. In this case, only one thread at a time can insert data into the buffer (the Single-Producer), and only one thread at a time can remove elements from the buffer (the Single-Consumer).

It’s possible to choose a minimal size for each “slot” of the buffer in order to exploit regularities of the information stored. The entities inside these slots are then considered a single “unit” of information, an information granule, from which the term “granularity” stems from. The ring buffer implementation in yuzu was meant to be as general as possible, which is why granularity was a parameter that the programmer could modify to fit their needs. Merry noticed there was a small bug when pushing data into the buffer with a granularity different from 1, but since there is no use case for a granularity different from 1 in yuzu, Merry decided to remove the parameter altogether, in favor of simplifying the codebase.

bunnei has been taking a look at the timing code and fixed an integer overflow in the wall-clock - a tool used to measure the passage of time in the emulator. Previously, these calculations would use 128-bit math for high precision, which can be quite expensive on the processor, so a few optimizations were done to perform 64-bit math instead. However, there was a bug introduced with these optimizations, and the timing math would result in an integer overflow. This PR fixed the bug by preventing the wall-clock from overflowing, and now things are back to working as intended.

bunnei also continues on his campaign to rewrite the kernel and its codebase. This time, he has been tidying up the memory management code and refactoring the implementation to be closer to the latest Switch firmware in order to make it easier to import code from newer firmware.

Additionally, he changed the implementation of fibers to use unique_ptr instead of shared_ptr, but later changed it again to use weak_ptr as it’s more appropriate in this use case.

Fibers are similar to threads, except they can’t be executed in parallel. Instead, they yield control to other fibers in a process. In yuzu, they’re used to have better control over thread scheduling, working as tools for the kernel to quickly pause and resume emulated guest threads from within the application, without having to rely on the OS scheduler.

Previously, fibers were managed through a special object called a shared pointer, a kind of variable that stores the memory addresses of other objects - it “references” them. In particular, this variable keeps track of how many shared_ptr references to an object exist in the program, and the memory won’t be freed until the total amount of references is zero (i.e. when the object isn’t being used anymore). If these references aren’t managed with proper care, some pointers may retain memory and never free it, resulting in memory leaks. For this reason, bunnei changed the implementation to use a different kind of object, a weak pointer, which is similar to the shared pointer but it doesn’t increase the reference counter, nor is it capable of deleting the original referenced object. Thus, the referenced memory will be free only when the original pointer is deleted, regardless of how many other weak_ptr references to the same memory exist, eliminating the memory leaks caused by the old implementation.

One of the many tasks of the kernel is to assign resources to processes whenever they ask for them. For this reason, epicboy started the work necessary to utilize a more accurate resource_limit implementation, in order to match the hardware behavior more closely.

Be it memory, threads, or ports, the kernel checks for their availability and keeps track of them through a variable called resource limit. By comparing the current amount of resources being used against the resource limit, the kernel can determine whether to deny a request or not. This stems from the fact that resources are finite, especially in weaker hardware such as that in the Nintendo Switch. A PC, on the other hand, isn’t as restricted as a Nintendo Switch. Until now, whenever a process requested resources, yuzu would create its own instance of resource limit instead of using a system-wide variable to keep track of it. This PR is just the initial step in preparation to reverse engineer the correct behavior and implement it in the emulator.

Paint me like one of your french bits

epicboy has also been busy this month implementing two features through compute kernels, a special kind of program that is written to run in the GPU instead of the CPU. Originally, these subroutines were used to calculate light levels, darkness, colors, and other properties to render 3D images on the screen. Thus, these programs were promptly named as shaders.

Modern GPUs are designed to break down their workload into smaller sized problems, which in turn are processed simultaneously in the many compute units of the card (entities akin to cores in a CPU). The reason for this design choice is simply because parallelisation is a very efficient scheme to process computer graphics. A single instruction is capable of operating over many components of data at the same time, such as the vertices and textures of a 3D scene, and produce separate results for each parallel thread of execution, which is generally a pixel. This increases the throughput of information, especially when compared against the performance of running the same operations on a CPU. Their potential isn’t limited to just these functions though. It is possible to write programs that won’t necessarily operate over graphics, but can still take advantage of the high levels of parallelisation provided by GPUs. This is known as GPGPU - General-purpose computing on graphics processing units - and it’s intended to be used when there is a problem that can be separated into a number of parallel tasks in order to be processed more efficiently. These problems are commonly called embarrassingly parallel problems.

One of these cases was the use of compute shaders to decode ASTC textures. ASTC stands for “Adaptable Scalable Texture Compression,” and it’s a fairly new image compression format developed by ARM and AMD mainly aimed at mobile devices. The Nintendo Switch is capable of decoding these textures natively in hardware, but it’s a feature that most PC GPU vendors lack in their products (with the exception of Intel Graphics, being the only vendor that offers native support). The decoding of these textures is therefore a non-trivial task that can have a huge impact on performance. Two notable examples are Astral Chain and Luigi's Mansion 3, since both games make extensive use of this format, but it can also be observed to varying degrees in other titles, where these textures are generally used in menu icons, minimaps, etc.

Your browser doesn't support mp4 video. :(

Comparison between the old and the new implementation of the ASTC decoder

This led to the implementation of an ASTC decoder through the CPU, which was faster than what GPUs could do with their lack of native support. The CPU decoder was still far from being a satisfactory solution, since it consumed precious CPU resources and, consequently, slowed down to a halt when running games that made extensive use of this format. The solution, thus, was to implement the decoding through compute shaders. Since this is an embarrassingly parallel process, seeing as how every block of pixels can be decoded independently, it’s more fit to be performed on the GPU by manipulating the data through GPGPU. This way, the load on the CPU will be shifted to the GPU, allowing emulation to run in parallel with the texture decoding. As a side benefit, now textures remain in the GPU memory all the time, since they don’t need to be transferred between CPU and GPU for decoding. This means that there won’t be time spent downloading the texture to the CPU and then uploading it back to the GPU after the decoding is done, like in the old implementation.

This feature works as intended on all GPU vendors on Windows, although there are a few problems on Linux (more specifically, the AMDGPU-PRO driver) that still need to be ironed out. Our devs are working hard to solve these bugs, so we ask our tux-friends to be patient and stay tuned!

Since compute programs were originally meant to manipulate image data, they also worked out nicely to fix a problem with one of the rendering APIs used in yuzu: by using compute shaders to swizzle BGR textures on copy.

Color-swapped and properly swizzled versions of Octopath Traveler's title screen

In OpenGL, colors are stored in channels, and the way they are laid out varies depending on the format used. For example, the RGB format stores the color channels in the order “Red, Green, and Blue,” while the BGR format stores the channels in the order “Blue, Green, and Red.” Unfortunately, this latter format isn’t supported internally by OpenGL, which caused problems with a number of games that made use of BGR textures: their Red and Blue channels were swapped and the final images looked blue-ish.

Blue Christina looks nice, but the red hue definitely suits the Nixie Tubes much better in Steins;Gate: My Darling's Embrace

The solution to this problem then was to reorder the Blue and Red channels of BGR textures in the copy uploaded to the GPU. Reordering the graphical information of an image to process it in the graphics card is called swizzling, so what this PR does is copy the values of the Red channel into the Blue channel and vice-versa, a process that can be exploited through parallel computation. This way, the limitation with OpenGL is directly bypassed on the GPU, and these textures are rendered as intended on screen.

General bug fixes and improvements

Pokémon Sword and Shield players can enjoy one less frequent crash. Boss bunnei fixed a problem on LDN initialization, eliminating the crash that occurred if the player pressed Y during gameplay (activating online services that yuzu lacks). An error window will still pop up, but emulation will continue.

Yet another Animal Crossing: New Horizons update, yet another service to stub or implement to regain playability. This time, stubbing GetSaveDataBackupSetting made 1.7.0 and later versions playable again. Thanks german77!

Under certain conditions, the WebApplet would crash yuzu when opening, for example, the Action Guide in Super Mario Odyssey. aleasto managed to solve this by fixing an out of bounds read.

A common annoyance that affected new users was a prompt asking for the derivation keys to be placed in the correct keys folder, a folder which had to be manually created until now. Thanks to Morph, now there is an empty keys folder created by default as part of the installation process of yuzu, ready to be populated by the user’s own Switch keys.

Graphics improvements

Maide has been working on improving the recently released Disgaea 6: Defiance of Destiny.

First, Vulkan needed some corrected offsets for TexelFetch and TextureGather, types of texture instructions.

A similar change was needed for OpenGL. This code also includes better handling of signed atomics, improving precision. Thanks to Ryujinx for helping here.

Finally, implementing glDepthRangeIndexedNV solves out of range issues in the depth buffer.

Your browser doesn't support mp4 video. :(

The result of Maide's work (Disgaea 6: Defiance of Destiny)

Rodrigo fixed a bug in Vulkan’s stream buffer, improving performance and reducing VRAM use, while also making better use of the dedicated VRAM, instead of falling back to shared VRAM, which is better known as just system RAM.

By using dirty flags, Rodrigo also managed another slim, but measurable, Vulkan performance bump. Reducing draw calls always helps!

After a lot of time spent experimenting, Rodrigo reduced the size of Vulkan’s command pool, from 4096 to just 4. This makes the driver assign less memory for command buffers, saving a considerable amount of system RAM.

For example, in Pokémon Sword and Shield, Vulkan’s use of system RAM goes from 707MB, to just 2MB.

To end the day, Rodrigo fixed a regression introduced by the Buffer Cache Rewrite. Some games benefit from skipping the cache, but others lose performance. Animal Crossing: New Horizons was an example severely affected in Vulkan. By implementing a way to heuristically decide when to skip the cache, performance was not only restored, but also increased.

Input improvements

First and foremost, german77 finished implementing native Gamecube controller support! With this change, games will now actually register GC controllers instead of registering them as, for example, emulated Pro Controllers. Right now Gamecube triggers are mapped as buttons, but they will be correctly handled as analog triggers in coming changes.

Morph later added vibration support for the GC controller.

Another new feature german77 added is stick mouse panning. This allows users to set the mouse as an analog stick, enabling very comfortable gameplay on titles that use the right analog stick as camera control. By default, pressing Ctrl + F9 toggles this feature.

Your browser doesn't support mp4 video. :(

Keyboard warriors rejoice! (The Legend of Zelda: Breath of the Wild)

A separate PR improves panning functionality even more, giving it a more natural control.

Morph implemented the Finalize request on the inline keyboard implementation, allowing it to exit in a stable and graceful way instead of looping indefinitely. This solves issues experienced in Super Mario 3D World + Bowser’s Fury.

Jatoxo gives us a feature we didn’t know we wanted. They’ve added depth to the analog sticks of the Pro Controller in the controls preview. See the result for yourself!

Your browser doesn't support mp4 video. :(

Nothing beats quality of life changes like this

Audio achievements

One of our most requested fixes is finally here. Fire Emblem: Three Houses no longer echoes voices! ogniK is responsible for this fix, which properly implemented I3dl2Reverb.

If you paused emulation and resumed it some time later, you would experience severe stuttering until the audio caught up to the rendering. german77 resolved this unpleasant experience by preventing overscheduling audio events, allowing for a seamless experience after resuming emulation.

Future projects

Project Kraken is underway. Project Gaia started. Project Hades, the shader decompiler rewrite, is progressing steadily. If it continues like this, it will be released before Memory Reaper. As you’ve seen in this article, bunnei continues to suffer through implementing Kernel changes.

That’s all folks! As always, thank you for reading until the end, and see you next time!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report January 2021

GoldenX86 — Wed, 10 Feb 2021 12:00:00 -0300

Welcome yuz-ers, to the first progress report of 2021! We have quite a bit in store for you: from kernel and CPU emulation improvements to another major graphical rewrite. Here are the most important changes of January.

The Buffer Cache Rewrite

While we have a dedicated article detailing the improvements from the Buffer Cache Rewrite (BCR), Rodrigo didn’t sit idle and continued to improve the buffer cache. These new changes and improvements deserve some time in the spotlight. For the full context, we advise reading the dedicated article before continuing.

Your browser doesn't support mp4 video. :(

The BCR offers performance and rendering improvements (Xenoblade Chronicles Definitive Edition)

Vulkan needed some improvements to be compatible with the BCR. In particular, its memory allocator got a complete overhaul, improving its functionality.

A performance bottleneck affecting Intel GPUs in Vulkan was fixed by using timeline semaphores instead of spin waits.

Preliminary work was done to have the compute accelerated texture decoders working in the near future.

Assembly shaders are very limited and hard to work with due to their ancient origins. A problem faced during the BCR development is keeping compatibility with them while offering their advantage in shader build times to Nvidia users. At release, the first implementation Rodrigo tried made use of interops, a feature that allows calling functions of one graphics API from another. In this particular case, he used the new memory allocator of Vulkan from within an OpenGL context. While the results in Windows 10 and Linux were satisfactory, this had some limitations:

Windows 7 was unstable due to broken memory management. A known problem that was never fixed during the lifetime of this now discontinued operating system.
Fermi era GPUs (mostly 400 and 500 series) had to skip assembly shaders due to Nvidia never adding Vulkan support.

So, as a workaround for now, the old pre-BCR method is currently in place. Since this method may be slower in some games compared to the updated GLSL implementation, assembly shaders is now disabled by default while Rodrigo works on a different implementation. Feel free to re-enable this setting if you get playable performance in your games. You can find it in Emulation > Configure… > Graphics > Advanced tab

Vulkan users are advised to update their GPU drivers to the very latest version, as the BCR makes the extension VK_EXT_robustness2 mandatory, instead of its previous optional status after the release of the Texture Cache Rewrite. All three main GPU companies (Nvidia, AMD, and Intel) now offer support for this extension in their latest driver. AMD users updating from Radeon Software may need to allow Optional driver download support to get the corresponding driver version to have access to this valuable Vulkan extension (at the time of writing).

Several games now prefer High GPU accuracy over the default Normal value. Users can change this setting while playing by going to Emulation > Configure… > Graphics > Advanced tab > Accuracy level. We recommend users to play with this setting to find the optimal performance, but to avoid the Extreme value for the moment, as it will either result in very low performance (intended result), or crash the game entirely (not intended, being investigated).

While there are big improvements across the board, this graph shows the limitations of integrated GPUs constantly fighting the CPU for RAM resources. Having your own fast dedicated on-board VRAM is very important for performance.

Analysis time. If you compare this graph to the one of the RX550 in the BCR artricle, you will notice that a small integrated Vega manages to beat a dedicated Polaris card in Fire Emblem: Three Houses by a few frames. This is because newer GPU architectures offer features that are useful for Switch emulation. Ray tracing is not the only cool kid in town!

The Tegra X1 SoC in the Nintendo Switch offers native support for FP16 with a 2:1 performance ratio, allowing games to double their performance over regular FP32 when doing floating point calculations. A simple way to achieve a higher frame rate on limited hardware. Vega (GCN 5.0), Turing, Gen 9 Intel Graphics and newer offer native support for FP16, or as AMD calls it, “Rapid Packed Math”. Series like Polaris (GCN 4.0), Pascal and older may offer support in their drivers but don’t provide a performance advantage, and in the case of Pascal, it reduces performance considerably (64 times slower than FP32). In those cases FP32 is used to emulate FP16, obviously resulting in no performance gains.

This is the main reason our Hardware Requirements lists Gen 9.5, Vega, and Turing cards, as the recommended GPUs. Maxwell v2, Vega, Gen9 and later series also offer conservative rasterization, a very useful feature that yuzu can take advantage of in the future.

General bug fixes and improvements

Let’s start with good news, Champion Leon can no longer win by default! Thanks to ogniK’s work, unregistering already registered events, games like Pokémon Let’s Go Eevee/Pikachu and Pokémon Sword/Shield won’t softlock when the game requests playing a video. Gotta beat em all, was it?

Let’s battle, for real this time! (Pokémon Sword)

Quality of Life improvements, although seemingly small, can still require several considerations. Morph made docked mode the default option, with the intention to offer users the highest game quality, and to remove flickering experienced in Super Mario Odyssey when running the game with assembly shaders enabled while in undocked mode. Users with integrated, slow, and/or old GPUs should consider using undocked mode, as the reduced resolution and detail level will help avoid performance bottlenecks.

german77 solved one of the most common problems users had when playing Super Smash Bros. Ultimate, the inability to boot the game if more than one user profile was created. Thanks to this fix, users are no longer forced to play the game with the top profile in the list.

toastUnlimited continues his work on Linux’s AppImages. Now yuzu’s AppImage build can be updated, reducing the download size to just around 9MB if you use AppImageUpdate.

By improving nvflinger, the display service of the Nintendo Switch, bunnei made Katana ZERO playable again.

Serendipity strikes again. By fixing a data race introduced by one of the recent kernel changes, epicboy also fixed unlimited FPS mods which previously made the emulator crash.

By fixing invalid buffer index errors, Morph was able to resolve various crashes in booting Super Mario Maker 2 that occurred due to file system issues.

In the eternal torture that is audio development, ogniK implemented FlushAudioOutBuffers, making the Devil May Cry series playable.

Look at the graphics, that's you know, what it's really all about (Devil May Cry 2)

Miscellaneous graphical improvements

We have three public service announcements, one for each GPU vendor:

First, a message for AMD users with RX 5000 series graphics cards. In the past, we blacklisted the VK_EXT_extended_dynamic_state Vulkan extension on all RDNA1 based GPUs on Windows. The drivers at the time were unstable when using this extension, causing yuzu to crash to the desktop. This block has been removed by Rodrigo, but keep in mind that the user needs to be running 20.12.1 or newer driver versions. “Navi“ users can expect several graphical fixes thanks to this change.

Blue team’s turn. On the topic of blacklists, Rodrigo had to disable FP16 math support from Intel Windows Vulkan drivers to solve stability issues affecting Astral Chain. For now, half-float operations will be emulated using FP32 math. This will result in lower performance if the game manages to make full use of the compute capabilities of the GPU. However, on current Intel Graphics, rasterization (to put it simple, the raw power of the GPU) is usually the first element to bottleneck performance, even before being affected by the aforementioned operations.

Thanks to this change and Intel’s native ASTC texture decoding support, Intel Graphics now has the best rendering quality in this particular game. We’re waiting for a driver fix to come relatively soon, so as always, keep your drivers updated!

Astral Chain on integrated GPUs, reaching 30 FPS (docked mode)

Finally, regarding Nvidia. If the shader cache is stored in Nvidia’s own provided directory, a 200MB total folder size limit is imposed. BSoD found out that such a limit is easy to surpass if other shader intensive programs are in use, like Adobe’s software suite. Rodrigo bypassed this problem by moving the cache to yuzu’s own directory, instead of using the default directory the driver provides.

With this change, we recommend building your cache with assembly shaders enabled, but once the cache is complete or close to completion, switch to regular GLSL (disable assembly shaders). That way (after a long period of shader compilation at boot), stuttering will be completely avoided. Thanks to Exzap from Cemu for the help!

Our resident shark, ogniK, implemented the missing services to have Stereo Vision, the Nintendo Switch’s implementation of Virtual Reality using a Nintendo Labo “headset”. Games like The Legend of Zelda: Breath of the Wild, Super Mario Odyssey, Super Smash Bros. Ultimate, and Captain Toad: Treasure Tracker can now render for both eyes.

While this doesn’t offer full VR support for PC compatible headsets yet, it allows users to make their own cardboard headsets à la Google, so long as they are handicraft-inclined. Pro tip, stream to a phone or tablet.

You will need a lot of cardboard if you want to use this on big displays (The Legend of Zelda: Breath of the Wild)

By fixing the constant buffer’s size calculation, Undertale can now be run in OpenGL with Assembly Shaders disabled, allowing the game to run on Intel and AMD GPUs. Rodrigo will no longer have a bad time.

The Buffer Cache Rewrite helped expose new issues in games, one example is geometry explosions in Zombie Panic in Wonderland DX. Rodrigo fixed this by flushing the destination buffer on CopyBlock.

More work is needed to make this game look right (Zombie Panic in Wonderland DX)

One of the important additions of the Texture Cache Rewrite is the support for Format Views, a feature games request and use natively. Unfortunately, AMD and Intel Windows drivers have a broken implementation, and format views had to be disabled to fix rendering problems.

Mushroom Dark World? (Super Mario Odyssey)

We reported this problem a long time ago to both vendors, but it seems like OpenGL is not a priority on Windows. The Linux mesa team, on the other hand, has fantastic response times to bug reports of any API.

For the Linux side, recent changes made the Vulkan Intel driver anv incompatible. By removing a not critical requirement (for now), and fixing initialization, Rodrigo restored functionality.

Due to its constant use of ASTC textures of considerable size (way bigger than the display resolution of the Nintendo Switch), Astral Chain is a prime example for testing the stability of yuzu’s software ASTC decoder. Game crashes were common due to reading or writing out of bounds, Rodrigo fixes this by improving the robustness of the decoder.

The Youkai, the rabbit, and friends

MerryMage has recently made some changes to Dynarmic that improved the performance of some games.

We start off with a PR that introduces a setting to remove some NaN checks from JITed code. This inherently results in a decrease of accuracy on the representation of these and other special values, which is why this setting is unsafe. However, this also boosts the performance of games that make heavy use of NaN values, such as Luigi's Mansion 3 (especially in the basement 2 and floor 12 areas, where previously performance would decrease greatly). This setting can be found in Emulation > Configure > CPU > Unsafe as a toggle option, Inaccurate NaN handling.

Your browser doesn't support mp4 video. :(

Luigi's Mansion 3, the new and the old. The general performance of the game improved drastically thanks to this PR.

On any digital system, all numbers are represented in a binary base in order to be stored and perform operations with them. Naturally, there is a limit to the amount of numbers and the precision with which they can be represented, not to mention that a number can be expressed in many ways by just declaring it as a different type (e.g. integer, floating-point number, etc.). Likewise, there are also many mathematical elements that aren’t numbers per se, but special cases that result from mathematical operations. Think, for example, about the square root of a negative number: although the result of this operation is a valid complex number, it’s not a defined type (i.e. a number that the computer understands), therefore, it becomes something else. Or think about dividing any number by zero: this mathematical operation is undefined, and thus it yields a similar result.

These types of indeterminations are defined as a special floating-point value called NaN - which stands for “Not a Number”. The architecture of the CPU of the Nintendo Switch (ARM) handles these NaN values differently from the architecture used by any computer CPU (AMD64). For example, while a NaN is always produced as a positive value in ARM, it is always produced as a negative value in AMD64. These NaN values might also be quiet or signaling - a characteristic that determines whether the CPU detects a NaN value at the end of an operation, or in an intermediate step (which can be halted or not, depending on the program). Dynarmic is in charge of translating the code of a game from instructions understood by the ARM architecture into instructions understood by the AMD64 architecture. This includes ensuring these NaN values are represented properly. By toggling this optimization, however, many of these checks are now skipped by dynarmic in favor of performance. The reason is quite simple: most software, including games, ignore the sign and payload of these values, so it’s safe to ignore them.

MerryMage also submitted a PR to prevent flushing the cache when an ISB instruction is executed, fixing a wide range of games that ran at 1-2fps, such as Cobra Kai, Megadimension Neptunia VII, Super Robot Wars series, Windbound, and many others.

Megadimension Neptunia VII

In order to process instructions faster, modern CPUs read program code from memory and store it in a cache, because access times are much faster that way. But processing these instructions isn’t an instantaneous task. First, an instruction is fetched from the cache, decoded, executed, and the result is written back to a register or memory. To make this process more efficient, the CPU has a dedicated circuit for every one of these steps, and they execute these tasks for different instructions at the same time. This parallelization process is known as Instruction Pipelining.

The ARM architecture has a variety of special instructions (called Memory Barrier Instructions) that give the CPU better control over how instructions are written in and from program memory. One of these is ISB, which stands for “Instruction Synchronization Barrier”, and it’s used to flush the CPU pipeline and cache, so that all instructions following the ISB instruction are refeteched from memory. Normally, this is useful when running self-modifying programs, since there is new code being written into executable memory (where the program is stored), and flushing the queued instructions ensures that no old code is run. So, naturally, when Dynarmic executed an ISB instruction, the whole cache was being flushed on the assumption that it was outdated. This resulted in yuzu constantly flushing out and recompiling the cache, which translated as severe slowdowns and performance drops for certain games.

Now, here’s the catch. The Nintendo Switch is a platform that, with some exceptions, doesn’t allow for executable code to be rewritten. So, there will never be a case where yuzu will need to flush the cache this way, because games can’t overwrite code in memory. This PR changed the behaviour of dynarmic, so that whenever there’s an ISB instruction, it executes a NOP (no operation) instead - a special instruction that does nothing. This way, performance is not affected anymore, as yuzu doesn’t need to rebuild the cache since it safely ignores these ISB instructions.

On a different note, bunnei has been continuing with his work on the kernel. The first change introduced last month was a PR to rewrite threads to be more accurate. While there are not many visible benefits for the user due to the low-level nature of the change, it helped to fix a lot of smaller inaccuracies, including the softlocks in Animal Crossing: New Horizons when transitioning between scenes.

We don't judge you, Isabelle (Animal Crossing: New Horizons)

Originally, yuzu started as a fork of Citra, the 3DS emulator. Naturally, there is a remnant of code that was used on Citra and later modified to work for the Nintendo Switch. While it was fully functional and did the job, it was far from being accurate. KThread is yuzu’s implementation of computing threads, and this change aims to make it match as closely as possible to the implementation of threads of the real Nintendo Switch kernel.

The second change introduced last month is Refactoring of KEvent/KReadableEvent/KWritableEvent. A Kernel Event is a kernel primitive that is used to “signal events”, generally across processes. This is one of the simplest mechanisms used to communicate different threads: one thread signals an event, and then another thread waits for it. The KReadableEvent and KWritableEvent attributes are just an abstraction used to further enhance the synchronization across processes. These three objects are thus used to represent a single “signallable event”.

These mechanisms would be used, for example, when a game needs to play a sound. The audio service will produce a KEvent that will “signal” when it’s ready for more audio data from a game, and this will communicate with the audio thread so that data can be submitted and requested as needed by using these KReadableEvent and KWritableEvent attributes.

As always, the major benefit of these rewrites is accuracy. These changes will also make it easier in the long term to add the code of future updates that Nintendo might do to their kernel, since the behaviour of this implementation will be closer to the hardware and the existing code won’t need many changes to accommodate for it.

There’s still room for more additions and improvements, so stay tuned for more work on this area.

After a period of inactivity, FernandoS27 is back with a PR to optimize clock calculations by introducing a new method to compute time values, such as nanoseconds, microseconds, milliseconds, and also guest clock and cpu cycles, from the native clock of the CPU. This is a relatively small change, but since these calculations are performed often, all optimizations are helpful to reduce the time spent on these transformations.

Input changes

What can be better than QoL changes that you didn’t know you wanted until you saw them? german77 gives us just that by animating the controller input settings image on player actions. You can see the results yourself:

Your browser doesn't support mp4 video. :(

I like to move it, move it!

The animation will highlight the buttons that are currently being pressed. There’s also a second animation for the analog sticks to make the calibration of deadzones and range more intuitive. Your controller will behave in-game as shown by the animation in the settings, so if you think there’s any problem with your input, it’s a good idea to check if it’s working as intended here.

Input lag, the worst enemy of competitive games… And german77 comes to the rescue, by preventing overscheduling events.

Pokémon Let’s Go Eevee/Pikachu may disconnect the emulated controller, or fail to recognise the connection. By applying a delay to this process, german77 improves the stability of input emulation for this series of games. Handheld or single Joy-Con input modes are still needed to play this game, be sure to check your input settings in Emulation > Configure… > Controls. Swap the default Pro Controller to, for example, Handheld.

Users discovered that some games may continue to send vibration signals, this is due to the game never sending a 0 amplitude signal. Morph fixes those erroneous vibrations by adding a 1 second maximum time for any vibration.

In a double combo, Morph and german77 hit us with fixes regarding Handheld mode. A wrong behaviour regarding player 1 was addressed, which used to result in input changes not saving, especially in Handheld mode. A check was added to ensure Handheld mode is connected only in the correct npad_index value.

Holding a button would sometimes stutter, resulting in unstable behaviour. Morph adds a new method to check the duration of the press or hold of the buttons, resulting in stable behaviour.

Future projects

The merge of the Buffer Cache Rewrite will open the way to some improvements and fixes on the roadmap, epicboy will have some interesting things to show thanks to this. Morph is up to something. german77 is up to something. ogniK is up to something. bunnei continues to suffer with the Kernel rewrites. Rodrigo is making the first tests on Project Hades, while also planning a couple of nice Vulkan and video memory management improvements.

That’s all folks! Thank you so much for staying with us. See you in the February report!

And remember kids, winners update their GPU drivers to the latest version!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

New Feature Release - Buffer Cache Rewrite

CaptV0rt3x — Sat, 16 Jan 2021 21:00:00 -0300

Hey there, yuz-ers! The follow-up to our previous big code rewrite is finally here: the Buffer Cache Rewrite! This massive undertaking not only improves performance significantly, but also simplifies the code for our developers. Now let’s get this article started!

So, what does a Buffer Cache do?

As the name implies, a Buffer Cache — well — caches (stores) buffers. That might not have made much sense, but that’s what it does.

In graphics programming, for the GPU to render anything it needs data like position, color, etc. Usually, this data is supplied by the application. But when we have large applications dealing with large volumes of data, it becomes increasingly difficult to constantly supply the GPU with data and have it render. Hence, buffer objects were introduced.

Buffer objects are memory objects that store the render data in the GPU memory — thereby increasing reusability significantly. There are various types of bindings, commonly referred to as buffer types, like index buffers, vertex buffers, and uniform buffers (among others). This improves the rendering performance because the data is now readily available for the GPU to use.

yuzu’s Buffer Cache

Coming back to yuzu’s case, yuzu initially inherited a stream buffer — originally implemented for Citra by degasus. A stream buffer works in a modify/use cycle, meaning you frequently update the buffer object and you bind that region. Rodrigo and Blinkhawk later implemented our existing buffer cache to work alongside the stream buffer.

There was nothing inherently wrong with it; stream buffers are in fact one of the fastest ways to upload data to the GPU. But when Rodrigo profiled yuzu, the cache management and upload copies were something that kept popping up as slow.

Profiling

In software engineering, profiling (“program profiling”, “software profiling”) is a form of dynamic program analysis that measures, for example, the space (memory) or time complexity of a program, the usage of particular instructions, or the frequency and duration of function calls. Most commonly, profiling information serves to aid program optimization.

The problem lay in the fact that games aren’t exactly streaming data all the time. So using immediate uploads (on OpenGL) and faster caching yielded much better performance than having a stream buffer and caching large resources, at least for Nvidia. Upon further testing, we found that this turned out to be false for non-Nvidia drivers on OpenGL (AMD, Intel, and Mesa) and hence had to add a stream buffer for small uploads in these drivers.

What’s changed now?

The technical design goals for the Buffer Cache Rewrite were the same as our Texture Cache Rewrite.

Cleaner code: No more virtual function calls or shared pointers, meaning easier maintenance in the future.
Improved efficiency and improved performance.

Resolving which buffer existed in which memory region was a very expensive operation in our old buffer cache implementation. This is why the stream buffer existed — to make it faster.

The new Buffer Cache has vastly improved tracking for the various buffers it caches. In the new implementation, when buffers are created in the memory, they are forcibly aligned to 4K pages (4096 bytes - starting at zero). And to efficiently know what buffer exists on what address, the cache uses a flat array 32 MiB wide to translate from the current CPU page where the buffer exists to what buffer resides in it. e.g., if the address is 4096 or 7000, that is page 1 & if it is 8192, that is page 2. Thus, the new Buffer Cache can track what pages of a buffer have been modified on a page basis instead of being a binary state.

Imagine if a buffer has a size of 524288 bytes and a game modifies only 1 byte of the buffer. Since buffers are now aligned to 4096 bytes as mentioned earlier, only those 4096 bytes are uploaded to the GPU. The same thing happens when the GPU tries to update the cache with data modified by the CPU.

This tracking is done by making use of bit arrays in the buffers. Each value represents the state of the page - 1 being modified, 0 being clear. Keeping things in a bit array allows us to use efficient bit operations like std::countr_zero and std::countr_one (C++20). This results in fewer instructions yielding the same results (much faster).

All right, let’s talk performance gains!

The main focus of this work is to improve performance, but some graphical improvements also resulted from this rewrite.

Vertex explosions are no longer a problem in OCTOPATH TRAVELER

Font rendering is now working for all GPU vendors in Animal Crossing: New Horizons

Your browser doesn't support mp4 video. :(

Item drops stop flickering in Xenoblade Chronicles Definitive Edition

With that out of the way, let’s talk about performance. Of course, metrics will vary greatly depending on the hardware and API in use. Here are some examples measured after a couple of runs in the most demanding or common areas of the games listed:

Nvidia, in this example represented by an RTX3070, shows up to 84% improved performance in OpenGL.

AMD on the other hand, represented by a small RX550, shows an up to 55% improvement in Vulkan.

Regarding Intel, an unsurprising problem arises. All currently released products bottleneck due to immature drivers and simply lacking the raw power for Switch emulation. This results in little to no performance improvements with this rewrite. Hopefully this can be addressed with future improvements to both yuzu and Intel’s future drivers and hardware releases.

As a special mention, AMD Vega based integrated GPUs show an up to 223% increase in Paper Mario the Origami King, reaching the same level of performance as dedicated cards of a much higher calibre.

Fin

With that, we conclude our coverage of the new Buffer Cache Rewrite. As always, we would like to remind users that the features released in Early Access are still being worked on. If you come across any bugs, issues, performance loss, crashes, or regressions with this new feature, please reach out to us on our Discord server and share your findings.

See you next time,
- yuzu development team!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report December 2020

Honghoa — Sun, 10 Jan 2021 12:00:00 -0300

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.

General improvements and bug fixes

epicboy has been busy squashing bugs, in this case killing two with one PR. In some instances, we were trying to read data from an nvflinger buffer before it even existed. By adding a check addressing this, Yoshi’s Crafted World now boots, albeit with several graphical glitches. This PR also fixes how buffers are accessed, so several games now boot for the first time. Some examples include: Katana ZERO, DELTARUNE Chapter 1, Dragon Ball FighterZ and Wonder Boy: The Dragon’s Trap.

Now booting!

A PSA for our Intel graphics users. With the release of the Windows driver version 27.20.100.9126, Intel added support for not only the much needed VK_EXT_robustness2, but also VK_EXT_custom_border_color, improving performance and stability with the former extension and solving rendering issues in The Legend of Zelda: Breath of the Wild with the latter. Nothing better than free improvements for our integrated graphics crew running Vulkan. Latest is best!

Linux distributions compatibility, and the dependency issues that come with it, have been a long standing problem for our tuxedo-wearing users… Until now.

Thanks to toastUnlimited, we now provide AppImage builds, simplifying the installation process considerably. AppImages eliminate the dreaded dependencies issues, and bringing back support for Ubuntu 18.04, Debian Buster, CentOS 8, and many older distributions.

In the future, Early Access will finally be able to be distributed pre-compiled like this, the promise has been made. Thanks to the reduced source code compilation work hours, the CPU Union approves of this change.

During the time the Texture Cache Rewrite spent in Early Access, several regressions have been fixed. One of the notorious ones is related to the camera rune in The Legend of Zelda: Breath of the Wild.

As you can clearly see with Rodrigo’s… art, the game informs two different size values for the same texture, named pitch and width, so yuzu didn’t transfer needed information between them as it considered them different textures. By changing this behaviour, entities like animals, flowers, enemies, etc. are properly registered by the camera now.

Tony, get the boulder (The Legend of Zelda: Breath of the Wild)

There were some crashes when exiting yuzu that was related to the telemetry process. Tobi ported a fix from Citra that changes the type of AddField to a string, squashing one bug down.

A commonly reported issue was that configuration changes are lost if yuzu crashes. toastUnlimited changed this behaviour to simply save the current settings before booting a game. This change saves several headaches.

Morph implemented the new OSS fonts that Rei put together. With this, users no longer require to dump the Switch firmware to get proper button fonts. The firmware dumping process is still needed for games that have Mii related content.

It’s far cleaner to have ZL and ZR as a trigger button, than just the letters alone, don’t you agree? (Super Mario Maker 2)

A separate PR added +/- to the fonts.

THE anime swordsman (Super Smash Bros. Ultimate)

Some insight in the process behind this.

Some games report the wrong device handle when sending vibration signals, like NEKOPARA Vol. 3 (don’t Google this series). Morph fixed this by validating the device handles before use. Man of culture.

Kernel Rewrites

yuzu’s kernel received important changes this month, focused on refactoring the code for thread management and synchronization. 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. 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. 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. 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 – 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 introduced a PR to incorporate a syncpoint manager for nvdec. 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 is here. Thanks to work done by Tobi 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!

You can find this in Emulation > Configure > General > UI > Interface language

Anyone is welcome to help expand the available language list.

For our command-line or shortcut lovers, Morph adds command-line arguments. Current options are:

yuzu.exe "path_to_game" - Launches a game at path_to_game.
yuzu.exe -f - Launches the next game in fullscreen.
yuzu.exe -g "path_to_game" - Launches a game at path_to_game.
yuzu.exe -f -g "path_to_game" - Launches a game at path_to_game in fullscreen.

Feel free to create desktop shortcuts of all of your games!

Thinking of our fast typers, toastUnlimited added several menubar access hot-keys. Now, for example, a user can press Alt + F, R, ENTER to load the most recently played game. Look Ma! No mouse!

german77 added the option to resize yuzu’s window to 1920x1080, on top of the traditional 1280x720. This ensures a perfect 1:1 pixel ratio with native 1080p games while playing windowed, for those with high-resolution displays.

Input changes

german77 is back in action with a couple of input improvements.

Adding a way to invert an analog stick axis was a problem we did not expect to have on Xbox and PlayStation controllers, but some alternative brands don’t seem to follow the specifications very closely. Now if you right-click on an axis, you get the option to invert it.

This is also a great way to invert a camera if a game doesn’t allow it in its own settings, for example in Star Wars Jedi Knight II: Jedi Outcast.

Analog triggers were sometimes mapped inverted to what the user intended. As a way to avoid some bad moments to our users, now the program takes two samples when mapping an analog trigger, to better determine the direction of movement. This was ported from Citra, so thanks, guys!

A few games like Voez and The Room require specific touch gestures, and to achieve that, multitouch support was added. With this, yuzu now offers support for up to 16 touch inputs with the keyboard, touch screen or via UDP services.

Preliminary work for the Buffer Cache Rewrite

While we sadly couldn’t give you a Christmas present in the form of the Buffer Cache Rewrite (or BCR for short), the preliminary work needed to have it ready has started. Rodrigo has his hands full with cleaning up the TCR recently merged into Mainline, the current internal work and testing on the BCR, and his first steps with Project Hades. “Sleep is for the weak” indeed.

And you don't seem to understand... (Rodrigo sleeping)

We will go in-depth once BCR is completed, but one of the required features is having access to Vulkan at all times to make use of interop, a driver feature (or as Rodrigo calls it, a monstrosity) that allows developers to cross-code between different graphics APIs on Nvidia and AMD products. This way, Vulkan can be used from OpenGL if it offers a better solution to a problem.

A rather interesting change needed is related to Dynarmic. By masking data in three lower pointer bits before reading them, Rodrigo can now store required information of the page tables without needing to use a lock, saving precious execution time and, at most, some 128MB of system memory.

Lastly, additional granularity in the CPU pages. This PR allows informing if the CPU or the GPU modified a range of data in the CPU page. If the relevant range was modified by the CPU, it must be uploaded to the GPU. Processors supporting the BMI1 instruction set will get a slim performance improvement, these include Intel Haswell (Gen. 4) or newer, and AMD Piledriver (2nd Gen. FX)/Jaguar or newer.

Future projects

It’s no surprise, but the Buffer Cache Rewrite is close to release. Vulkan performance and stability improvements are planned, with kernel improvements continuing to be a high priority. Plus we also have some other interesting things we’ll reveal later on.

That’s all folks! Thank you so much for sticking around. See you next time in the January progress report! Take care and stay safe! Thanks to Darkerm and Morph for helping with the pictures.

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report November 2020

GoldenX86 — Wed, 09 Dec 2020 12:00:00 -0300

Salutations, yuz-ers! This is the November progress report which, for an unlimited time, will offer you hundreds of graphical fixes, improved performance, kernel changes, input additions, and major code cleanups.

4-JITs, four of a kind

bunnei and Blinkhawk 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.

This kernel refactor PR 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.

Your browser doesn't support mp4 video. :(

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 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).

Your browser doesn't support mp4 video. :(

World map in Super Mario Odyssey, before (left) and after (right) the changes, now stutter-free!

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, 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 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: a dynamic recompiler written by 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.

Memory usage before and after implementing 4-JITs

bunnei is still working on more cleanups and looking for things that can be further improved, so expect more updates in the future.

The Texture Cache Rewrite

We’ve already spoken in detail about the Texture Cache Rewrite in its dedicated article, so in short, the Texture Cache Rewrite (which is not a shader cache change) is work done by Rodrigo to reimplement the old texture cache yuzu used, which was forked from Citra. This effort took over 10000 lines of code, fixing graphical bugs in numerous games and improving performance along the way.

This paves the way for future important changes, like the Buffer Cache Rewrite, which is expected to not only continue to improve render accuracy, but to raise performance by optimizing the “hottest” code in the GPU section of our source, according to profiling. Afterwards, development of Project Hades is planned. This is a rewrite of the Shader Cache, with its main focus being improved precision and stability, and increased performance in Intel GPUs that are bottlenecked by the current implementation.

Expected soon-ish are the Compute Texture Decoders which will leverage the compute shader capabilities of GPUs to decode the texture formats handled by the Nintendo Switch games. This includes even elusive formats like ASTC, the main cause of non-shader related stuttering on non-Intel GPUs.

Your browser doesn't support mp4 video. :(

Prettiest fast-traveling (The Legend of Zelda: Breath of the Wild)

One sad point of this rewrite is that the “Vulkan memory manager”, now called the Texture Reaper, which was expected to help reduce VRAM use in Vulkan, will take longer to implement due to technical complications that surfaced during its development. There is more detailed information in the dedicated article.

A small PSA, AMD users should install the 20.11.3 driver version or newer, as it adds VK_EXT_robustness2 to all missing Radeon products, helping in stability and precision.

Project Aether, or how to visit yuzu from within yuzu

Nintendo Switch games have access to a web applet that is typically used to show tutorials or guides while playing. Our original implementation using QtWebEngine had some lasting bugs that impeded gameplay in some cases, like the tutorials on a first boot of Super Smash Bros. Ultimate.

Morph rewrote yuzu’s web applet, still based on QtWebEngine, but completely overhauled. The web applet now accepts controller input instead of only touch emulation via mouse, and rendering fonts extracted from the native OS on the Switch, or using Open Source Software fallbacks.

Working tutorials in Super Smash Bros. Ultimate

Previously non-rendering applets are now working. This includes the few cases where games got stuck due to the previous implementation, like in Super Smash Bros. Ultimate. Mods that bypass the applet are no longer required, like in Super Mario Odyssey.

There are limitations listed in the Pull Request that we will continue to work on. Expect this change to force our minimum Ubuntu version requirement to 20.10 in the future due to the need to update Qt to version 5.14.2 or higher.

yuzuception!

General bug fixes and improvements

Rodrigo brings the Xenoblade fans a nice little fix. Implementing early fragment tests fixes ghost geometry problems that resulted in dark rendering areas.

Like night and day! (Xenoblade Chronicles Definitive Edition)

This fix will be a Vulkan exclusive for now to avoid invalidating the current OpenGL shader cache.

More vulkan fixes, now by epicboy! He implemented the missing alpha test culling feature from Vulkan, resolving transparency related rendering bugs. This could be easily spotted in the main menu of Super Smash Bros. Ultimate or the vegetation of Tales of Vesperia: Definitive Edition.

Those are some weird plants (Tales of Vesperia: Definitive Edition)

While we are speaking about epicboy, he also improved the quality of the NVDEC video decoder, by queueing all frames and cleaning up the code. This results in reduced skipped frames, and greatly improves videos encoded in VP9.

Your browser doesn't support mp4 video. :(

Do you need a hand? (Super Smash Bros. Ultimate)

Your browser doesn't support mp4 video. :(

An example of embedded videos during gamplay (Super Mario Odyssey)

There has been some progress in World of Light playability, the single player campaign of Super Smash Bros. Ultimate. The main problem is not fixed yet, but thanks to bunnei stubbing GetAlbumFileList3AaeAruid, now users can do a single fight in World of Light, save, restart yuzu, and do another one. We’re slowly getting there!

Later updates of Animal Crossing: New Horizons fail to load, but by stubbing OLSC Initialize and SetSaveDataBackupSettingEnabled, bunnei restored playability once again. You can now enjoy all the new content and events added with the latest update.

ogniK started preliminary work on future fixes for audio emulation. This change currently improves fidelity in games like Shovel Knight and the LEGO series. Expect more audio related changes soon.

yuzu has always been unstable when stopping emulation, and there are several reasons for this. bunnei fixed two distinct cases, when closing while shaders were compiling, and when closing early during the boot process. Quality of life fixes are always welcome.

Input improvements

You’ve been asking for it for ages, and german77 delivers. Mouse support is here! With this, users can now set their mouse as they desire, be it an analog stick, buttons, motion, or touch screen emulation. A controller with motion support is still the recommended input method, but a mouse can save you in a pinch.

As an extra gift for keyboard users, german77 also added support for better analog emulation with keyboard inputs. With this change, keyboard players can now “drift” the emulated analog stick to get any angle, not just the fixed eight directions you can get by pressing key combinations.

You can find this setting in Emulation > Configure... > Controls > Advanced > Emulate Analog with Keyboard Input

german77 also enabled the use of up to 8 different UDP servers. This allows for motion controls for each player.

By using NpadStyleSet, Morph now limits the available input options depending on the game. For example, in Pokémon: Let’s Go, the options are now limited to either Handheld, Left Joy-Con, or Right Joy-Con.

No cheating!

german77 tweaked the rumble amplification function, making it more linear and less aggressive. This should help when low strength percentage values are used.

By stubbing both SetNpadCommunicationMode and GetNpadCommunicationMode, german77 made Borderlands: Game of the Year Edition and Borderlands 2: Game of the Year Edition playable!

A silent Guardian, a watchful Protector

Lioncache, our harsh but fair code reviewer, has been removing the global variable accessor from the whole project (the linked PR is just the latest section), work that has taken months. yuzu used to be able to run a single global system instance, but with this change, yuzu can now create as many emulated instances as needed, all separate from each other. This provides full control over the life cycle of the emulated system, allowing among other things, faster game boot times, and maybe more importantly, forcing the devs to keep up cleaner code, which is easier to maintain in the future.

Future projects

The Buffer Cache Rewrite has been progressing very fast with no delays so far, and Rodrigo is very enthusiastic about starting Project Hades after finishing it. More multicore changes are incoming, along with input improvements.

That’s all folks! Thank you so much for taking the time to read this progress report. See you next month, maybe Christmas will come early!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Mini-Series - Dev Interview #3

MysticExile — Thu, 03 Dec 2020 01:45:00 +0100

Hey there yuz-ers, welcome to the third Developer Interview! It’s been a while since the last installment of this mini-series, so let’s jump right into the good stuff.

This time we’re interviewing the myth, the legend, epicboy! He is the main reason why we have NVDEC now! If you didn’t know already, NVDEC is Nvidia’s video decoder used by the Nintendo Switch. Without him, we wouldn’t be able to watch videos like Fire Emblem: Three House's intro or The Legend of Zelda: Breath of the Wild's memories. But that’s not the only thing he has done! He was also responsible for asynchronous shader compilation on the Vulkan renderer, GameCube Controller support, and Alpha Test Culling on the Vulkan renderer. And now, on to the interview!!

Q: Hey epicboy, why don’t you start by telling us a bit about yourself?

E: I’m just a typical college student majoring in Computer Science. I’m in my fourth year of studies out of five, pursuing both a BS and MS degree. To be honest, I’ve been suffering from imposter syndrome in my classes, so I wanted to put my programming skills to the test. That’s what drove me to contribute to yuzu; a real-world test of the knowledge and experience I gained from my classes to prove to myself that my time at college hasn’t been a waste.

Q: Why did you choose yuzu, a Nintendo Switch emulator, specifically?

E: When I first heard of yuzu, back in 2018, I was impressed by the progress made on Switch emulation so soon after the console’s release. I continued to follow the project’s progress and was inspired by the never ending drive and effort of the developers. Soon after Super Smash Bros. Ultimate was announced as playable on the emulator, which sounded too good to be true, I gave the emulator a shot and was blown away at the compatibility. Of course, it wasn’t perfect, especially given that my beloved controller of choice, the Nintendo GameCube controller, was not compatible with the emulator.

Q: So you decided that it was time to take matters into your own hands and add support yourself?

E: Knowing that other emulators (notably Dolphin) had proper support for the official GameCube adapter, and considering I was looking to sharpen my programming skillset, I decided to take the opportunity and see if I can bring that support over to yuzu, opening the option to use the GameCube controller for anyone on the emulator.

Q: I’m sure our GC controller users are very happy with your contribution! Why did you choose to tackle such a large task as NVDEC?

E: I found the code review for the GC adapter implementation to be really useful. I wanted to learn more from the very sharp yuzu developers and continued to make more contributions and became more familiar with the yuzu dev team. One feature that I saw many yuzu fans request was for video decoding. I learned that ogniK had attempted to implement NVDEC before and reached out to get an understanding of this feature’s scope and challenges faced along the way. Before I knew it, I had access to the repository with the old implementation’s code and was encouraged to find a way to finish it off.

It was intimidating at first, but the encouragement and mentorship from ogniK kept me motivated. It was also the first glimpse I had at the guts of yuzu, and found the work that has gone into the emulation of the Nintendo Switch’s GPU to be very interesting.

The Legend of Zelda: Link's Awakening

Super Smash Bros. Ultimate

Q: What obstacles did you have to overcome when implementing NVDEC?

E: The earliest challenge was to understand what the data I’m looking at means. At the GPU command level, everything is hexadecimal numbers with no obvious meaning tied to it. Thankfully, there have been others who reverse engineered and documented the processes that the GPU goes through for the NVDEC functionality. I was able to get quite far with decoding H.264 videos with the help of ogniK’s older implementation. But the VP9 encoded videos found in many games were very difficult to decode.

In order to decode VP9, I needed the frame data along with a “compressed” and “uncompressed” header to be sent to FFmpeg, a library which is widely used for video decoding. The Switch GPU provided me with the frame data, but the headers needed to be manually constructed based on meta data provided by the GPU. I found myself spending countless hours reading the VP9 specification, and analyzing the video frame-by-frame in a tool that displays each frame’s headers. Ultimately, it paid off, and many VP9 videos are decoded accurately.

Your browser does not support the video tag.

Q: Quite the task I imagine. Why did you opt for the FFMpeg library instead of other alternatives?

E: FFmpeg was kind of a no-brainer. It’s fast, it’s open sourced, and it’s well documented. It handles decoding with little effort on the programmer’s part. It also provides API’s to re-scale and convert video formats, which proved to be useful. The other alternative would have been writing my own software decoder from scratch, but there’s no point in reinventing the wheel!

Footage of one of The Legend of Zelda: Breath of the Wild's memories.

Q: No kidding! Is there anything you’re currently working on?

E: Of course! I’m always looking for the next opportunity to contribute to the project while continuing to learn and grow as a programmer as well. There’s still some work left for me to finish up for the NVDEC implementation, so I haven’t decided on what I’d like to tackle next. All I can say for now is that I genuinely enjoyed GPU related programming.

Q: We look forward to your future contributions! Is there anything else you would like to share to our users?

E: I’d like to say “thank you” to all the yuz-ers! They are always appreciative of the work the yuzu developers put into the emulator, and are always excited to know what’s next for the project. Their demands can sometimes be overwhelming, but it continues to motivate the developers, and it’s always gratifying to see the positive reaction they have when a feature they’ve been looking forward to finally becomes a reality.

A huge thanks to epicboy for taking the time to sit down and give us some insight on NVDEC and himself. We hope you all enjoyed it, and we will be back soon with another featured yuzu dev to bring you behind the curtains again. Until then, thank you for your support and stay tuned!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

New Feature Release - Texture Cache Rewrite

GoldenX86 — Sun, 22 Nov 2020 16:00:00 -0300

Hi yuz-ers! We’re very excited to offer you one of the biggest code rewrites in yuzu’s history: The Texture Cache Rewrite! Now available to our Early Access members, continue reading to learn more.

But what is the TCR?

yuzu started as a fork of Citra, so Citra’s texture cache (or rasterizer cache, as it was called at the time) was used in the early days of yuzu. However, this cache only supported OpenGL, so one of the first efforts when adding support for Vulkan was to make the code more generic, helping in GPU emulation.

When this was being worked on, we were still learning how the Nintendo Switch’s GPU worked (we still are, but even more so then). Some design decisions taken at the time stuck with the codebase making things harder to change in the future. It was also easier to break with unrelated changes.

So out with the old, in with the new. The previous implementation was no longer sufficient, so Rodrigo started working on a complete rewrite from scratch. This includes but is not limited to:

Cleaner code. No more virtual calls or shared pointers, this allows for easier maintenance in the future.
Proper handling for texture swizzling.
Some operations are now done in the GPU instead of in the CPU, improving performance.
Control over when to destroy textures.
Previously, textures were removed from the cache on CPU writes, but now they are flagged as dirty. This allows yuzu to cache already visited image views and render targets, saving time.
Multiple textures can coexist in the same address now.
Aliased images are now emulated through copies on demand.
Rendering to compressed textures is properly emulated.
3D BC4 textures are emulated with RGBA8.
Rendering to texture views of different compatible formats is emulated without copies.

A very detailed explanation from our developer

OK, but how does this help?

In short: it fixes a lot of graphical bugs, improves performance, and is not limited to any hardware configuration or driver in use. Improvements for everyone, once all parts are finished.

Before we talk about performance, here are just a few examples of the rendering fixes you can expect to see with this release:

Shadows in Splatoon 2 are now rendered correctly, finally allowing us to admire the beautiful cityscape

Lighting and stencil shadow corruption is now fixed in Luigi's Mansion 3

Astral Chain no longer exhibits black texture corruption

Depth of field issues are gone in Animal Crossing: New Horizons

Xenoblade Chronicles 2 is free from vertex explosions on AMD Vulkan drivers

Your browser doesn't support mp4 video. :(

Texture swapping & flickering issues are fixed in all Xenoblade Chronicles games

Jumbotrons now display correctly in Super Smash Bros. Ultimate. Here’s an example running in the radeonsi mesa OpenGL Linux drivers

yuzu now has Multisample anti-aliasing (MSAA) support, as shown in SONIC FORCES here

Your browser doesn't support mp4 video. :(

Slow rainfall fixed in The Legend of Zelda: Breath of the Wild (Requires High GPU accuracy)

Your browser doesn't support mp4 video. :(

Rune transportation renders just like native hardware in The Legend of Zelda: Breath of the Wild

But what about performance?

On top of the rendering improvements, many games show a 10-30% improvement to framerate, with greatly improved frametime stability as demonstrated below:

Your browser doesn't support mp4 video. :(

Luigi’s Mansion 3 received some huge leaps in rendering accuracy *and* performance, notice the frametime graph

Your browser doesn't support mp4 video. :(

Super Mario Odyssey

Your browser doesn't support mp4 video. :(

The Legend of Zelda: Breath of the Wild

Your browser doesn't support mp4 video. :(

Animal Crossing: New Horizons

Current limitations and future progress

Due to these changes, hardware lacking the VK_EXT_robustness2 extension will not produce the optimal experience. In Windows, this includes AMD graphics cards older than Vega (Polaris and older series) and all Intel iGPUs to date. You can check the current support here. Games requesting this extension on unsupported hardware may behave randomly or crash in rare instances. A fallback code path is being worked on. Make sure to be up to date with your drivers, as the GPU vendor may be able to add support in the future if the hardware allows it.

Originally, Bindless Texture support was expected to be added, but several difficulties emerged during development. One of the problems is the lack of native hardware support for ASTC texture decoding. If we used uncompressed textures, GPUs with less than 8GB of VRAM would not be able to load all the game assets, and if we recompressed them in another texture format to avoid this problem, image quality would degrade. True bindless texture support can be considered again in the future.

Depth Stencil Blits are not implemented on Vulkan for devices that don’t offer native support (any AMD and Intel GPU).

Another complication that emerged during development is related to memory management. The idea was to release the Texture Cache Rewrite with what the team calls the Texture Reaper, a way to remove textures from VRAM that have not been used after some time. While this has been almost working in OpenGL during testing, managing to run Luigi’s Mansion 3 in under 300MB of VRAM, Vulkan on the other hand received no benefit.

Vulkan faces one main problem: it fragments the memory when textures need to be mapped to contiguous video memory. There’s no tolerance for fragmentation, so freeing blocks will not help at all if the next texture doesn’t fit in the new empty space. This will require the development of a VRAM defragmentation routine, work that can take quite some time. So we can say that today marks the day Project Texture Reaper starts.

A feature that will be added shortly later will be Accelerated Texture Decoding, which will handle any texture format via Compute Shaders, even formats the GPU doesn’t support natively. epicboy is working on the ASTC compute decoder.

The next project Rodrigo is working on is the Buffer Cache Rewrite. This work promises to solve more rendering issues (for example font rendering problems) and seriously improve performance, especially on memory bandwidth starved hardware like integrated GPUs.

And with that, our overview of the Texture Cache Rewrite is finished! Please report any bugs or problems you face with this new feature on our Discord server or on our Forums.

HONK

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report October 2020

Honghoa — Tue, 10 Nov 2020 12:00:00 -0300

How’s it going, yuz-ers? Here work continues. This month’s report offers you mythological hammers dropping, Vulkan and OpenGL stability fixes, and some news on the continued fight to make Super Mario 3D All-Stars render.

Project Mjölnir

Part 3 - Smite as hard as you desire

Morph strikes again with part 3 of Project Mjölnir - a major rewrite of yuzu’s Human Interface Device (HID). This concludes months of hard work that also involved the contributions of Rei (who designed the new user interface) and jroweboy (who started the original HID rewrite that later Morph continued).

Just as three different gifts were given to the Nordic gods by the dwarves (including the iconic hammer of Thor), this project was divided into three parts focused on different aspects of emulating the input control of the Nintendo Switch.

The first part was centered on overhauling the user interface, as well as modifying and fixing errors in the backend that handled the mapping and detection of controllers. These changes allowed yuzu’s implementation of input to behave more closely to the hardware, improved the user experience, and also paved the way for the subsequent improvements in the following PRs.

The second part took care of implementing the Controller Applet: a service used by games to communicate and set up the kind of controller input they can accept, how many players will use them, what character they will control, etc.

And now, at last, comes the third part of this project: introducing bug fixes, Controller Profiles, and an overhaul to the implementation of Rumble realized by german77.

Your browser doesn't support mp4 video. :(

Loading a profile for a Sony DS4 controller

Controller Profiles had been a placeholder since Part 1 of Project Mjölnir. They allow users to set up the configuration of their gamepads and save them in a file, which can be loaded and marked with a distinctive name. This is particularly useful for people who own more than one type of controller, since they store all button and axis information, as well as the port and engine used to read the input data. Changing between one configuration and another becomes as simple as clicking a dropdown menu and choosing the desired profile, and all the settings will then be applied automatically. Users now can create a profile by simply clicking on the “New” button and writing a descriptive name to save it.

Modifier Buttons was also another feature that wasn’t working well since Part 1. A Modifier Button allows the user to change the range of an axis on the fly by pressing it, which is particularly useful when said axis is mapped to digital buttons instead of an analog stick. This is because digital buttons are interpreted as a “virtual axis” that is being pushed from the minimum value (0%) to its maximum value (100%) every time they are pressed. With this change, it is now possible to set the maximum value of this axis to a value lower than 100%, effectively limiting its range. Useful for walking or sneaking!

Next on the list of fixed bugs, we had a controller reconnection issue. Sometimes, a controller instance was being pushed back into memory right after being disconnected. This faulty behaviour was a bug that prevented the controller from being recognized by yuzu when it was reconnected by the user again. Morph implemented a simple guard to avoid this and solved the problem.

For some games, vibrations didn’t work properly, or at all. To understand why this was happening, we will need to explain a bit of what’s going on behind the curtains of abstraction, so please bear with us here.

Rumble in the Nintendo Switch is physically generated by a pair of identical Linear Resonant Actuator motors that can emit a wide range of frequencies on the low and high spectrum, independently from each other. This contrasts with the approach used in other controllers, which typically have low frequency Eccentric Rotating Mass (ERM) motors at the left side and a high frequency ERM at the right side; depending on the desired frequency band at which one wants to make those controllers vibrate, it is possible to send signals to one or the other and thus accomplish low and high frequency rumble. The Nintendo Switch also characterizes vibration in such a way that it’s possible for games to distinguish between the left and right motors of different players. This is because each device has an identifier handler that is used to send the correct vibration commands to the right place.

Prior to this PR, the functions that processed this handler information weren’t coded yet, or they were stubbed and returned incorrect information. Even with those limitations, this exceeded the capabilities of the SDL library (an API that yuzu uses to communicate with the hardware of the input devices), which was designed to work with generic gamepads that do not present any of these unique features of the Nintendo Switch. As a result, the rumble wasn’t being processed correctly. This resulted in inaccurate behaviour, such as the lack of vibration for the controllers of players other than player one, since this handler information wasn’t available for SDL to distinguish where to send the vibration signals other than for “controller 0”. In order to make vibrations work as intended, Morph investigated how this information was characterized and implemented the functions to process these handlers, so that the vibration data could be sent to the appropriate devices and players. The addition of these functions also fixed a number of games, such as Xenoblade Chronicles: Definitive Edition, Xenoblade Chronicles 2, Hollow Knight, and many others that previously didn’t exhibit rumble at all.

Previously, some people using certain types of wireless controllers reported in-game performance losses whenever their gamepads rumbled. The root of this issue lied in the rate at which the vibration states were being updated to these controllers, so german77 implemented a solution to reduce the rate to 50 Hz and filter out some of the vibrations. But it was later reported that some vibration effects were missing in games such as Super Smash Bros. Ultimate due to this filter, so an alternative solution was needed. For this reason, Morph implemented Accurate Vibrations, a toggle option (off by default) that switches between a full implementation and one with the effective vibration rate reduced through heuristics. If this option is disabled, the vibration rate is limited to 100 vibrations per second, excluding vibrations with an amplitude value of 0 (which is considered as the “not vibrating” state). This rate was determined to be safe through testing done by Morph and Ren.

Vibration Configuration Window

These changes were enough to fix the stutters experienced by these users. In order to toggle Accurate Vibrations on, the user should navigate to Emulation > Configure... > Controls and click on “Configure” under the “Vibrations” tickbox. They can also change the intensity of the vibrations for each player, if desired.

Furthermore, an additional check has been implemented when initializing a vibration device to determine if a controller is apt to rumble or not. It consists in sending vibrations with an amplitude value of 0 and reading the value sent back from the controller. While this approach works fine for the GameCube Adapter, SDL returns an incorrect value if two vibration signals with identical amplitudes are sent to the device. To work around this problem, yuzu first sends a vibration with an amplitude of 1/65535, then one with amplitude 0, and then reads the value returned from the device. This check is extremely important, because it helps in implementing the necessary functions that tell the games if the vibration device is properly mounted and capable of rumble, and it also makes it possible for yuzu to disable rumble capabilities in the backend automatically if a controller doesn’t support it.

On top of these changes, work has been done so that anyone can plug in their favorite controller and, if it supports vibrations, all configuration related to it will be applied automatically. In the case that the controller doesn’t, however, rumble will be disabled on the backend.

Manually mapping an analog stick

It is worth noting that, in case the automatic configuration process fails, users can map their analog sticks manually by clicking on any of the axis mappings. This solves issues with certain controllers that have their axis mapped as digital buttons.

Project Mjölnir has come a long way since it started. Major parts of yuzu’s original code for input were rewritten, tested, and ironed out. Vast parts of the input frontend and backend were overhauled in favour of a more user friendly interface, aiming to make it easy to configure your controllers in the most intuitive way (and many of these configurations are also being applied automatically). Much of the effort done by the devs is easily perceivable, but there’s also a lot of work that went into making things run perfectly behind the scenes. Hours of investigation, lining up the details, and polishing every addition. Indeed, our devs gave it their best, just like the dwarves in the Eddas, to present you with this gift. The Nordic gods debated which among the three presents they received was the best, and they concluded the hammer was, without any doubts, the most precious of them. It is our most sincere wish that you will accept this hammer from us, and smite as hard as you desire!

As a small sidenote: In the Edda, the dwarves happened to ask for Loki’s head as compensation for the gifts. But don’t worry, we won’t go that far with you! (Yet).

Back to the Pokéfuture

A highly requested fix, and understandably so. Pokémon has long been a franchise that uses time as a game mechanic. In yuzu, this feature was not working as intended with Sword and Shield. What would normally be saving, closing yuzu, and loading in later expecting time to naturally pass, ends up as if nothing happened, rendering several events (like berry respawns, changing weather, Pokéjobs, different Pokémon spawns, or just simple time of day changing) useless. We don’t have a proper fix to naturally progress the time yet, but for now, thanks to the work done by bunnei, it is now possible to bypass this problem by changing the clock from yuzu’s settings during gameplay.

You can find the setting in Emulation > Configure... > System, enable Custom RTC, and then enjoy time travelling!

Try to avoid changing the divergence value, Doc!

Greetings, Professor! Fixes to report!

Rodrigo has for us a couple of stability improvements for Fire Emblem: Three Houses, only involving Vulkan and assembly shaders (GLASM) for now.

On the Vulkan side, managing primitive topologies as fixed state fixes regressions introduced by recent Nvidia drivers, but it has been reported to also help AMD Radeon users quite a bit too.

On the GLASM side, and benefitting our Nvidia users the most, implementing robust buffer operations like it is done in GLSL helps make the game playable when using this very useful shader implementation.

I have something to ask of you (Fire Emblem: Three Houses)

Crashes will still be experienced in specific chapters of the game, like Ch. 15 and Ch. 17. For those cases, we can offer you a workaround:

You need to download one of the following old builds: yuzu 66 or yuzu 41.
Set it up as a standalone version by extracting it and creating a user folder where yuzu.exe is located.
This folder will replace %appdata%\yuzu, so you need to extract a copy of your keys there, along with any save data you want to transfer to get past the crashes. Make sure to also copy your nand folder so you can transfer all DLC and updates to the standalone yuzu build.
Play the game, expect tons of glitches and pretty bad performance for such an old build. Save after progressing past the crashing area and transfer that save to the latest Mainline/Early Access version you are using, and continue playing regularly from there.

Emuception

bunnei seems to have a personal vendetta with Super Mario 3D All-Stars. He has:

The last one also improves stability in games like Luigi's Mansion 3. The only thing missing to get Super Mario 3D All-Stars rendering is the Texture Cache Rewrite.

NVDEC improvements

Work on video decoding continues, thanks to epicboy. Some games like Onimusha: Warlords and Ni no Kuni had an incompatible BGRA8 format in our first NVDEC implementation. Now they render correctly.

Working menu rendering (Ni no Kuni)

Unfortunately, a select few games like FINAL FANTASY XII THE ZODIAC AGE, The Legend of Zelda: Link's Awakening, and Onimusha: Warlords currently have problems with memory addressing, causing incorrect video decoding and various graphical glitches (flashing/flickering). While there is a workaround in place in Early Access builds, this fix is not stable enough to be considered mergeable. Once a more elegant solution is found, we will let you all know.

Happy moments (Onimusha: Warlords)

And last but not least, NVDEC is now in Mainline! Anyone can now enjoy the in-game videos in yuzu. As the tradition for all merged Pull Requests, Lioncache didn’t take long to clean it up.

Non-mythological input changes

We have some great changes made possible from the work of german77. Thank you!

To start with, buttons that are impossible to use on certain input configurations are now blocked. For example, if an emulated Pro Controller is changed to a left Joy-Con, the right stick, A, X, Y and Z will no longer be accessible to the games. No cheating!

Up next, some devices have access to an accelerometer, but lack a gyroscope. While this setup is basically useless for full motion, it can be used to detect simple shaking motions, so we don’t see why we shouldn’t add support for that.

And finally, for our traditional fighters out there, we have some improvements for GC adapters. Adapters can now be hotplugged, basic rumble support was added, and compatibility with more vendors was improved.

A new challenger approaches! FrogTheFrog tuned up the shake values to improve compatibility with the rare Steam Controller. Wouldn’t having Portal and Portal 2 on the Switch be awesome?

Bug fixes and improvements

bunnei changed the values for Multicore, Asynchronous GPU, and Assembly Shaders to be enabled by default. This will help provide a much better experience out of the box to all users that haven’t changed those values already. Some other advanced settings like Asynchronous shaders are not altered by this change as they still require further testing and bug-fixing.

By implementing CUBE textures and fixing an issue with arrays, Rodrigo made the Pikmin 3: Deluxe Demo playable. This will most likely help in making the final game playable too.

Thanks GG for the capture! (Pikmin 3: Deluxe Demo)

In a minor change to Vulkan, Rodrigo changed the way GPU devices are sorted in yuzu, helping pick the best GPU according to yuzu’s current compatibility and needs.

A developer's system, gotta render 'em all!

The current method follows these rules:

Priority will be given to the GPU vendor following the Nvidia > AMD > Intel order.
Dedicated hardware will take priority over integrated. For example an RX 570 will have a higher priority than an Intel UHD630.
The device name will be considered, a GTX 1650 will be selected over a GTX 1060. Most of the time, newer architecture generations offer better performance benefits than pure raw performance.

In the previous progress report, we mentioned that we removed a blacklist on AMD GPUs for the VK_EXT_extended_dynamic_state Vulkan extension. Turns out, RDNA1 GPUs crash to the desktop while using this extension, so Rodrigo (while using your writer’s PC) had to manually add a new blacklist only including current Navi based GPUs. One would expect that a reported extension is tested before releasing the drivers that start supporting it… The 20.10.1 driver version from AMD seems to revert to an older Vulkan version lacking this extension, so the Red Team is aware of the issue.

epicboy changed how Asynchronous Shaders determines the amount of threads to use, increasing it for higher thread count CPUs. Past the 8 threads mark, one shader thread is added every two CPU threads.

CPU Threads	Shader Threads	Example CPUs
1 - 7	1	R3 3200G, i5-9400
8	2	R3 3100, i3-10100
12	4	R5 3600, i5-10400
16	6	R7 3700X, i7-10700K
32	14	R9 3950X, i9-9960X
128	62	Threadripper 3990X

Kewlan is back again, fixing another important UI bug. This time, yuzu will no longer ask for a profile if there is a single one created. The devil is in the details.

Morph added a check to see if a directory is a nullptr. This fixes save file creation in Hades. However, more work is needed to get the game playable.

With the demo just released, Rodrigo started the work to get Hyrule Warriors: Age of Calamity - Demo Version playable. By implementing FCMP immediate and texture CUBE array shadows the game starts to render.

Where are my glasses? (Hyrule Warriors: Age of Calamity - Demo Version)

We personally want to thank Lioncache. He’s not mentioned much in the progress reports due to the technical nature of his work, but he is without a doubt one of the top contributors to the project. Thank you Lion, for the patience you have, and the huge help you give us.

Future changes

There are some important core fixes incoming: Local Wireless emulation continues to progress well, we have more plans for NVDEC progress on their way, and there is now a roadmap of what will follow the Texture Cache Rewrite once it’s finished, but we will tell you more about that later.

As an early gift, here’s a preview of the Texture Cache Rewrite’s progress:

And that’s all folks! Thank you so much for reading, and see you all in the next progress report! Thanks GG for the pics!

Image by https://twitter.com/JamesTurner_42

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Online Support Removed

CaptV0rt3x — Mon, 02 Nov 2020 18:00:00 -0800

We are saddened to report that we have removed online support from yuzu, indefinitely, and effective immediately. We apologize to our community for the confusion and disappointment surrounding this release, and especially to those who were excited to try this feature.

We have received valid and insightful feedback from our fans and members of the broader Switch and emulation communities. Truthfully, we are all just a bunch of enthusiastic people from around the globe, who were genuinely excited about something we thought we could offer. In hindsight, we 100% understand your concerns.

As always, we will continue working on other features and improvements within yuzu, to make it the best emulator we possibly can. Thank you to everyone who has continued to support us, provided us feedback and been open to constructive discussion on this topic. Now, as always, we value your opinions.

– The yuzu development team

Progress Report September 2020

Honghoa — Wed, 30 Sep 2020 12:00:00 -0300

Greetings yuz-ers! Welcome to September’s progress report. This month we offer you the joy of motion, video playback, more input fixes and additions, small Vulkan improvements, and the initial groundwork needed to get Super Mario 3D All-Stars playable.

Ya like to (move it!)

Many popular Nintendo Switch titles have mechanics designed with motion controls in mind, so naturally this was a long-awaited feature that a lot of people wanted to see implemented in yuzu. We are very happy to announce that, thanks to the efforts of the developer german77, it is now possible to use any controller that supports motion sensing and play these games the way they were meant to be played. Just be careful not to hit anything when you shake it!

Your browser doesn't support mp4 video. :(

Functional Motion Input ('A SixAxis tester by German77', a homebrew application).

This feature’s development began back in July, when german77 was working on the implementation of a native Joy-Con adapter for yuzu (a task still in the works). While he was analyzing the data sent by the controllers, he realized he could read the values reported by the accelerometer and the gyroscope as well. Feeling curious about what could be done with this knowledge, he experimented with implementing new inputs and feeding them the output from these sensors. The result was quite satisfactory: not only did this work, but it became the main motivation to investigate and implement motion controls the same way they work on the Switch.

german77 was aware of a previously discontinued PR for motion by anirudhb and decided the best course of action would be to take it from there, fix any incompatibilities, and sort out the subsequent bugs introduced. As he ironed out the implementation, he tested how it performed with the game Captain Toad: Treasure Tracker. The results this time, however, were far from satisfactory. Controls felt unnatural and responded quite differently compared to the Switch, indicating an error in how the values sent by the controllers were processed. To better understand the problem, german77 developed two homebrew applications to identify and fix these inaccuracies.

After a long period of extensive testing, and with the help of theboy181 (who focused on testing the feature on different games), german77 finally realized the problem laid in the implementation’s logic: there was an error transforming a quaternion into a rotation matrix. For the people allergic to math, you can think of a quaternion as a system to describe orientations and rotations in a 3D space, and a rotation matrix as a “translation” from a quaternion to a familiar (x, y, z) Cartesian coordinate. Thankfully, once this error was fixed, almost all the games that showed problems started to work flawlessly!

Your browser doesn't support mp4 video. :(

Motion in action. Top: 'Super Mario Odyssey', bottom: 'The Legend of Zelda: Breath of the Wild'.

Motion controls currently work with Wiimotes, Joy-Cons, Pro Controllers, DualShock 4 Wireless Controllers, and even cellphones (provided they have an accelerometer and a gyroscope). To bridge these devices to yuzu, the implementation makes use of the DSU protocol (also known as “CemuHook UDP”), so users need to utilize BetterJoy (for Nintendo controllers), ds4windows (for Sony controllers), or any app that supports CemuHook for cellphones or other compatible devices. You can check this guide for more information regarding how to set up your controller. Make sure to try it out!

Bear in mind that devices such as generic copies of official Nintendo or Sony controllers may work, although it’s not guaranteed. Needless to say, no matter how hard you shake your keyboard and mouse, that’s not going to work, so please don’t do it!

I have no motion, and I must shake

If your favorite controller has no support for motion controls (such as Xbox controllers), don’t worry, not everything is lost. After implementing functional motion controls, german77 also made this follow-up PR to implement a button to simulate a shake. This will allow you to configure any key of your liking to work as if you were physically swinging your controller and activating the in-game motion mechanics.

While this should work with games such as Super Mario Odyssey and others, do note it won’t be able to cover all cases or titles. Every game is different, and the required input is not always just a shake.

Remember the Rumble Pak?

Also thanks to german77, yuzu can now proudly boast Rumble support. Any SDL2 compatible device will vibrate when asked by your Switch games. This includes but is not limited to: DualShock, Xbox, and Nintendo controllers.

HD Rumble is not possible, yet. The SDL2 specification is incompatible, and not everyone will play with Nintendo peripherals. This means that a Pro Controller or a pair of Joy-Cons cannot reach the same level of precision as the Switch. Additionally, some games seem to use different ways to ask for rumble and are not supported yet. We are investigating this.

Soon, german77 has plans to add native Joy-Con pairing support. This will allow for real HD Rumble compatibility.

Video decoding, or how to suffer for so long with a single codec

It’s finally here! After such a long wait, and thanks to the work from ogniK and epicboy, yuzu can now play videos in-game! For now, only H.264 and VP9 videos are supported, which thankfully seems to cover all released games until now. Support for H.265 and VP8 will come later.

Your browser doesn't support mp4 video. :(

Video Killed the Radio Star (Mario Kart 8 Deluxe)

This is possible by using FFmpeg. For now, decoding happens in a single CPU thread, and support for multiple threads and GPU decoding is currently being worked on.

We have an entire article dedicated to showing how this feature came to be, how it works, its challenges, and current limitations in more detail here. Please take your time to read it: it also includes a list of games confirmed working and not-so-working yet.

An emulator inside an emulator

Super Mario 3D All-Stars is a special case in several aspects. For starters, the game is just a container for several other binary executables (known as Program NCAs), each one with their own Title ID. Step one to get this game to boot is to correctly handle these multi-content games, a job Morph did.

Good, finished, right? Wrong. Turns out, handling several integrated programs with different title IDs will make XCI game dumps conflict, as they include games and even firmware updates to account for users without internet access. Morph also had to add checks for cases like this.

Next step, unimplemented functions. Morph did a partial implementation of LoadOpenContext, a function that several collections games use. Some examples are Clubhouse Games: 51 Worldwide Classics, Grandia HD Collection, XCOM 2 Collection, Baldur's Gate I and II, Dr Kawashima's Brain Training, and of course Super Mario 3D All-Stars.

Similarly, GetPreviousProgramIndex needed to be stubbed. The result is getting the game-selector/menu working.

For now, just the menu and soundtrack sections! (Super Mario 3D All-Stars)

Vulkan changes

VK_KHR_timeline_semaphore is a relatively recent Vulkan extension only supported by desktop or laptop GPUs. In the past, resources were being assigned with VkFence and freed when arbitrarily asked, leading to a possible small pileup. With VK_KHR_timeline_semaphore, each resource is tied to a periodically checked “GPU tick,” and you only need to verify on which tick you are at the moment to know if that resource is now free.

Our implementation is not that complex. This is just an example provided by Khronos

Adding support for timeline semaphores in yuzu helps simplify the code a lot, improves VRAM use a small amount, and paves the way for the finalization of the Texture Cache rewrite. Thank you, Rodrigo, for its addition! The result should be transparent for the user with no perceptible change besides a bit of VRAM savings.

Bug fixes and improvements

A missing feature in the input rewrite was the ability to merge two separate single left and right Joy-Cons into a single dual Joy-Con, a function Super Mario Odyssey needs. Morph implemented MergeSingleJoyasDualJoy, so this is no longer a problem for Mario. He can return to work once again for nothing. Thirty-nine years and no rewards for the best hero the Mushroom Kingdom ever saw.

A small PSA for our Linux users, the required Qt version has been raised to 5.12.8 now. Thanks Morph for the update! We need those new Plasma functions.

Users have been reporting input latency, so Tobi decided to test some changes and see if the situation improves. To further mitigate this issue if you experience it, be sure to enable Radeon Anti-Lag or Nvidia Ultra-Low Latency in your respective driver control panel. Nothing makes you ragequit more than losing in Smash due to lag.

Gamecube controllers will now be autoconfigured! Thanks to work done by german77, Gamecube Adapter controllers will show up as devices in the input window, and their buttons will be mapped automatically. Laziness is the best.

Clubhouse Games: 51 Worldwide Classics now manages to boot and, with a save, load the board games. Morph managed this by implementing the Get/SetNpadHandheldActivationMode functions. However, the game will still render almost everything in black, so don’t consider it playable yet.

Paint it all black (Clubhouse Games: 51 Worldwide Classics)

If you ran a game in fullscreen and a pop-up needed to display (for example, naming a character), it used to render behind the main yuzu window, forcing you to exit fullscreen, focus the pop-up, complete the action, and then continue with your game. Quite annoying indeed. Morph is our savior for this one, by using the Qt::WindowStaysOnTopHint flag, the pop-ups will now display on top of your game. Thanks a lot, poyo.

GPU vendor specific fixes and changes

Recent Nvidia Geforce drivers (past the 446.14 version) introduced a performance regression mainly affecting Paper Mario: The Origami King and Super Smash Bros. Ultimate's menus, important enough that we had to recommend our users to stay on older driver versions until we could figure out what was going on. Turns out, the new drivers don’t seem to like how Qt handles VSync, so Rodrigo fixed it by calling SwapBuffers from the emulation thread. This change means that Nvidia users are free to use the latest driver version without fearing low framerates.

Your browser doesn't support mp4 video. :(

Just in time for Ampere, eh! Good luck getting one for now (Super Smash Bros. Ultimate)

As mentioned in July’s progress report, toastUnlimited continued to work on solving crashes only experienced with recent Nvidia Vulkan drivers in Linux. Thanks to work done by DXVK, toast’s current implementation aims to be global, and so far we haven’t got any report on getting the issue or any sort of regression. Please feel free to contact us if you are still affected by this issue.

Not a fix in yuzu’s code, but in fact a fix AMD implemented in their drivers. As mentioned in the previous August progress report, VK_EXT_extended_dynamic_state was giving problems on the AMD Vulkan Windows driver. This has been fixed in the latest 20.9.2 driver version, allowing yours truly to remove the previously needed blacklisting. No more nightmares when playing Super Mario Odyssey.

Future projects

Not much information can be given right now, but you all should know that Raptor is advancing at a very impressive speed. Our devs are so preoccupied with whether they can, they don’t stop to think if they should.

That’s all she wrote, folks! See you next time in the October progress report!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

New Feature Release - NVDEC emulation!

CaptV0rt3x — Tue, 29 Sep 2020 23:20:00 +0530

Hello, yuzu fans! Tired of broken cutscenes and having to mash your controller buttons in hopes of skipping them? Well, look no further! Thanks to the efforts of epicboy, yuzu can now play (most of) your favorite in-game cutscene videos. Jump right in to find out more!

NVDEC - What is it?

For a long time, one of the most noticeable missing features of yuzu was support for NVDEC.
What is NVDEC? NVDEC stands for Nvidia Video Decoder and is a feature in Nvidia GPUs that performs video decoding. And since the Switch has an Nvidia Tegra X1 SoC, it too makes use of its NVDEC module to offload all CPU intensive video decoding tasks to the GPU.

NVDEC supports video codecs like MPEG-2, VC-1, H.264 (AVC), H.265 (HEVC), VP8, and VP9, but Nintendo only exposes H.264, H.265, VP8 and VP9. Most games seem to use H.264 because of its wide support and efficiency ratio. But many first party games are known to use VP9 too - eg. Super Smash Bros. Ultimate, Pokémon: Let’s Go, Pikachu/Eevee!

With NVDEC support, users no longer have to rely on old save files or crazy button mashing to bypass broken cutscenes. Grab the latest yuzu Early Access build to try it out now!

Development

The Switch uses NVDEC along with VIC (Video Image Composer) in the GPU for video decoding. Games are exposed to higher level APIs by Nintendo which abstract the configuration of these modules.

NVDEC and VIC work together to decode incoming videos and the process usually goes like this:

- Allocate memory
- Place encoded video frame data in known memory location
- Decode and place frame data into GPU memory
- Clear intermediary allocated memory

Although this seems fairly simple, implementing it was quite the task. epicboy began working on this by implementing the service/command calls to NVDEC and VIC. It was decided to use the FFmpeg library to decode the frame data once we knew its codec (H.264 or VP9).

VP9

VP9 was the biggest challenge as its decoding required knowledge on the different attributes of a specific frame. Each frame carries two headers and raw frame data with it. The headers contain the information as to which previous frame the current frame refers to or depends on. Frames usually refer to previously decoded frames, along with transformations to be done on various parts of those, to compose new frames. This is done in an effort to reduce the memory footprint of each frame.

Here is where things got complicated. On the Switch, these headers are parsed by the Nvidia library in the games; therefore, NVDEC never receives this data. But for us to decode the frames using FFmpeg, we need to provide it with the full frame - Two headers and raw frame data from NVDEC. And since NVDEC hardware doesn’t expose all of the data of the two VP9 headers, epicboy had to manually compose these headers from the provided information.

epicboy took an interesting approach to this problem - he buffered two frames in advance. As the frame data from NVDEC holds some data on previous frames, knowing two frames in advance was useful. But this wasn’t sufficient as a few games resulted in issues with this approach. We are currently researching these edge cases to properly fix it for all games.

H.264

H.264 was relatively easier compared to VP9. Each H.264 frame contains two headers and raw frame data with it. Unlike VP9, H.264 doesn’t have different headers for each frame but has same headers for entire video.

ogniK had, long ago, already implemented H.264 support in his experimental branch. epicboy based his work off of ogniK’s and fixed a bug in it which caused distorted videos. It turned out that ogniK was using incorrect dimensions when writing the pixel location.

Currently NVDEC operations are synchronous, but are asynchronous compatible. This means that in the future, NVDEC operations can be made asynchronous thus yielding even better performance. Also, thanks to the FFmpeg library, we have access to hardware acceleration for faster decoding. And in the future, this will allow yuzu to offload video decoding to the host GPU (user’s GPU).

VP8 & H.265

The Switch officially supports VP8 and H.265 too, along with VP9 and H.264. However, we are yet to see games make use of these codecs for in-game videos and hence support for these codecs remains unimplemented for now.

Testing

As development work progressed, there were a lot of challenges and issues with games. Link’s Awakening, for example, wasn’t providing the proper memory locations to write frame data to and the NVDEC/VIC service/command calls were inaccurate as well. This led to data corruption when we wrote frame data to wrong memory locations.

epicboy and our testers spent tens of hours testing various games in yuzu to make sure any minor issues were ironed out. This rigorous testing also brought to our attention more games that exhibit weird edge cases. Over the next couple of weeks, we plan to fix these bugs and make our decoding even more accurate.

Huge shoutout to our testers for testing and compiling these lists.

Games that work

The following games were tested by our team and work well with minor occasional glitches:

1-2-Switch
AI: The Somnium Files
Animal Crossing: New Horizons
Attack on Titan 2
Atelier Ryza: Ever Darkness & the Secret Hideout
Bloodstained: Ritual of the Night
Bulletstorm
Children of Morta
Dark Souls Remastered
Deadly Premonition Origins
Devil May Cry
Devil May Cry 2
Devil May Cry 3
Disgaea 5 Complete
Donkey Kong Country: Tropical Freeze
Dragon’s Dogma
Dragon Quest Builders
Dragon Quest XI:S
Dragons: Dawn Of New Riders
Fairy Tail
Final Fantasy IX
Fire Emblem: Three Houses
Fire Emblem Warriors
Go Vacation
Hollow Knight
Huntdown
Hyrule Warriors: Definitive Edition
Indivisible
Just Dance 2020
Kirby Star Allies
LEGO City Undercover
Mario Kart 8 Deluxe
Marvel Ultimate Alliance
Monster Boy and the Cursed Kingdom
ŌKAMI HD
Paper Mario: The Origami King
Pokkén Tournament DX
Psyvariar Delta
Resident Evil
Resident Evil 0
Resident Evil 4
Resident Evil 5
Resident Evil 6
Resident Evil Revelations
Resident Evil Revelations 2
Ring Fit Adventure
Rune Factory 4 Special
Shantae and the Seven Sirens
Star Ocean First Departure R
Steins;Gate Elite
Super Mario 3D All-Stars
Super Mario Odyssey
Super Smash Bros. Ultimate
TLOZ - Breath of the Wild
Tokyo Mirage Sessions #FE Encore
Trials of Mana
Xenoblade Chronicles Definitive Edition
Yu-Gi-Oh: Legacy of the Duelist

Games with known issues

The following games are known to have issues, and we are actively working on fixing them:

Alien: Isolation
Ni no Kuni: Wrath of the White Witch
Onimusha: Warlords
Persona 5 Scramble
Resident Evil 0
TLOZ: Link’s Awakening
The Legend of Heroes: Trails of Cold Steel III
Final Fantasy VIII Remastered
Pokémon Let’s Go
Pokémon Sword

Fin

As always, we would like to remind users that the features released on Early Access are still being worked on. Hence not all games might behave in the way we want them to. If you come across more games (other than the ones mentioned above) that encounter bugs or issues, feel free to reach out to us on our Discord server and share your findings.

See you next time,
- yuzu development team!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report August 2020

flamboyant_ham — Sun, 30 Aug 2020 12:00:00 -0300

Yahallo yuz-ers! We hope you are doing well. This monthly report has a few critical topics to cover. Yet another major rewrite is done, some graphical bugs are fixed, the UI is further refined, and ghosts from our past are expelled. Here we go!

Project Mjölnir

Part 1 - Input Rewrite

Let’s start with the biggest change. One of yuzu’s weakest aspects was its input support. It was riddled with bugs, not very intuitive, and lacked several critical features. Earlier this year, jroweboy and Rei decided to start working on what would end up a complete rewrite of the input UI and its internal workings, dubbed Project Aphrodite.

Never gonna give you up

As you can see in the following images, the original draft lacked some of the features we have working right now and some that we plan to add in the future. No code is ever complete, better ideas and new implementations can always be achieved. So that’s exactly what happened, Rei continued to iterate on the concept design that is inspired by RPCS3’s controller UI.

The first draft, in all its glory

With this concept in mind, jroweboy implemented an automapping feature which correctly maps all the inputs upon selecting an input device.

Your browser doesn't support mp4 video. :(

Finally, no more spending hours mapping controls!

Since jroweboy’s departure from emulator development, Morph continued his legacy and picked up where he left off, not wanting to have all this work go to waste. With renewed hope, both Morph and Rei have taken the reins and are continuously refining the UI to achieve the best user experience possible. Their efforts have culminated in the UI we have today.

The fruits of our labor, the triforce of themes is complete!

The user experience would not be complete unless a long standing issue where updating controllers in the UI will not update them in game is fixed. Knowing this, Morph decided to find out what is causing this issue and fix it along with the UI changes. With some guidance from the shark ogniK, he discovered that 1. The frontend was not signalling to the backend when a controller changes configuration and 2. StyleSetChangedEvents were not being signalled on a controller change. By fixing these two issues, he managed to fix input issues in a wide array of games and allowed users to change their controller and input devices while in game without needing to restart yuzu.

Your browser doesn't support mp4 video. :(

Smash players rejoice!

The games that demonstrated the most benefit from these fixes are Pokemon Let's Go: Pikachu and Pokemon Let's Go: Eevee, as single joycons can now be properly detected in game, bringing us one step closer to hardware accuracy.

Professor Oak! Input is now in working order!

Part 2 - Controller Applet

Morph began on Part 2 knowing that yuzu lacked an implementation of a Controller Applet, which is crucial for a lot of multiplayer games such as Super Mario Maker 2, Kirby Star Allies, Hyrule Warriors: Definitive Edition and many more. It had previously been attempted by DarkLordZach but was riddled with issues due to the immature input implementation at the time. Therefore, Morph decided that it was time to implement it after gaining knowledge of and fixing HID in Part 1.

While Morph was completing the backend implementation of the applet, Rei was designing the UI that was inspired by DarkLordZach’s initial implementation, with an error box showing all the issues with the current controller configuration as shown.

The very first concept of the Controller Applet inspired by DarkLordZach's initial implementation

After taking a look at this first concept, they decided that it wasn’t very intuitive for the user. One morning, as Morph was about to finish the backend implementation, Rei had an epiphany to replicate the Switch’s native UI for the Controller Applet and whipped up the concept design you see below:

The one that started it all

As you can see, this was much closer to the design we have now, but was lacking some features such as the number of supported controllers, LED pattern, border color, and explain text. Wanting to get as close to the Switch’s design as possible, Morph implemented these features one by one, and the frontend UI was adapted by Rei to include these features, bringing us to the final design we have now.

It's all coming together now

As the design was now complete, Morph hooked up all of these features from the backend to the frontend and produced these clean and pretty results!

Below are comparisons between the Nintendo Switch’s and yuzu’s Controller Applets:

Mario Kart 8 Deluxe

Kirby Star Allies

Super Mario Maker 2

There is still more to come!

There is always room for improvement, keep your eyes peeled for future additions and features!

As we cannot fit in all the changes present in both parts, our more tech savvy users can read about all the changes in the following PRs: [Mjölnir Part 1], [Mjölnir Part 2].

Bugfixes and improvements

Khronos recently added the new VK_EXT_extended_dynamic_state extension to the Vulkan API, and driver support is slowly being completed by the vendors. Per the norm with newly supported extensions, you can expect stuff to be in a non-perfect state, or as we like to say, “Expect Dragons.” AMD recently added support for this extension in the 20.8.3 Windows driver, but part of it is glitched, resulting in graphical errors in games like Super Mario Odyssey. Rodrigo temporarily solved this by blacklisting the extension on the AMD Windows drivers until it is fixed. Intel doesn’t support VK_EXT_extended_dynamic_state at the time of writing this, and Nvidia had already fixed their issues with the extension.

Mario stared into the abyss, and the abyss stared back (Super Mario Odyssey)

Continuing with VK_EXT_extended_dynamic_state, a glitch affecting Super Smash Bros. Ultimate, and others, was discovered when using this new extension. Attack sprites were missing during gameplay, but Rodrigo was able to solve the issue on all compatible drivers.

Your browser doesn't support mp4 video. :(

The Master Sword can't just look like a regular sword (Super Smash Bros. Ultimate)

Thumbnail pictures in in-game save slots were a black rectangle for most games up until now. By fixing block linear copies, Rodrigo prevented users from loading up the wrong save or course by mistake in games such as The Legend of Zelda: Breath of the Wild and Super Mario Maker 2.

Ohh, this one was my good course! (Super Mario Maker 2)

Precision has a cost

Up until now, CPUs lacking the FMA instruction set had to run generic code as fallback. After a lot of work, Merry added optimizations intended for CPUs lacking the FMA instruction set.

This means that users with CPUs from the AMD Phenom II series or older, Intel 3rd generation Core-i series or older, and all Pentium, Celeron and Atom CPUs can now select the “Unsafe” setting and see major performance improvements in almost all games. Don’t bother to try this setting on CPUs that have FMA, as it will not improve your performance in that case.

However, due to being a less precise alternative, expect emulation inaccuracies if you decide to enable it. Here be dragons, as they say.

You can find it here

UI Changes

As part of the input rewrite, Rei fixed several consistency bugs affecting the Midnight Blue UI theme. You can see the results below.

Input window fixes, before (left) and after (right)

Gamelist fixes, before (left) and after (right)

Both of our dark themes (Dark and Midnight Blue) had a transparency bug affecting the per-game settings pop-up window. toastUnlimited made the necessary changes to fix this by setting QLabel background color to transparent. You can see the changes below.

Dark theme, before (left) and after (right)

Midnight Blue theme, before (left) and after (right)

toastUnlimited also added an option to access game specific settings while playing. This makes it easy to change graphics accuracy or other settings on the fly.

Found it!

Force 30FPS was an option that was used for debugging, and as an emergency brake for the old days when yuzu lacked a proper frame limiter. The fate of this tick-box was undecided for long, moving it to the Debug tab was considered at one point. But in the end, it was finally removed by Morph. This option was no longer functional after the changes of Project Prometheus took effect, so this was a necessary sacrifice.

Our users reported that some checkboxes were duplicated after the addition of Vulkan. These were Dump Decompressed NRO and Dump ExeFS which could be found both in General > Debug and System > Filesystem > Patch Manager. Tobi put an end to this clone war, removing the duplicates in Debug.

Future Projects

epicboy is working on a universal, GPGPU (General-Purpose GPU) accelerated method to decode ASTC textures. We shall hear more of this after the Texture Cache rewrite is finished.

Whispers of more audio changes have been heard, and a certain shark will be responsible for this.

Devs uh… find a way.

That’s all for now folks! See you again in the September progress report!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report July 2020

Morph — Tue, 04 Aug 2020 12:00:00 -0300

Hey yuz-ers, what is up and welcome back to the… progress report. In this monthly report, we offer you major rewrites to critical components, another successful attack on shader compilation times, tons of game fixes, and the promise of a very bright future ahead. Let’s get started!

Paper Mario: The Origami King fixes

To begin with, Rodrigo implemented several fixes to make Paper Mario: The Origami King playable:

By clamping the host’s compute shared memory limit, the game doesn’t get stuck when trying to start rendering.

Now in A4 format! (Paper Mario: The Origami King)

Some graphical artifacts affecting OpenGL can be fixed in GLASM by executing the shader instruction BAR inside control flow.

That is one big sheet of paper! (Paper Mario: The Origami King)

Lighting issues were fixed by implementing the S2R.LaneId instruction in the shader decoder.

Lights, please! (Paper Mario: The Origami King)

New GPU Virtual Memory Manager

bunnei brings the big guns. The complete rewrite of the GPU Virtual Memory Manager fixes several bugs in many games, with the two strongest examples being Mario Kart 8 Deluxe and Super Smash Bros. Ultimate. Now several graphical bugs are fixed in Mario Kart 8, including tracks that show invisible terrain or missing graphics. In Smash’s case, there are no more vertex explosions now.

This rewrite also should reduce committed memory a bit, hopefully reducing the size of the required page file, and opens the possibility to implement new features in the future. We have to clarify that this doesn’t fix the high VRAM usage in Vulkan.

That's not what I meant when I said Anti-Gravity! (Mario Kart 8 Deluxe)

Bug fixes and improvements

Accompanying the recent addition of 32-bit emulation support, bunnei implemented support for the creation of random and default Miis. This does not include full support for custom ones for now. With Miis in place, games like Mario Kart 8 Deluxe and New Super Mario Bros. U Deluxe can now get past their menus and become playable.

For this service to work, the user needs to dump the system archives from their Nintendo Switch. The process requires the Goldleaf homebrew.

To obtain the files, you must open Goldleaf from the Homebrew menu, select “Console and Goldleaf settings,” select “Firmware and updates,” pick “Export update,” confirm on the “Directory” option, and the files will be dumped in the switch\Goldleaf\dump\update location. After that, just copy the files to %AppData%\yuzu\nand\system\Contents\registered.

Ports, ports everywhere! (Mario Kart 8 Deluxe & New Super Mario Bros. U Deluxe)

This is tradition by now. Morph fixed another bug in Kirby Star Allies, this time by implementing MirrorOnceClampOGL. This is done by using the GL_EXT_texture_mirror_clamp extension on the OpenGL drivers that support it. The Intel driver doesn’t, so, with those GPUs, yuzu falls back to GL_MIRROR_CLAMP_TO_EDGE.

Improvements to the texture cache by implementing additional checks, done by Rodrigo, fixed crashing issues on Turing GPUs (RTX 2000 and GTX 1600 series) in The Legend of Zelda: Breath of the Wild. Now you can load saves normally! So get moving and save the princess!

Our GLASM users experienced black textures on top of the vegetation in The Legend of Zelda: Link’s Awakening. By using the extensions NV_shader_buffer_load and NV_shader_buffer_store, Rodrigo solved this issue for good.

Beware of the dark weeds, legend says rupoors lay there (The Legend of Zelda: Link's Awakening)

We talked about this in the previous June progress report, and we’re happy to announce that Rodrigo finished implementing support for VK_EXT_extended_dynamic_state. This fixes the “triangle glitch” that affects Super Mario Odyssey on all Vulkan drivers that support this new extension.

Thanks to help from gdkchan and Blinkhawk, Rodrigo added support for copying 2D arrays of pixels into 3D voxels, fixing rendering bugs in games like LEGO Marvel Super Heroes 2 and possibly others.

toastUnlimited, along with Rodrigo, started preliminary work to fix crashes only happening in recent Nvidia Linux Vulkan drivers. Through trial and error, it was found that increasing the Vulkan device allocable size mitigates this issue on most GPUs, but some still remain affected for now.

epicboy is working on implementing support for GameCube adapters, allowing players to use original GameCube controllers! Veteran Smash players will surely enjoy it.

Project Prometheus introduced so many changes that we are still working on reaching feature parity with the original single-core implementation. ogniK improved the audio timing, fixing audio bugs that were introduced with the implementation of the new multicore and single-core emulation methods.

Since its introduction, enabling multicore was the only way to reach stable gameplay on Linux systems, as the single-core option would lead to a crash in every game. Thanks to comex’s report, Lioncache fixed it by using the return value of Lock() in the nvflinger surface compositor. Thanks to this fix, games that are not yet stable with multicore, like Luigi’s Mansion 3, can now be safely played in the Tux OS (Linux).

Project Kobra

Six months ago, Morph proposed an implementation of a batch installer to yuzu, which allowed users to install many updates and DLCs at the same time. This was a boon for many users, but it remained in Early Access for a long time due to several issues and anticipation of a new VFS implementation dubbed Project Viper. With renewed hope and motivation from the shark (ogniK), Morph went on to fix all of its remaining issues, allowing it to finally be merged into the master/Mainline branch of yuzu.

I can finally install all the DLCs of Super Smash Bros. Ultimate!

Additionally, as Project Viper has been delayed until further notice, Morph took it upon himself to fix the list of Virtual File System (VFS) bugs that had been plaguing yuzu.

It was well known that yuzu had problems with installing Updates and DLC into the NAND and reading them correctly. Due to the inability to easily remove individual game files, users had to delete all their installed game files just to ensure that their new Update or DLC got detected properly.

Not again, my precious write cycles! *sobs*

Upon closer inspection of the inner workings of the VFS, Morph found that the previous Updates or DLC were not removed when a newer one was being installed, leading to issues with the detection of these files in yuzu. He solved this by properly removing the previous update or DLC if it exists on installation. In addition to this, he also corrected a small oversight in the way yuzu stores autogenerated titlekeys. Now invalid titlekeys will no longer be written into the title.keys_autogenerated file, ensuring that only valid ones are written. If your game, update or DLC is not being detected by yuzu, ensure you have the latest key files dumped from your switch, as newer game updates and DLC require newer firmware keys to decrypt. With these fixes in place, yuz-ers no longer have to delete all installed game files to install a newer update or DLC as this properly overwrites the previously installed ones.

Next, he looked into fixing one of the oldest and well known VFS bugs - the Luigi's Mansion 3 autosave issue. Every time an autosave was triggered, the game would softlock. This had also affected other games such as KATANA KAMI: A Way of the Samurai Story and Okami HD. Building upon the initial research by theboy181 (the creator of the mod that bypassed the Luigi’s Mansion saving issue), Morph dug into the VFS code and found that files were not closed prior to being renamed or moved, leading to a simple fix for any games that use this function.

Keeping the ball rolling, he went on to find out why Diablo III: Eternal Collection was not able to get past the EULA screen and thus needing a save file to bypass it. It turned out that an old PR was causing folders instead of files to be created. After this discovery, the PR was immediately removed from Mainline/Early Access and closed as it was no longer needed.

EULAs can't stop me! (Diablo III)

Looking for the next meal, Morph took a bite at the saving issues of the Bioshock Trilogy. These games were unable to save due to checking for free space prior to saving. This was fixed by ensuring that the NAND partition sizes were set to their defaults and are read correctly by the relevant filesystem service commands.

Game saves are for the weak! (Bioshock Remastered)

After this little treat, the Kirby embarked on an adventure to fix the last remaining issues with the VFS. After 3 days of debugging the Pokemon Sword and Shield RomFS weather bug, he discovered that these games contained a 0 byte file called global_setting.bin which caused the file right after it called weather_data.bin to be skipped entirely. And you may have guessed by now - this file contains all the data for weather and without it, no weather can be generated within the game! This eureka moment led to an extremely simple fix which accommodates for 0 byte files during RomFS building.

Let it snow, let it snow, let it snow! (Pokemon Sword and Shield)

Morph’s adventures have led him to save ~~Zelda~~ Link from the eternal softlocks after awakening from his slumber, seems like Ganon may have known Zelda’s plan after all. Our Kirby traveled to the shattered Kingdom of Hyrule and foiled Ganon’s plans by creating the save subdirectories that would allow Link to save his progress. Finally, he can save the princess without wasting his time eternally stuck after his slumber.

Hearing stories of Nook Inc’s deserted islands, Kirby flew off to visit some of them, only to be met by a barrier preventing access to the other realms. He managed to bypass the barrier by stubbing two filesystem service commands which were blocking access to the islands. Now he can view all the latest treats added in the islands since the last update.

Wrapping up his adventures, he went and brought peace to Dreamland once again by adding an option to remove individual NAND or SDMC installed games, updates, and DLCs and fixing the last remaining issues with the game list, such as opening the Save/Mod Data Location of installed titles, game list subdirectory scanning, and game list metadata detection.

Removal of installed game files has never been easier!

The old guard

When yuzu started using Conan, most of yuzu’s dependencies were migrated to it. Unfortunately, our audio decoding dependency, Opus, had bad settings in the Conan version. These settings forced the use of the AVX/AVX2 instruction set even on old CPUs that don’t support it, such as AMD Phenom CPUs or any Intel Pentium, Celeron, or Atom CPU. This caused some games to crash when processing audio on the affected CPUs. ogniK fixed this by replacing our included Opus version.

Merry finished the preliminary work needed to fix a performance regression affecting CPUs that lack the FMA instruction set. This includes AMD Phenom series or older, Intel 3rd generation Core-i series or older, and all Pentium, Celeron and Atom CPUs. For now this shows up as a debug CPU configuration in yuzu’s settings. We recommend that our users not play with these settings, as altering them will only produce a worse experience than the default settings.

UI changes

A very requested feature from our users. toastUnlimited rose to the challenge and decided to add per-game configurations to yuzu! For now it lacks support for input settings, but this will be added in the future. To access this new feature, right click a game in yuzu’s game list and select Properties.

No need to remember specific settings before booting a game!

Morph added a new theme for our anti-light themes users, Midnight Blue! You can access it in Configuration > General > UI.

Oooh, Spooky

Fixing small annoyances is something that is overlooked most of the time, but very appreciated when done. Tobi removed the need to confirm which Switch profile to use when there is only a single one created. Thank you so much Tobi.

Bye little fella!

The Sharkman, episode one

ogniK has been working for a long time on a major audio rewrite for yuzu. To avoid a very long explanation of the complexity of Nintendo’s audio renderer systems, we recommend our more tech savvy readers to read the Pull Request’s description where you will find more detailed information.

This is “Part 1,” several fixes and more complex (or annoying to code) features will be finished at a later date. Right now the results speak for themselves. Tons of games with broken audio of any kind - like missing sound effects, fading music, mixing errors, crackling or even no sound at all - are either running perfectly or are starting to sound a lot more like the native hardware. Some bugs are to be expected for now, for example, Shovel Knight and Fast RMX experience choppy audio, and the voices in Animal Crossing: New Horizons will play from only one ear.

You would think that this is enough, but ogniK has another fantastic gift for us. Up until now, when several new shaders had to be built during gameplay, they could only be done one at a time. Thanks to some good help provided by Exzap, Cemu’s lead developer, yuzu can now decode shaders asynchronously! This means that, depending on the amount of threads your CPU has, the shader compilation will happen on several threads at the same time. Thus cutting down shader build time significantly, especially if you can also use assembly shaders.

To top it off, epicboy added async shader support for Vulkan!

Your browser doesn't support mp4 video. :(

Thanks to BSoD Gaming for the video comparison (Super Smash Bros. Ultimate)

Due to limitations in the AMD Windows OpenGL driver, we recommend that you avoid using asynchronous shaders in OpenGL if you have a Radeon GPU, as it will only produce frame skipping and lead to a very poor gameplay experience. The Linux OpenGL drivers are unaffected by this, as well as any of the Vulkan drivers.

The number of threads used for asynchronous shader compilation (along with example CPUs to illustrate the number of CPU threads) are as follows:

CPU Threads	Shader Threads	Example CPUs
1 - 7	1	R3-1200, i3-6100
8 - 11	2	R3-3300X, i7-7700K
12 - 15	3	R5-3600, i7-8700K
16+	4	R7-3700X, i7-10700K

Future projects

Rodrigo started rewriting the Texture Cache and once the work is finished, this should positively affect both OpenGL and Vulkan by introducing bug fixes, better performance, and a better experience in Vulkan in particular.

There are also some other yet undisclosed but very impressive projects that we will reveal soon enough. Stay tuned!

That’s all for now, folks! Until the August progress report!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report June 2020

GoldenX86 — Wed, 01 Jul 2020 12:00:00 -0300

Hello fellow yuz-ers! We hope you are doing well. Once again, we’re here to tell you about some of the exciting changes that were implemented last month in both yuzu Mainline and Early Access.

In this episode, we have lots of fixes and optimizations, a feature many have been requesting, and as always, some hints of what the future will bring.

Bug fixes and improvements

How should we start? Oh, I know! With Morph fixing another Kirby issue of course! By reserving 4 image bindings in the fragment stage, instead of just one as before, he was able to fix several shader compilation errors that affected both GLSL and GLASM in Kirby Star Allies. Check out the results below, Poyo!

Here you can see the bug affecting an attack (Kirby Star Allies)

And here affecting terrain (Kirby Star Allies)

Rodrigo fixed a bug that previously manifested as random black flickering by marking vertex buffers as dirty after a cache invalidation. This issue primarily affected Animal Crossing: New Horizons, but the bugfix should affect a lot of other games as well. Feel free to share any other games you discover that benefit from this!

Your browser doesn't support mp4 video. :(

Now that doesn't look nice, does it? (Animal Crossing: New Horizons)

A very elusive bug in Super Mario Odyssey, dubbed the “triangle glitch,” had been tormenting us for ages. Rodrigo managed to solve the issue, but only in OpenGL with Nvidia GPUs due to the exclusive NV_vertex_buffer_unified_memory extension. However, due to both a yuzu and driver bug, we’re unable to use this extension on Turing based GPUs (RTX 2000 and GTX 1600 series) for the moment.

Dark and glitchy (Super Mario Odyssey)

We are working on a universal implementation in Vulkan that requires the VK_EXT_extended_dynamic_state extension, but it is not yet available in all the GPU vendors’ drivers. At the time of writing, only the Intel Mesa ANV Linux driver and the latest Nvidia Vulkan Beta driver support it.

A rare bug was affecting Xenoblade Chronicles 2, causing fantastic vertex explosions on time-of-day transitions. Rodrigo managed to solve the issue by improving the shader cache.

Exactly the same spot (Xenoblade Chronicles 2)

By implementing RendererInfo into yuzu’s audio emulation, ogniK solved the softlocks affecting the credit sequence in Animal Crossing: New Horizons and the softlocks in several areas of The Legend of Zelda: Link's Awakening. Now you can enjoy both games without the fear of getting stuck, and even listen to some newly working sound effects!

Nothing to report! (Animal Crossing: New Horizons & The Legend of Zelda: Link's Awakening)

Also thanks to ogniK, Animal Crossing: New Horizons no longer needs the crash-fix patch we were distributing in our compatibility article for the game. This was done by improving the emulation of the Tegra X1 GPU drivers. As a bonus, this also fixed T-posing on the later updates in Super Smash Bros. Ultimate!

Not all games are native to the Nintendo Switch, with a portion of its library consisting of ported games from other consoles or the PC. Up until now, yuzu failed to run PC game ports that were originally developed for Direct3D (a Windows graphics API), even though they ran perfectly fine in NVN (a Switch exclusive graphics API). However, Rodrigo found a way to translate this behavior to yuzu’s OpenGL and Vulkan implementations, resulting in tons of western games going in-game. This change was also accompanied by a shader cache invalidation.

Would you kindly? (BioShock Remastered)

By implementing a missing texture format, Rodrigo fixed dark surface glitches that appear in Xenoblade Chronicles Definitive Edition.

This is the Monado's power!

(Xenoblade Chronicles Definitive Edition)

Intel used to have a bug in their OpenGL driver causing many games using Compute Shaders to crash or render effects incorrectly. This forced us to disable them on any supported Intel GPU, which introduced adverse effects in many games. One game of note is Super Smash Bros. Ultimate, wherein compute shaders are used to render character model animations and without them, character models will be in a T-pose.

Additionally, Intel’s OpenGL Geometry Shader implementation (unlike AMD’s and Nvidia’s one) lacks an OpenGL extension called GL_ARB_shader_viewport_layer_array. This forces us to re-evaluate yuzu’s implementation of it.

By re-enabling Compute Shaders and changing the way yuzu handles Geometry Shaders, Morph closed a big box of issues that previously affected only our Intel GPU users.

Gone are the rainbows on Intel (Octopath Traveler)

No more T-posing (Super Smash Bros. Ultimate)

Volca stubbed an input instruction allowing Minecraft: Nintendo Switch Edition to go in-game.

Don't dig too deep! (Minecraft: Nintendo Switch Edition)

Not all games have to be in 3D. Morph replaced the default texture filtering behaviour to achieve crisp graphics in 2D games like Undertale.

Crisp, just the way I like it

Now on to our final bug fix of last month. Old AMD GPUs from 2012 lack the OpenGL GL_EXT_texture_shadow_lod extension, leading to shaders that failed to build in The Legend of Zelda: Breath of the Wild. As described here, by using the textureGrad function, Morph achieved similar results, improving compatibility with such old devices.

Vulkan improvements

OCTOPATH TRAVELER got some Vulkan love thanks to Rodrigo. By implementing a missing image format and storage texels and atomic image operations, the game can now reach in-game status in Vulkan, and with some very beautiful visuals!

This is how nostalgia makes us remember the SNES era (OCTOPATH TRAVELER)

Rodrigo also worked on multiple performance optimizations for the Vulkan API. This results in lower frametimes and higher framerates on average.

User Interface changes

An old misconception our users had with yuzu had to do with the Internal Resolution option in the graphics settings. This was carried over from Citra’s UI, but it wasn’t coded to do anything in yuzu. So, lots of users set it up at higher values expecting an image quality increase that could never happen. Morph decided it was time to remove it for good, and so he did.

Until we meet again, Internal Resolution!

Thanks to users requesting it, Volca added Open Mods, FAQ, and Quickstart shortcuts to yuzu’s interface. This is a great way for users to find helpful information on how to use the emulator — you just need to click on Help!

Just an easier way. Thanks Volca!

Continuing with UI changes, Kewlan added a mute audio hotkey. They also fixed a bug with the fullscreen hotkey, where the default hotkey would still function even when changed.

Dreams and reality

Project Maribel Hearn has been released, and is available in Mainline too! Native 32-bit Switch games are now starting to work, with some of them even being fully playable! This means that games like New Super Mario Bros. U Deluxe and Captain Toad: Treasure Tracker work almost perfectly and with great performance, while games like Mario Kart 8 Deluxe still need more work.

This has been a highly requested feature for a very long time, but implementing it required a major rewrite of the kernel, and official support for ARMv7 was needed in Dynarmic, our ARM JIT recompiler. This took a tremendous amount of work from several of our developers, including, but not limited to: Merry, Lioncache, Blinkhawk, bunnei, Rodrigo, Tobi, ogniK, Morph, and many others. Special mention goes to Merry and Lioncache: they are the soul of this project, and without them we couldn’t have even started it. Several of their pull requests are “too technical” to be included in the progress reports, but it should be known that Merry and Lioncache are the main code contributors at the heart of yuzu.

You may not have noticed that four months ago, bunnei and Tobi laid down the initial framework towards 32-bit support in yuzu.

They accomplished this by refactoring the ARM interface to support 32-bit and 64-bit JIT backends, implementing a 32-bit ARM interface based on Citra’s ARMv6 dynarmic backend by adding CP15 coprocessor support, and implementing several 32-bit SVCs such as GetThreadPriority32, WaitSynchronization32, and many more.

While rewriting the kernel for Prometheus, Blinkhawk and bunnei saw an excellent opportunity to include support for 32-bit ARMv7 CPU instructions and services. With this spark of motivation, they worked with Merry and Lioncache to make the dream of 32-bit support a reality, by ramping up the implementation of various ARMv7 instructions such as VPADD, VCVT, and VSHL in Dynarmic, and 32-bit SVCs such as CreateTransferMemory32, MapSharedMemory32, and CreateThread32 in yuzu. There are many other ARMv7 instructions and SVCs that we cannot cover here, but the culmination of this work allowed us to get the very first 32-bit games up and running!

Good performance even on low-end hardware!

Additionally, the merge of this work into the Master branch also means that Multicore support is now working in Mainline! Thanks Blinkhawk for all your hard work on this! Please refer to our previous May progress report and the dedicated Project Prometheus article to read more about this crucial new feature.

Future projects

With Multicore finally in Master, some of the ideas we have “in the oven” can start to take shape. Project Apollo is starting to be nice and sound. And finally, I’ve heard bunnei is up to something, again.

That’s all for now, folks! We hope to see you in our July progress report! Special thanks to gidoly for providing screenshots.

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report May 2020

GoldenX86 — Sun, 07 Jun 2020 03:15:00 -0300

Hello yuz-ers! How are you all doing?

In this monthly episode of “yuzu — Trials and Tribulations,” we offer you: major rewrites, massive performance gains, stability improvements, bug fixes and graphical corrections. More after the commercial break.

The worst kept secret

It has its own article, and it had been guessed to hell and back before the official announcement. Project Prometheus is a proper multithreaded emulation of the 4 CPU cores the Nintendo Switch offers. This brings a massive performance boost to users with CPUs with 4 physical cores or more, but for this to happen, a lot of groundwork was needed. Besides changes previously discussed in past reports, old external libraries (which yuzu needs to operate) needed to be updated, and with that, some changes were needed for our Linux users.

Thanks to jroweboy’s work, yuzu now uses Conan, helping the project manage dependencies, and letting Linux distributions use their native ones when possible.

With the previous VMM rewrite reducing memory use, the dependencies updated, and all the groundwork done, Blinkhawk pressed the metaphorical nuclear launch button and released Project Prometheus. yuzu can now use up to 6 or 7 CPU threads (in ideal conditions) compared to the previous 2 or 3. You should expect a performance boost in a lot of games, but still see some titles perform mostly the same due to being coded to only use a single thread.

Now, some clarifications are needed for this change. Multicore support can’t be merged into our Mainline release for now due to incompatibilities between Multicore and the Master branch of yuzu. Work is being done to resolve the conflicts, but please have patience. Additionally, users with 2 cores, and either 2 or 4 threads, should not enable multicore as it will most likely result in a performance loss for them due to the lack of physical cores on their CPUs. Our hardware recommendations have been updated accordingly.

Unreal Engine fixes

Rodrigo implemented rendering more than one slice of 3D textures, fixing the most glaring issue in Unreal Engine 4 games, known as “the Rainbow”. This also improves the previous implementation that was used in Xenoblade games.

Your Excellency (OCTOPATH TRAVELER)

Animal Crossing: New Horizons changes

Rodrigo fixed Animal Crossing: New Horizons terrain borders in Vulkan by implementing constant attributes. This is not a native extension, constant attributes have to be emulated in Vulkan as there is currently no official support for it.

Beautiful beaches, now in Vulkan too (Animal Crossing: New Horizons)

bunnei implemented time zone support, and Windows users will find that yuzu automatically detects their time zone. For those not on Windows (or want to spice up their life), you can manually change your system time via the “Custom RTC” option in the System settings. Previously, yuzu always assumed the user was located in the GMT+0 time zone.

bunnei also improved the saving mechanism. Most games save their data in each user profile, but Animal Crossing: New Horizons does it via a “device” profile, so yuzu had to accommodate for that.

Xenoblade specific fixes

Rendering bugs are abundant in Xenoblade games due to the complexity of their engine, and they are not trivial to solve. However, with the help of gdkchan and using this Pull Request from Ryujinx, Rodrigo fixed one of the major rendering issues in Xenoblade Chronicles 2 related to front face flipping. Additional improvements to texture depth samplings resolved some rendering glitches, such as the clouds and start menu. Additionally, a better handling of mipmap overlaps solved the constantly moving textures the games previously had. You can see the results below.

Who said yuzu can’t run JRPGs? (Xenoblade Chronicles 2)

Rodrigo also optimized the performance in Xenoblade games, one method of which was profiling the texture cache line by line and finding where it bottlenecks. By improving the code, you get a faster frametime, which translates to better performance.

Another way, and not an expected one, was to log less information. This avoids saturating the GPU thread, giving more room to actual processing and rendering.

General performance improvements

ogniK wrote a new Macro JIT (Just-in-Time) to improve the performance of games that spend too much time in the macro interpreter. This should be a global performance boost independent of GPU vendor or API.

When Rodrigo improved yuzu’s ASTC decoding, he also added a rule to use native hardware decoding whenever possible. The Nvidia driver tells yuzu it supports ASTC decoding, but as it turns out, they actually use an internal software decoder that is much slower than our own implementation. Ignoring the Nvidia driver-level software decoder produced a massive performance improvement when facing the dreaded ASTC texture format in games. It will still be immediate with Intel GPUs, as no software optimizations will beat a dedicated hardware decoder.

Bug fixes and improvements

Vulkan development is an ongoing process in yuzu, and it has stability problems as expected of a relatively new and complex feature. Blinkhawk made a couple of critical changes to Vulkan and Asynchronous GPU, improving stability considerably.

Speaking of Vulkan, many 2D games had their sprites flipped or completely wrong, and once again, we currently lack the extension required to fix this. Therefore, Rodrigo implemented support for NV_viewport_swizzle. This Nvidia-exclusive extension is the only way to solve this problem in a clean manner for now, but a universal method is being developed.

Quack (Duck Game)

The updated libraries (that the migration to Conan brought us) also gave us a new version of the cubeb audio engine which adds support for 6 channel audio, allowing ogniK to add support for surround sound.

Our good shark, ogniK, also fixed keyboard emulation support, so expect compatible games to have proper direct input from your keyboards now.

Morph implemented the missing support for R8G8UI textures, fixing both the performance problems and saving crashes that The Walking Dead games experienced.

Thank you Toxa for the screenshot (The Walking Dead: The Final Season)

Although objectively a small issue, the mouse cursor didn’t hide when running yuzu in full screen, causing a subjectively significant annoyance. Thankfully, Tobi implemented an option to automatically hide the mouse once it has been inactive after some time.

An elegant feature of a more civilized age

Recently released in the Early Access build, and coming soon to Mainline, is support for assembly shaders (GLASM), usually referred to as ARB shaders.

A couple decades ago, there was no common language for the then newly added programmable shading units in GPUs, so the OpenGL Architecture Review Board decided to create a proper standardised shading language they called GLASM. In broader terms, this is an assembly language used to communicate with the GPU. This makes it very difficult to work with, and the difficulty is only exacerbated by the limited set of debugging tools available. Furthermore, the language was developed with the hardware limitations of the time in mind. In the present, GLASM has been mostly deprecated in favour of easier-to-work-with, high-level shader representations like GLSL or SPIR-V. While this means faster results for game developers due to less time spent looking at the code, it also has the disadvantage of being far slower for emulators that have to constantly intercept, decode, and recompile shaders on the fly.

In the beginning, support for GLASM started as just an experiment. Armed with apitrace as his only debug tool, Rodrigo set to his task. Luckily, and for no apparent sane reason, Nvidia still maintains support for such an old feature, even on the latest OpenGL versions. As such, support for GLASM soon became a reality and with this initial assembly shading support in place, Nvidia OpenGL users can enjoy extremely fast shader compilation times.

Due to being closer to the native hardware of the Nintendo Switch, we can also expect some precision fixes, with more coming in the future.

Unfortunately, GLASM has some limitations. To list some of them:

This is an Nvidia and OpenGL only feature — other vendors (AMD and Intel) only offer support for the specific assembly shaders that old games require and this is highly unlikely to change in the future.
Currently, some games experience bugs that will need to be ironed out, such as: Luigi’s Mansion 3, Astral Chain, and The Legend of Zelda: Link’s Awakening.
There are architecture specific bugs; a Pascal GPU may face different issues than a Turing or Kepler GPU.

You can see the progress from simple things… (Cave Story)

To more complex tests (Fire Emblem Warriors)

Future projects

I can’t say much here, but there is something going on with both Project Viper and Project Hearn.

That’s all for now, folks! See you in the June article! Special thanks to BSoD Gaming for the comparative GLASM video, and Toxa for providing some screenshots.

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report April 2020

GoldenX86 — Thu, 28 May 2020 12:00:00 -0300

Hello awesome yuz-ers! We hope you are all doing well. We have lots of material to cover in this April progress report: some new additions, bug and regression fixes, and the groundwork for future improvements that affect both Mainline and Early Access. But first, let’s discuss a few really big changes.

The Big Changes

This month brought us huge improvements to compatibility, fidelity and resource management. Our master of serendipity, bunnei, fixed a softlock in FINAL FANTASY VIII Remastered. What he didn’t know at the time is that this small fix also made Super Smash Bros. Ultimate playable. Thanks to this, you can now enjoy local multiplayer battles with your friends, either locally or even via Parsec!

For quite a while, Nvidia Turing users (GTX 16 series and RTX 20 series GPUs) had to deal with several rendering bugs, like black and white terrain in Fire Emblem: Three Houses, or black areas in Super Monkey Ball: Banana Blitz HD. Rodrigo fixed most of them by improving the accuracy of the shader decoder. This also fixes some bugs on older Nvidia GPUs too.

Monochrome no more (Fire Emblem: Three Houses)

No greasy black peels (Super Monkey Ball: Banana Blitz HD)

Speaking of shader decoding accuracy, Rodrigo improved the precision of the HADD2 and HMUL2 instructions, fixing some long standing bugs like the fog in Fire Emblem: Three Houses and the excessive brightness in most maps in Super Smash Bros. Ultimate.

You can now take off your sunglasses (Super Smash Bros. Ultimate)

From steampunk, to the proper medieval fantasy setting (Fire Emblem: Three Houses)

We talked about this in its own article, but it deserves a mention here: bunnei rewrote the Virtual Memory Manager (known internally as Project Epimetheus), which drastically reduced the amount of RAM games use, and helped Multicore support (also known asProject Prometheus) become a reality.

One of the features in yuzu, and a common one in other emulators, is the ability to separate the rendering thread from the main emulation thread. This makes better use of the CPU’s resources, while also helping deliver better performance. That is exactly what Asynchronous GPU does in yuzu. Thanks to Blinkhawk, our Emulated GPU improved drastically, achieving better performance, stability, and accuracy. These changes introduce the option to adjust the GPU accuracy level while playing.

Performance may be reduced with more accurate levels

Your browser doesn't support mp4 video. :(

Normal accuracy (left) and High accuracy (right) (Super Mario Odyssey)

One Line to Fix ’em All

Toki Tori had sound problems that were related to a floating point instruction, and while investigating the issue, Merry and bunnei were worried that it may be a problem in Dynarmic, our ARM to x64 recompiler. It turns out the problem was just a bad default value in yuzu’s Dynarmic configuration. Remember what we said about bunnei and serendipity? With a simple one line change, a plethora of bugs were resolved! A special mention goes to Pokémon Sword/Shield, as that single line fixed the softlock that plagued us for months and made the game fully playable!

Here’s only a partial list of fixes:

Pokémon Sword/Shield - All softlocks fixed, running in tall grass fixed, hair salons fixed
The Legend of Zelda: Link’s Awakening - Miniature placing fixed
Toki Tori, Final Fantasy 7, Diablo 3, Project DIVA MegaMix - Distorted audio fixed
Team Sonic Racing - Physics fixed
Onimusha Warriors, Tales of Vesperia, The Messenger - Game logic fixed
Skyrim - Audio looping fixed, game progresses further
Oninaki - Elevator softlock fixed
All Unreal Engine 4 games - Motion jitter fixed
Super Smash Bros. Ultimate - Fighter select jitter / flickers fixed
Starlink - Softlock fixed, game progresses further

This sofa is no longer our enemy (Pokémon Sword/Shield)

Bug fixes and improvements

Morph used some Kirby magic and implemented the first steps to get World of Light working in Super Smash Bros. Ultimate. Even though it doesn’t work yet, the first step is always the most important one!

Kewlan strikes once again with more quality-of-life UI improvements. This time, they’ve fixed the placement of button mappings in the input settings for single joycons.

From this

To this

Not stopping there, Kewlan added a slider for the analog stick modifier, allowing keyboard users to half press the emulated sticks. Additionally, the sliders now show percentages, making them easier to read.

Precision

And to top it off, he also added a way to restore the default value for a hotkey. An important part of the user experience is having a tidy and useful interface.

More customization

Tobi fixed some of the internal workings of the input settings, and improved the games list sorting process. He also reworded some of our error and warning popups to be more user friendly.

The old errors

The new errors

Waluigi is not part of Smash, yet, but that doesn’t mean he can’t enjoy some limelight. Rodrigo decided to help the purple fellow and fixed the shadows in Mario Tennis Aces. The border color of textures in this game are in sRGB format, and we had some small precision errors. Now you can enjoy those intense matches!

WAA! (Mario Tennis Aces)

Rodrigo added indexed QUADS to Vulkan, this brings major graphical fixes to Xenoblade Chronicles 2 and Fast RMX! Some barrier fixes are still required to get Xenoblade Chronicles 2 rendering properly, but work on these rendering fixes is on-going.

From a dark void to RPG (Xenoblade Chronicles 2)

Blinkhawk implemented some optimizations to the GPU command list, improving performance in Diablo 3 and many other games. He also ported a Ryujinx hack made by gdkchan, Fast GPU Time. This helps force games to render at their maximum resolution, when they would otherwise dynamically lower it due to not hitting their target framerate. Some examples include ARMS, Super Mario Odyssey, Splatoon 2, Luigi’s Mansion 3, and Mario Tennis Aces. This is not only a graphical improvement, but also a way to avoid very high memory usage in dynamic resolution games. We still recommend the use of resolution mods, but if such mods are not available for your game, Fast GPU Time will help you. A good example of this is The Legend of Zelda: Breath of the Wild with the latest 1.6.0 update.

Milk baths are over Link, go save Zelda or something (Legend of Zelda: Breath of the Wild)

Fixed regressions

Rei found a 3D texture regression in the Wooden Kingdom of Super Mario Odyssey that was affecting both Vulkan and OpenGL. Blinkhawk investigated it and found that there was a bug in the texture cache. Now it works as intended again, with no more fog stripes on trees.

As it should be (Super Mario Odyssey)

Rodrigo fixed a regression found in Puyo Puyo Tetris while running in OpenGL. With it in place, character portraits have their proper white border rendered.

Better, right? (Puyo Puyo Tetris)

Rodrigo also fixed a regression in Kirby Star Allies, which restored the shading and life to this cute game. Kirby deserves a colorful world for his adventures!

Poyo! (Kirby Star Allies)

Future plans

Rodrigo also removed the need to have a Qt build with Vulkan support in Linux, which will help get Vulkan support in our Ubuntu pre-built packages.

That’s all for now, folks! See you in the May report!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

New Feature Release - Prometheus

CaptV0rt3x — Sat, 09 May 2020 05:37:00 +0530

Hello there, yuzu fans! We are very excited to share the news of another major feature release. Thanks to the efforts of our dev Blinkhawk, yuzu now supports Multicore CPU emulation. Hop right in, to read more about it!

In Greek mythology, Prometheus is a Titan that aided humanity by teaching how to make fire.
In modern society, it symbolizes the strive for scientific knowledge.
The Prometheus Project is about that - the journey to new emulation techniques.

Since we cannot really show performance boosts in pictures, here is a video by BSoD Gaming that takes you through all the improvements.

What is Multicore CPU emulation?

As many of you might know, yuzu is considered a HLE (high level emulation) emulator. This means that instead of running the real Switch OS (known as Horizon), yuzu has recreated its own version of the OS, built entirely from the ground up. Like your PC, the Switch has multiple cores (4, actually), and the Horizon OS can run multiple tasks in parallel on these cores using a kernel construct known as a thread. However, due to limitations of our old kernel design taken from Citra, yuzu was actually emulating this behavior using a single core on your host PC! This had led to an absurdly high CPU requirement for users.

So, what is "Multicore CPU emulation"? Put simply, instead of emulating the CPU on a single thread yuzu will now emulate the CPU using multiple threads; 4 to be precise - one for each Switch CPU core. Although it might sound simple or easy, it is nevertheless the biggest undertaking this project has seen up until now.

yuzu CPU emulation

yuzu’s initial CPU emulation and kernel were heavily based on Citra’s. The kernel emulated the external behavior of the Switch’s kernel but vastly differed from the Switch OS. Instead of saving contexts and switching from one guest thread to another within the kernel, we used a mechanism within Citra’s kernel that emulated the same behavior but with a complex system of stops and callbacks.

Not only that, but in the typical tradition of previous emulators, yuzu used something called a cycle timer. A cycle timer is a mechanism to emulate time on consoles by counting each guest instruction executed and adding it to global CPU ticks. These ticks can then be transformed into time units like nanoseconds by using the guest’s CPU frequency.

Drawbacks

Citra’s model was perfectly fine for single core emulation. It was accurate, simple, and worked perfectly for the 3DS as it used only one of its two cores for apps/games. However, in the case of yuzu, this wouldn’t hold true.

The Switch is a much more complicated and modern system that pushes 4 CPU cores, where 3 are used for apps/games. Not only that, but the scheduling is more robust and can be used in some more interesting and more complicated ways. Using Citra’s model for scheduling was all possible in yuzu but it had a few flaws of its own:

The code didn’t match the Switch OS and even though it had the same behavior, it was hard to keep track of changes and replicate them.
The code was very complex as there was a callback for everything and was hard to maintain.
This model would be extremely hard to run on multiple host threads.

Super Smash Bros. Ultimate

Prometheus

You might’ve heard rumors and whispers about this in the community recently. Prometheus is the internal codename for this feature’s development and it is a total rework of three things:

Kernel scheduling
Boot management
CPU management

Prometheus aims to ensure that emulation behaves the same as on the Switch while matching the code with the Switch’s original OS code. And, as a by-product, host multicore support using host timing has been added to yuzu. Host timing is just yuzu using the host’s (user’s) internal clock for timing.

The multicore feature of Prometheus is a beast in terms of thread handling. Originally yuzu used at best 2 threads: one for the CPU and one for the emulated GPU. Technically we also use a thread each for the UI, logging, the host GPU driver, and the host audio driver, but let’s ignore them for the time being.

With multicore, there are now 6 threads in use: four for the CPU, one for the timer, and one for the emulated GPU. It is worth noting that CPU core 4 is rarely used. Of these 6, effectively 5 threads have considerable use but not all will be running constantly.

Planning

Prometheus was a big undertaking that was set in two phases: planning phase and development phase. The planning phase was all about studying our current setup to make it work under this new scheme. This happened roughly over 8 months, and was mostly just research and brainstorming.

During this phase, Blinkhawk encountered multiple challenges and considerations for development. He started studying other emulators that already did multicore emulation such as Cemu, RPCS3, and Ryujinx.

These emulators all differed in their approaches to multicore. Some used Fibers for guest threads, 1:1 guest-host kernel threads, cycle timing, or host timing. In computer science, Fibers are lightweight threads of execution (Wikipedia).

For yuzu, we initially planned to use Fibers and cycle timers. We chose Fibers over kernel threads because changing a Fiber is at worst 50 host CPU cycles, whereas a kernel thread can be thousands of cycles and there’s no guarantee that the host OS will start running it right away.

In the case of cycle timers for yuzu multicore, they ended up being quite a pain. Cycle timers have many advantages over host timers:

They are deterministic,
They don’t leak the host state, and
They always advance for every instruction that Cycle timers are run.

We tried many theoretical models for multicore cycle timers and they all were pretty hard to set up while still having flaws. Sadly, cycle timers don’t work too great for multicore settings, because it is very hard to keep all the cores advancing at the same pace and to emulate idling accurately. For all these reasons, we opted for host timing instead.

Bayonetta 2

Development - Issues

Development started on February 1st of 2020. The first thing Blinkhawk did was to implement Spinlocks, Fibers, and host timing. Afterwards, he went ahead with the massive overhaul.

As he started the overhaul, the first issue he encountered was that for some reason yuzu was creating and destroying JITs (just-in-time compilers). Thus, whenever we resumed code from a guest thread and it went back to the JIT, it would hard crash. This was fixed by caching the JITs depending on the state of the page table, instead of creating a JIT every time. This way we could also avoid creating more JITs than necessary.

The second issue occurred on booting the first homebrew on multicore, where we found that guest vsync was messed up. By redesigning the server session we were able to identify the cause and fix it.

Here is where things started getting interesting. Blinkhawk implemented Condition Variables and Mutexes, which are the base syncing mechanisms in any multithreaded environment, and found an issue with how our JIT functions. Our JIT was heavily designed to work like Citra’s and it expected that on any SVC (Supervisor call) call to kernel, the code returned back afterwards.

Under the new architecture, a thread could easily call an SVC and be paused there, while another thread started running on that same JIT, thus causing a conflict. The easy solution was that instead of making a JIT per core, we would make a JIT per thread. This solution, however, costs us additional memory usage.

After fixing these issues, we were finally able to boot Super Mario Odyssey on multicore, but many games were still soft-locking due to an old bug we thought eradicated: Mutex Corruption. Mutex Corruption happens due to issues with exclusive memory handling in ARMv8. As it turned out, dynarmic had to be modified to fix it.

After looking into it, Blinkhawk realized exclusive memory in dynarmic was prone to a race condition when the exclusive address was written by a non-exclusive write. The solution was to save the current value on exclusive read and then atomic exchange it with a new value on exclusive write. By fixing this, most of the games were able to go in-game and many of them were fully playable.

Two games had interesting bugs on multicore: Luigi's Mansion 3 & Hyrule Warriors.

Luigi's Mansion 3 had an issue in which two threads, A & B, were running on cores 0 and 1 and after some scheduling, B was rescheduled to core 0 and A to core 1. But a thread cannot start running on a new core until it is liberated (freed). So core 0 scheduler was holding A and waiting for B to be freed, while core 1 scheduler was holding B and waiting for A to be freed, thereby causing a deadlock. The solution was that instead of exchanging threads on scheduling switch, we free the current thread and switch to an “intermediary” thread and then from there proceed to the next thread.

Luigi's Mansion 3

Hyrule Warriors had an issue that was caused by host timing. Our host timing implementation was based on Cemu’s approach and used x64 architecture’s hardware timer directly. This timer is way more accurate than ARMv8’s hardware timer present in the Switch.

The game soft locked at a point because a thread infinitely looped on a TimedWait of 30 nanoseconds. This function did some time calculations and later checked with the current time. If the timeout wasn’t reached at that moment, an SVC was called which paused the thread for some time and let the next thread run, effectively causing a yield.

In the Switch’s hardware, the timer’s accuracy isn’t too great and a TimedWait of 30 nanoseconds always resulted in the thread calling the SVC. Our host timer, however, was way more accurate and that function would never call the SVC. The solution, ironically, was to reduce the accuracy of our host timer a bit, to better match actual hardware.

Another interesting challenge was implementing pausing/resuming in multicore. As you know, you can pause and resume yuzu in our current versions. This was simple before because emulation occurred in steps and you just had to stop on the next step. But on multicore, emulation is continuous and unmanaged in the same sense.

Thus, implementing this was very hard due to how multicore scheduling worked. The original solution was to modify scheduling to support it but that proved very complicated to do. After a while, we figured out a pretty easy solution without having to modify anything. We would create a kernel thread for each core and make that kernel thread pass control from and to the CPU Manager to the emulation.

Animal Crossing: New Horizons

What to expect with games?

Many of you may be eager for multicore but have in mind that there are other bottlenecks as well. Not every game utilizes multithreading effectively and makes the most use of the Switch’s CPU. Some games, like Super Mario Odyssey, barely use cores 1 & 2, by doing all processing in core 0, effectively making them gain nothing from multicore. However, games like Breath of The Wild see some performance boost but are still bottlenecked by the emulated GPU.

The Legend of Zelda: Breath of the Wild

The emulated GPU depends on four things:

Your CPU’s single-core speed. A single host CPU core translates all the commands from guest GPU (Switch) into host GPU (User) commands. So, having a CPU with great single-core speeds is most beneficial.
Your GPU Bus Speed. yuzu heavily relies on the bandwidth available in the GPU bus. This is the speed at which data is uploaded to and from your GPU and this varies depending on PCIe generation and allocated lanes.
The quality of your GPU drivers. AMD’s drivers for OpenGL are terrible while NVIDIA’s are great.
Your host GPU itself, be it NVIDIA, AMD, or Intel.

Lastly, be aware that RAM speed, amount of RAM, and the type of processor in your system, will also influence your experience. The initial release may use additional memory (100mb to 3Gb depending on the game). We are currently stability-testing a fix for this additional memory usage.

Current Known Issues

Getting multicore to run perfectly is a big deal and in our internal testing we found that audio can be slower in multicore. Activate Audio Stretching to mitigate the issue. If you come across any softlock or bug that is not present in mainline but present in early access, notify us and include the following data with it.

* Game name
* Version of the game
* Game savefile
* Steps to reproduce the softlock
* Whether the softlock is random or consistent (always happens in the same spot)

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Progress Report March 2020

GoldenX86 — Mon, 20 Apr 2020 07:11:00 -0300

How are you doing in this quarantine, yuzu fans? We hope you are all staying in your homes safe and sound. Today, we are bringing you a report on a few changes from the past month for both the Early Access and regular Mainline versions of yuzu.

We have on our plate a couple of bug fixes, some graphical improvements, the first “performance win” for Intel GPUs, a really serious case of serendipity, and some groundwork for amazing improvements that will be coming to you in a “near-ish” future.

Bug fixes and improvements

After some intensive debugging by Rodrigo, an OpenGL rendering bug in ARMS (that was with us since the game started to boot), was solved by simply updating our buildbot virtual machine from Visual Studio 2017 to the latest 2019 version. Thanks to DarkLordZach for the change!

PSA - Please update to or install the latest Visual C++ 2019 x64 redistributable, or else you won’t be able to open yuzu, as it will complain that the library VCRUNTIME140.dll cannot be found.

Better, right?

perillamint and bunnei stubbed (this means to send a fake everything’s OK signal so the game can continue) some VR related services. These changes are needed for version 1.6.0 of The Legend of Zelda: Breath of the Wild, 1.3.0 of Super Mario Odyssey, and versions 3.1.0 and above of Super Smash Bros. Ultimate.

Commercial games aren’t everything. Rodrigo decided to give homebrew lovers and old-school gamers something to play with by implementing some attributes from the old OpenGL 1.X and 2.X days. It’s now possible to run Xash3D, so you can frag in Counter-Strike, or follow G-Man’s orders in Half-Life! Currently, this needs to be manually built with newer dependencies, but that should be solved for good in the near future.

Margen67 and Morph wanted to improve the graphics for games and so they added Anisotropic Filtering (AF) to yuzu. With this feature in place, distant textures now look much sharper, improving game quality even over what the original Switch can produce! Games like Pokémon Sword, Pokémon Shield, and Fire Emblem: Three Houses benefit a lot from this; however, some other games don’t respond well to this new feature, one example being Astral Chain. Feel free to experiment with it!

An example in Pokémon Sword:

AF Off

AF 16x

And another example in Fire Emblem: Three Houses:

AF Off

AF 8x

Shader cache invalidations are something our users don’t like at all. We don’t either, but it’s all part of the process of improving yuzu to achieve better performance and accuracy. For example, one of our recent invalidations was needed to fix the reflections in Luigi’s Mansion 3, making certain parts of the game playable.

Because the art of dancing is important, namkazt and Rodrigo have been fighting with the code, allowing us to enjoy 3D graphics in Hatsune Miku: Project DIVA MEGA39’s, and as collateral, fixed some rendering issues in Bayonetta 1 and Super Smash Bros. Ultimate.

Miku Miku Dance!

Super Smash Bros. Ultimate's menu (Before & After)

Kewlan, a regular in our Discord Server, submitted a small change to our input mapping GUI, changing the position of the shoulder buttons so they no longer make anyone angry.

Incorrect.

Much better.

We also have a cool improvement by Tobi. The Switch is a surround sound compatible console and our implementation of downmixing removed any channel that wasn’t left or right. By keeping the extra channels and mixing them in the left and right stereo outputs, the sound in tons of games, including Luigi’s Mansion 3, Sonic Forces, and Bayonetta, has been improved.

A peculiar case of “Even a broken clock is right twice a day!”

The Nintendo Switch supports ASTC, a type of texture format generally used in mobile hardware, such as phones and tablets, in order to reduce bandwidth usage (a limited resource in those devices). Since it’s a heavily compressed format, decoding it via the CPU, like it is normally done on PC, is a time-consuming task.

To give an example, Astral Chain is a game that uses ASTC very extensively and in bizarre ways, as previous fixes and optimizations have shown. On NVIDIA and AMD graphics hardware, the first scene of a new game typically takes 17 seconds to load. The GPU has to wait for the CPU to decode all the ASTC textures, and thus slowing down the whole process.

Thanks to Rodrigo’s research, it was discovered that on any recent Intel GPU this same operation is immediate and occurs with no delay, due to it being the only vendor providing a native ASTC decoder in their hardware. That’s right, the best way to experience Astral Chain in yuzu is with a small, and typically inferior, iGPU (like the ones that come in any desktop or notebook CPU from Intel).

On the topic of formats, implementing the RG32 and RGB32 vertex formats fixed a room that refused to load in The Legend of Zelda: Link’s Awakening in Vulkan. Great work, Rodrigo!

It works!

Paving the road for even bigger changes

Rodrigo’s initial work on Transform Feedback has concluded and is now partially working. This has already helped games like POKKÉN Tournament DX, Donkey Kong Country: Tropical Freeze and Xenoblade Chronicles.

An optimization by Blinkhawk reduced the use of RAM by 1GB. When talking about RAM usage, less is best!

Now, for an important but also astonishing fix; one that nobody expected, not even our project leader bunnei. While he was working on fixing what seemed to be a simple bug on Final Fantasy VIII, he also accidentally fixed Super Smash Bros. Ultimate fights! This case of serendipity, is without a doubt, a surprise, but a welcome one.

Now all users can brawl to their hearts’ content thanks to a measly 5-line change in yuzu’s code! However, keep in mind that any Super Smash Bros. Ultimate update newer than 3.1.0 will work, but will also make the characters T-pose, resulting in hilarious fights and victory screens. We’re working on resolving this, but for now, stick to update 3.1.0 or older!

bunnei fixed audio crackling in various games like Crash Team Racing and Super Mario Odyssey. We are slowly but surely improving our audio quality. He also implemented initial support for 32-bit ARM emulation. Nothing tangible can be tested yet, but thanks to this, it will be possible in the future to run 32-bit games like Mario Kart 8 Deluxe.

And last but not least, Blinkhawk has been making some serious changes to yuzu’s GPU emulation, while also laying the foundation for the recent rework of yuzu’s Virtual Memory Manager (codename: Project Epimetheus).

These, in turn, will help further advance the development of Project Prometheus, one of the super-secret Projects our devs are currently working on to bring some considerable changes to yuzu’s performance and hardware requirements. Stay tuned to hear more about them in the future!

That’s all for now folks, see you in the April report.

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

New Feature Release - Vulkan

CaptV0rt3x — Tue, 03 Dec 2019 21:17:00 +0530

A very good day to all you yuz-ers out there. The curtains are up and the most awaited feature of yuzu is finally here! The Vulkan renderer for yuzu is now available for users on Early Access. To find out more about it, jump right in!

Vulkan for yuzu

Super Mario Odyssey

Astral Chain

Link's Awakening

Breath of the Wild

For the past year, the most awaited and requested feature for yuzu has been the Vulkan Renderer. Many users, especially those with AMD GPUs, have been patiently waiting for this day.
Download the latest Early Access build via the installer now to try it out! After you download the build, go to Emulation -> Configure -> Graphics and select Vulkan in the API dropdown.

yuzu Configuration

We highly recommend using the latest drivers, or beta drivers, as vendors are actively fixing bugs in their Vulkan drivers. Nvidia appears to encounter the least bugs, but it is still strongly recommended to keep your drivers up to date.

How It All Started…

Barely a year had passed since the Nintendo Switch launched, but there it was, yuzu - The Nintendo Switch Emulator - already running several games with stellar performance and stunning graphics. But it came with a caveat; to deliver that performance, yuzu exclusively needed an Nvidia GPU among several other hardware requirements.

This was mainly due to the low performance on AMD GPUs OpenGL Windows drivers. For AMD users, this meant that they either had to start using Linux, where the drivers were a little better, or had to buy an Nvidia GPU, and neither of those was an easy choice. Thus we quickly realized the need for a way to deliver the same performance to our AMD users, and Vulkan seemed to be the answer!

To tackle this, one of our resident GPU emulation experts - Rodrigo (aka ReinUsesLisp) - set out to master Vulkan and implement a renderer in yuzu using this API. Rodrigo started experimental work on the Vulkan renderer, with the customary Hello World - by rendering a RED screen.

He used existing switch homebrew like SpaceNX and Push A button, and later wrote his own homebrew app of a blinking screen and got them to render using the Vulkan renderer successfully. With some progress, it was now time for him to implement shaders on the Vulkan renderer. (If you are interested, you can check out the homebrew here.)

Before we get into deeper technical details, we need to understand a few things:

The Nintendo Switch has an Nvidia GPU and games can use either OpenGL or NVN API (Nvidia proprietary API), to communicate with the GPU and render visuals. (Games might use Vulkan, but we are yet to see any games using it)
GPUs use small programs called shaders to control the GPU rendering pipeline. For more info, read here.
Shaders have instructions inside them for the GPU to perform various types of operations.
yuzu decodes these shader instructions from games to guest GPU (Switch), turns them into GLSL (OpenGL Shading Language) code, and then rebuilds those shaders to work on the Host GPU (User GPU) to get games rendering.
SPIR-V is an intermediate language for defining shaders in Vulkan, which is sort of similar to OpenGL’s GLSL. For more info, read here.

Now that we have some context, let’s dive deeper!

Rodrigo wrote Sirit - a runtime SPIR-V assembler to generate SPIR-V code easily. Basically, there isn’t a built-in way to generate SPIR-V code. Most game developers actually use a high level shader language and compile them statically. And as yuzu could only convert the game shaders to GLSL, he used Sirit to generate SPIR-V shaders, instead of GLSL, for Vulkan.

Game developers usually write shaders using GLSL or HLSL and compile it to SPIR-V with a compiler and send that to the driver.

However, yuzu Vulkan generates SPIR-V on the go and sends that to the driver.

When development began, yuzu didn’t have a shader IR (intermediate representation). As a result, Rodrigo had to copy and adapt many parts of the code, to the point that it became bug ridden and unmaintainable. At this stage, we decided to write a shader IR that would allow us to share the shader decoding logic on both GLSL and SPIR-V.

Vulkan experiments - Super Mario Odyssey (broken)

What is shader IR?

An IR (intermediate representation) is a representation of the program “between” source and target languages. A shader IR in yuzu’s context would be the representation of game shaders decoded from their actual form and before they were rebuilt for GLSL or SPIR-V.

In regards to Shader IR, Blinkhawk rewrote how guest shaders are analysed in control flow (the code that tells how a shader diverges in execution) from the ground up. He created a decompiler that removes stack based branches which result in under performant shaders in Intel and AMD, and created a more advanced decompiler that could convert all the branches in the shaders into higher level structures (ifs, loops, etc). He also corrected control flow in SPIR-V shaders and fixed some crashes that occurred on AMD due to unoptimized control flow structures.

Simply put, he redid the whole system on which shader IR is based, after Rodrigo converted most of the instructions into IR and setup the foundation.

Kind of like reorganizing a messy closet, after segregating its contents.

While the shader IR was being worked on, Rodrigo was parallelly working on the Vulkan renderer, and managed to get more homebrew working, but soon ran into further issues. As a result, development of Vulkan didn’t continue for a few months, and quite some time was spent implementing the Shader IR.

Problems and Solutions…

Problem 1: Texture Cache

What is a Texture Cache?

The texture cache handles everything related to texture management. When a game asks to sample a texture, we create a texture like the game wants and we fill its texels (pixels) from guest data. When the game wants to render to a texture, we do the same process. The texture cache is full of border cases that need to be properly handled.

Rodrigo and Blinkhawk, our GPU emulation experts, had just started working on the shader IR and Rodrigo ran into issues with the Vulkan renderer. Upon investigation, they realized that the existing texture cache was too heavily embedded in OpenGL and there was no easy way to make it API agnostic. In other words, they found it was very difficult to decouple the texture cache’s backend logic from the frontend, so that they could use it for both OpenGL and Vulkan.

Though Rodrigo (with some help from Blinkhawk) implemented a primitive texture cache on Vulkan to get Sonic Mania & Cave Story+ rendering, Blinkhawk saw the need for a better approach to solve this problem. He (Blinkhawk) then reimplemented the texture cache from scratch, using some of Rodrigo’s ideas and some inspiration from the original texture cache. This is a generic texture cache that is able to handle all of the border cases, in generic code that can be implemented on both OpenGL and Vulkan.

Problem 2: Buffer cache

What is a Buffer Cache?

A buffer cache stores & caches most guest GPU memory objects (like vertex data, index data, constant buffers, global memory and others) into host GPU memory objects, thus avoiding having to continuously upload/download data in between Host & Guest GPUs. This is needed because the Host GPU can’t normally use Guest GPU’s data directly. Host GPU = yuzu user's GPU & Guest GPU = Switch GPU

yuzu’s original buffer cache was a stream based buffer, which was brought from Citra. Rodrigo observed that this buffer cache couldn’t handle large buffers properly. So he made a dual cache - with a stream buffer for small buffers and a single buffer for large buffers, which allowed him to handle memory more easily on Vulkan.

Later, Blinkhawk took over and sought to improve it further by using ideas from texture cache. While it worked as an experiment, it had some performance issues. So, he rewrote the buffer cache from scratch, based on a completely new approach, so that it was compatible with both OpenGL and Vulkan. This new approach for the buffer cache was to map 1:1 guest GPU memory with host GPU memory i.e., yuzu will now automatically allocate GPU memory chunks depending on the game’s utilization and a single chunk on guest memory will be mapped to a single chunk on host memory.

Benefits of a buffer/texture cache

Improves performance significantly,
reduces syncing between Guest/Emulated GPU and Host GPU,
allows controlling host memory capacity, etc.

Trivia: The Buffer Cache is what got animations working on Smash Ultimate (along with compute shaders)

Vulkan Continued…

As a result of fixing the aforementioned problems, we had managed to abstract away the OpenGL backend from the frontend. This was very crucial for the progress of Vulkan development, as it allowed us to narrow down issues from something is broken and I don't know what it is to this is a Vulkan exclusive bug. Along the way, we fixed many long standing bugs on popular games like fog and water interactions in Super Mario Odyssey, and found new ones, like broken shadows in the same game.

Now, let’s get to the part that everyone cares about:

How is the performance compared to OpenGL?
With Vulkan on yuzu, AMD GPUs now perform mostly on par with Nvidia GPUs. As an added benefit, Intel onboard graphics now have better or around the same overall performance too. On average, the performance is still a bit lower than what you’d observe on OpenGL, but that could change very soon with future optimisations.

Note 1:

Some games don’t yet work with Vulkan on Nvidia GPUs. This is a known issue and we are investigating.

yuzu Vulkan vs OpenGL (on AMD GPU)

yuzu Vulkan vs OpenGL (on Nvidia GPU)

yuzu Vulkan vs OpenGL (on Intel iGPU)

Note 2:

Some games perform worse with Vulkan due to how they change framebuffers.
This is a result of how the games were developed, and might change with vendor driver improvements.

yuzu Vulkan (on Intel iGPU)

One noticeable improvement is the shader build times. We didn’t profile the others, but Nvidia’s SPIR-V compiler is surprisingly fast. Where some effects on OpenGL GLSL may take 4 to 5 seconds to build, Vulkan SPIR-V may take only a few milliseconds.

yuzu’s OpenGL and Vulkan backends are now close in feature parity, but both still lack some features the other has. Rodrigo has been recently experimenting with adding tessellation shaders to Vulkan instead of OpenGL, since the Vulkan codebase is better laid out which makes things easier to implement for him. Vulkan also lacks a few texture formats that we have yet to add, since we haven’t seen games using them.

Fun Fact: Tessellation shaders are used in the recently released Luigi's Mansion 3!

Testing Tessellation shaders in Vulkan

Behold - Vulkan in All It’s Glory!

Here are a few screenshots taken with yuzu using the Vulkan renderer.

Super Mario Odyssey

Link's Awakening

Marvel Ultimate Alliance 3

Onimusha: Warlords

Resident Evil 4

Pokémon Sword/Shield

Vulkan and Its Shortcomings

While many uninformed users believe Vulkan to be a saviour and a single answer to all performance issues with OpenGL, even though their issues were because of their old hardware, Vulkan is not without any shortcomings. To understand these, let us first understand the situation with the Nintendo Switch’s GPU.

Maxwell and Pascal Nvidia GPUs are heavily optimized in hardware for D3D11 and OpenGL software. It seems that whenever Nvidia gets a chance to put something in the hardware, they take it. Since the Nintendo Switch’s GPU is a 2nd generation Maxwell GPU, it comes with additional features like ASTC textures and efficient half-precision float math.

Nvidia’s OpenGL driver is a scary monstrosity, it’s really fast. And to achieve this Nvidia has, over the years, invested resources heavily to make their OpenGL software (the driver) and their hardware really efficient. They have not only optimized their software to be fast for OpenGL, but also their hardware.

Both NVN and OpenGL expose Nvidia’s Maxwell hardware at its greatest. Lots of OpenGL features that are (sometimes wrongly) considered “legacy”, “old”, or even “emulated by the driver” are actually natively supported by the hardware (in the case of Nvidia). The problem arises when Switch games use these features.

Vulkan wasn’t designed with these features in mind. Some of these features were intentionally left out of the standard and the committee does not want to add them (not even as extensions) unless they really have to, or big companies behind CAD software require it. To sum it up, if a Switch game uses X feature supported natively by the hardware, and this feature is not available on Vulkan; it has to be emulated with a slower path or not emulated at all.

Here is a reduced list of features that are supported by Nvidia Maxwell hardware - exposed in OpenGL, but not supported in Vulkan:

OpenGL Feature	Games that use it
Minus one to one depth space - `(-1 to +1)`	Used in nearly all Nintendo games
Quads, quad strips, polygons and line loops primitive topologies (e.g. rendering geometry with quads instead of triangles)	Used by Xenoblade Chronicles 2
Bindless textures	Used by Super Mario Party, Super Mario Odyssey and others
Legacy varyings (vertex attributes from the D3D9 era, like front colors and fog coordinates)	Used by Dragon Quest Builders
`GL_CLAMP` texture filtering	Used by Hollow Knight
`uint8` indices (available as an extension, not supported on all vendors)	Used by Pokémon Let’s Go: Eevee and many others
Conditional rendering (available as an extension, but not exposed on AMD’s proprietary driver)	Used by Super Mario Odyssey and others
Copying depth images to color images and vice-versa (only on Nvidia)	Used by Super Mario Odyssey, Zelda Breath of the Wild and others
Alpha testing (eliminating pixels with some transparency)	Used by Smash Ultimate, Bayonetta and Astral Chain

Not having these features forces the Vulkan renderer to emulate them with slower techniques. At the moment of writing this article, features that are not known to be used by Switch games and some with extensions widely available, have been excluded from the above list.

In addition to these, Vulkan also doesn’t yet support a feature that has been supported by OpenGL since 1992 - a mutable pipeline state. In Vulkan, to define how a triangle is going to be rendered, you create a PSO (Pipeline State Object). For instance: “the clockwise side of a triangle is the front face”, “cull the back face of the triangle”, “render triangles”, “enable blending (transparency)”, “use these shaders”.

In case you want to change any of these attributes, an entire new pipeline has to be created. This has the advantage of eliminating “shader recompilations” that cause micro-stutter at boot on some games. The problem is that, again, Nvidia hardware can change this atomically.

If you want to change what faces of a triangle to cull (to render shadows for instance); you just queue the change on the GPU and it’s done. And on OpenGL too, it’s the same thing. yuzu currently doesn’t take much advantage of this feature, but we do have plans to optimize the current OpenGL backend for this.

In summary, for Switch emulation, OpenGL is the API to rule them all (unless Nvidia decides to release NVN on desktop, but that’s doubtful). Vulkan is great to take advantage of hardware that is not OpenGL friendly and it receives more love from some vendors and the market, so better tools, more extensions and better driver support will appear in the future.

Conclusion

Vulkan is still EXPERIMENTAL!

The Vulkan renderer for yuzu is still experimental and doesn’t yet have all the features implemented. In addition to that, the Vulkan renderer currently DOES NOT support shader caches and the infamous Resolution rescaler is not yet integrated into the Vulkan renderer. While some games like Zelda: Link’s Awakening work really well on Vulkan, many games like ARMS, Crash Team Racing, and Luigi’s Mansion 3 crash on it.

As this feature release is a monumental one, we want to make sure that all the rough edges are polished before making it available to normal users.

And as such, the Vulkan release will take more time to become available on Mainline. We’ll be slowly rolling it out in December.

As always, we’re so thankful to our supporters. Please enjoy testing out Vulkan on your own games, and remember to reach out to us with any feedback/bugs you experience on our Discord’s exclusive Patreon channels!

yuzu on yuzu

Progress Report January 2024

Multiprocess, services, LLE applets, and Project Leviathan

Device mapping and SMMU

Project Leviathan

Now Presenting

I AM the applet manager

Sounds good

Universal Serialization Byte[]

Other service rewrites and fixes

Graphics changes

A dose of Dozen

Your regularly scheduled GPU changes

Android augmentations

Miscellaneous changes

Hardware and software section

NVIDIA TrueHDR

Lossless Scaling to the rescue

AMD Fluid Motion Frames

Intel delivering on its promises

Qualcomm

Exynos and Mali

Linux

Future projects

Please consider supporting us on Patreon! If you would like to contribute to this project, check out our GitHub!

Progress Report December 2023

Graphics changes and driver fixes

Vulkan

OpenGL

Android adventures, and kernels with benefits

Saving RAM makes games boot fast

4K

Other Android specific GPU changes

Android-specific UI and miscellaneous changes

Memory heap allocation, or how the Linux kernel can be wrong sometimes

Project Leviathan, applets, and input fun

Miscellaneous changes

Multiprocess preliminary work

Core, kernel, and file system changes

UI changes

Hardware section

NVIDIA, safe to update

Proprietary NVIDIA driver

NVK

AMD

Intel…

Qualcomm

Proprietary Qualcomm driver

Turnip

Mali moment

Future projects

Please consider supporting us on Patreon! If you would like to contribute to this project, check out our GitHub!

Progress Report November 2023

Mario Role-playing as Mario!

Project NiCE

Yet more changes for Android

Graphics changes

Applets, input, and other services

Miscellaneous changes

Hardware section

AMD, mixing drivers

Intel, fixing drivers (WIP)

Future projects

Please consider supporting us on Patreon! If you would like to contribute to this project, check out our GitHub!

Progress Report October 2023

Wowie Zowie!

The GPU changes

Android changes

UI and Applet changes

Kernel, CPU, and file system changes

Audio changes

Hardware section

NVIDIA, our fault this time

AMD, giving a last hurrah to Polaris and Vega

Turnip, a very quickly improving work-in-progress

Future projects

Please consider supporting us on Patreon! If you would like to contribute to this project, check out our GitHub!

Progress Report September 2023

Of Miis and applets

Graphics changes

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!

Please consider supporting us on Patreon!
If you would like to contribute to this project, check out our GitHub!