mirror of
https://github.com/yuzu-emu/yuzu-emu.github.io.git
synced 2026-08-09 11:15:00 +00:00
Apply suggestions from code review
Flam's Co-authored-by: Schplee <24275329+Schplee@users.noreply.github.com> Co-authored-by: liamwhite <liamwhite@users.noreply.github.com>
This commit is contained in:
Matías Locatti
GitHub
parent
ba68602f2b
commit
ba07072c93
|
|
@ -5,34 +5,34 @@ author = "GoldenX86"
|
|||
forum = 0
|
||||
+++
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Before we start, we have some important news to share before we dive into the report.
|
||||
It seems that some users have been experiencing crashes when trying to use Vulkan or change settings.
|
||||
The culprit is none other than `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 get rid of this piece of… software.
|
||||
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 or button fonts.
|
||||
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](https://github.com/lat9nq), yuzu {{< gh-hovercard "10603" "now ships with" >}} virtually all {{< gh-hovercard "10797" "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 in the guest.
|
||||
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, Flatpak being its usual annoying self, Windows has some special needs. There are two important things to keep in mind:
|
||||
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 got released, users needed to run at least a 2019 version of Windows 10, with 1809 no longer being compatible. For LTSC users, this meant only the newest 2021 release would work. We later {{< gh-hovercard "11030" "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. Get it from this link: https://aka.ms/vs/17/release/vc_redist.x64.exe
|
||||
- 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 {{< gh-hovercard "11030" "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!
|
||||
|
||||
|
|
@ -63,7 +63,7 @@ The following bugs have now been fixed as a result:
|
|||
"./rainfix.mp4"
|
||||
>}}
|
||||
|
||||
- Fixes some particle corruption exclusive to `Tears of the Kingdom` seen for example while teleporting.
|
||||
- Fixes some particle corruption exclusive to `Tears of the Kingdom` seen, for example, while teleporting.
|
||||
|
||||
{{< single-title-imgs
|
||||
"It’s not perfect yet, but it’s almost there (The Legend of Zelda: Tears of the Kingdom)"
|
||||
|
|
@ -79,7 +79,7 @@ The following bugs have now been fixed as a result:
|
|||
"./smofix.mp4"
|
||||
>}}
|
||||
|
||||
- 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.
|
||||
- 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.
|
||||
|
||||
{{< single-title-imgs
|
||||
"Hey, Noah’s eyes are up here (Xenoblade Chronicles 3)"
|
||||
|
|
@ -95,15 +95,15 @@ The following bugs have now been fixed as a result:
|
|||
"./picfix.png"
|
||||
>}}
|
||||
|
||||
And more.
|
||||
- And more!
|
||||
|
||||
{{< gh-hovercard "10783" "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 or IR, which is a middle format that can be optimised 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.
|
||||
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.
|
||||
Some quick maffs, and you can see how 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.
|
||||
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, as it is not uncommon to see a laptop with only 8GB of RAM and a 12 thread-equipped Ryzen 5500U for example, as well as 8GB phones and tablets.
|
||||
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[]](https://github.com/liamwhite) 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!
|
||||
|
|
@ -143,7 +143,7 @@ A bug affecting how NVN virtual images were being remapped after sparse memory g
|
|||
"./yfcfix2.png"
|
||||
>}}
|
||||
|
||||
{{< gh-hovercard "10953" "Fixing this regression" >}} returns proper rendering to these games.
|
||||
{{< gh-hovercard "10953" "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 {{< gh-hovercard "10956" "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.
|
||||
|
|
@ -153,7 +153,7 @@ In order to avoid crashes in Unreal Engine 4 games like this, the LLE slow code
|
|||
>}}
|
||||
|
||||
This pull request introduced a regression that affected rendering in `Metroid Prime Remastered`.
|
||||
Thankfully [gidoly](https://github.com/gidoly) quickly solved it by {{< gh-hovercard "11012" "merging both approaches," >}} old and new.
|
||||
Thankfully, [gidoly](https://github.com/gidoly) quickly solved it by {{< gh-hovercard "11012" "merging both approaches," >}} old and new.
|
||||
|
||||
{{< single-title-imgs-compare
|
||||
"Chozo Suite error 404: Texture not found (Metroid Prime Remastered)"
|
||||
|
|
@ -162,7 +162,7 @@ Thankfully [gidoly](https://github.com/gidoly) quickly solved it by {{< gh-hover
|
|||
>}}
|
||||
|
||||
While working on these crashes, byte[] changed the behaviour of the Vulkan memory manager to prefer (instead of require) {{< gh-hovercard "10994" "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.
|
||||
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 hardware.
|
||||
|
||||
|
|
@ -182,19 +182,19 @@ 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 {{< gh-hovercard "10668" "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%.
|
||||
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 {{< gh-hovercard "10818" "additional samples checks" >}} when finding the correct render target, [vonchenplus](https://github.com/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 additionally fixes incorrect colour and shadows in `SPONGEBOB SQUAREPANTS THE COSMIC SHAKE`.
|
||||
This change also fixes incorrect colour and shadows in `SpongeBob SquarePants: The Cosmic Shake`.
|
||||
|
||||
{{< single-title-imgs-compare
|
||||
"Yeah that portrait wasn’t very engaging, your excellency (Fire Emblem Engage)"
|
||||
"That portrait wasn’t very engaging, your excellency (Fire Emblem Engage)"
|
||||
"./feebug.png"
|
||||
"./feefix.png"
|
||||
>}}
|
||||
|
||||
vonchenplus also fixed {{< gh-hovercard "10798" "resolution scaling issues" >}} affecting `Titan Quest` and `Crysis Remastered`; no more smaller duplications that used to take a corner of the screen!
|
||||
vonchenplus also fixed {{< gh-hovercard "10798" "resolution scaling issues" >}} affecting `Titan Quest` and `Crysis Remastered`; glitchy picture-in-picture bug begone!
|
||||
|
||||
{{< single-title-imgs-compare
|
||||
"Yes, we can run Crysis, now at 4k (Crysis Remastered)"
|
||||
|
|
@ -204,7 +204,7 @@ vonchenplus also fixed {{< gh-hovercard "10798" "resolution scaling issues" >}}
|
|||
|
||||
OpenGL also got some love once again thanks to efforts made by [Epicboy](https://github.com/ameerj).
|
||||
|
||||
In a surprising discovery (or as said 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.
|
||||
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 {{< gh-hovercard "10916" "beautiful driver trick" >}} gives a 2-10% performance increase depending on the size of the GPU.
|
||||
|
|
@ -254,11 +254,11 @@ This change also improved frametime consistency, especially in sudden spikes, wh
|
|||
"./frame2.png| I have become frametime, the destroyer of gameplay"
|
||||
>}}
|
||||
|
||||
Users like to try 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.
|
||||
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](https://github.com/mrcmunir) decided to change this and {{< gh-hovercard "10635" "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.
|
||||
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 {{< gh-hovercard "10829" "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.
|
||||
|
|
@ -275,10 +275,10 @@ Thanks to the joint work of byte[] and [GPUCode](https://github.com/GPUCode), an
|
|||
|
||||
[Kept you waiting, huh.](https://www.youtube.com/watch?v=6EBuKP-uc94)
|
||||
|
||||
This means users of Mediatek, old Samsung Exynos, and Google Tensor CPUs [(among others)](https://en.wikipedia.org/wiki/Mali_(processor)#Implementations) can run their games on yuzu as long as they have a [G series Mali GPU](https://en.wikipedia.org/wiki/Mali_(processor)#Variants), for example the Mali-G710 on the Pixel 7 series.
|
||||
This means users of Mediatek, old Samsung Exynos, and Google Tensor CPUs [(among others)](https://en.wikipedia.org/wiki/Mali_(processor)#Implementations) can run their games in yuzu as long as they have a [G-series Mali GPU](https://en.wikipedia.org/wiki/Mali_(processor)#Variants), for example the Mali-G710 on the Pixel 7 series.
|
||||
|
||||
{{< single-title-imgs
|
||||
"SUPER MARIO ODYSSEY and Pokémon Mystery Dungeon Rescue Team DX. Pics taken with a Pixel 7 Pro"
|
||||
"SUPER MARIO ODYSSEY and Pokémon Mystery Dungeon Rescue Team DX (Running on a Pixel 7 Pro)"
|
||||
"./mali1.png"
|
||||
"./mali2.png"
|
||||
>}}
|
||||
|
|
@ -286,23 +286,22 @@ This means users of Mediatek, old Samsung Exynos, and Google Tensor CPUs [(among
|
|||
This theoretically doubles the compatibility of yuzu’s Android builds, as Mali is the most common GPU family in the Android ecosystem.
|
||||
|
||||
{{< single-title-imgs
|
||||
"The Legend of Zelda: Skyward Sword HD, Advance Wars 1+2: Re-Boot Camp, and OCTOPATH TRAVELER. Pics taken with a Pixel 7 Pro"
|
||||
"The Legend of Zelda: Skyward Sword HD, Advance Wars 1+2: Re-Boot Camp, and OCTOPATH TRAVELER (Running on a Pixel 7 Pro)"
|
||||
"./mali3.png"
|
||||
"./mali4.png"
|
||||
"./mali5.png"
|
||||
>}}
|
||||
|
||||
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.
|
||||
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 from getting no rendering output at all, byte[] {{< gh-hovercard "10790" "disabled the use of the extension" >}} on Mali hardware.
|
||||
To avoid users of affected drivers experiencing no rendering output at all, byte[] {{< gh-hovercard "10790" "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.
|
||||
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.
|
||||
What can we say–we’re new at this.
|
||||
|
||||
To begin with, [PabloG02](https://github.com/PabloG02) has given us a hand again, this time by {{< gh-hovercard "10551" "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.
|
||||
|
||||
|
|
@ -310,13 +309,13 @@ To begin with, [PabloG02](https://github.com/PabloG02) has given us a hand again
|
|||
"./move.png| Place your input anywhere you want!"
|
||||
>}}
|
||||
|
||||
To help users with transferring the required files to yuzu and with debugging, PabloG02 also {{< gh-hovercard "10578" "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 on our official channels. Thanks!
|
||||
To help users with transferring the required files to yuzu and with debugging, PabloG02 also {{< gh-hovercard "10578" "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!
|
||||
|
||||
{{< imgs
|
||||
"./firmware.png| And then select your firmware dump location"
|
||||
"./firmware.png| 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 prefer less or more visible buttons.
|
||||
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](https://github.com/t895) added a dialog to {{< gh-hovercard "10557" "adjust the scale and opacity" >}} of the overlay controls.
|
||||
|
||||
{{< imgs
|
||||
|
|
@ -329,7 +328,7 @@ For cases like these, [t895](https://github.com/t895) added a dialog to {{< gh-h
|
|||
"./ov2.png"
|
||||
>}}
|
||||
|
||||
yuzu includes a notification to ensure the app isn’t closed by Android while switching apps.
|
||||
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.
|
||||
|
|
@ -377,7 +376,7 @@ It’s not fun having to constantly repeat the process to install every single t
|
|||
|
||||
Big Boss [bunnei](https://github.com/bunnei) made some changes to the {{< gh-hovercard "10746" "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.
|
||||
|
||||
Transferring from the desktop releases is `Reactive Flushing`, an option that can significantly reduce performance in the name of rendering accuracy.
|
||||
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.
|
||||
|
|
@ -389,7 +388,7 @@ We’ll revisit this toggle once native code execution is implemented.
|
|||
|
||||
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 {{< gh-hovercard "10751" "touchy behaviour," >}} making playing visual novels with no overlay buttons a joy.
|
||||
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 {{< gh-hovercard "10751" "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 {{< gh-hovercard "10760" "per-app languages," >}} so properly declaring the available language translations allows users to take advantage of this feature.
|
||||
Thanks [flTobi](https://github.com/FearlessTobi)!
|
||||
|
|
@ -419,17 +418,17 @@ As a way to warn users with devices that may not be capable of stable emulation,
|
|||
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 {{< gh-hovercard "10945" "support for Android 14." >}}
|
||||
Better be ready beforehand!
|
||||
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 previous GPU changes, and memory and ARM optimizations we’ll mention next are also part of the Android builds.
|
||||
These changes have boosted the performance by 30-70% in the latest versions, for example, and none were Android specific.
|
||||
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.](https://github.com/yuzu-emu/yuzu-android/releases/)
|
||||
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.
|
||||
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
|
||||
|
||||
|
|
@ -438,16 +437,16 @@ We have a big mistake to correct here. We said only Intel offered such instructi
|
|||
|
||||
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 doing his usual black magic, [Morph](https://github.com/Morph1984) implemented support for these instructions, providing the same benefits Intel users got to previously enjoy alone, namely performance and battery life improvements for power-limited products (laptops, handhelds) or CPUs with few core counts.
|
||||
By performing his usual black magic, [Morph](https://github.com/Morph1984) 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 {{< gh-hovercard "10935" "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.
|
||||
Since AMD CPUs running Windows can now {{< gh-hovercard "10935" "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 got a 10-16% reduction, which translates with this particular CPU model to around a 10W reduction.
|
||||
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!”
|
||||
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.
|
||||
|
|
@ -486,14 +485,14 @@ Thank you!
|
|||
|
||||
## Input improvements
|
||||
|
||||
The work on making those fancy plastics with Near-Field Communication (NFC) behave like on the Switch continues.
|
||||
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](https://yuzu-emu.org/entry/yuzu-progress-report-may-2023/#input-and-amiibo-improvements), 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.
|
||||
{{< gh-hovercard "10623" "With this implementation," >}} yuzu now can do the same with Joy-Cons and Pro Controllers.
|
||||
The backups will be stored in `%appdata%/amiibo/backup`.
|
||||
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 {{< gh-hovercard "10795" "adding their size as a valid input." >}}
|
||||
|
||||
|
|
@ -540,7 +539,7 @@ Thanks!
|
|||
|
||||
Yes, there’s more progress by byte[] in fixing the current file system implementation while we wait for `Project Gaia`.
|
||||
|
||||
The [previously reported](https://yuzu-emu.org/entry/yuzu-progress-report-may-2023/#project-gaia-lite) “algorithmic complexity issue” when loading mods was working like a charm on Linux, but Windows always has special needs.
|
||||
The [previously reported](https://yuzu-emu.org/entry/yuzu-progress-report-may-2023/#project-gaia-lite) “algorithmic complexity issue” when loading mods was working like a charm on Linux, but Windows always has to be difficult.
|
||||
A {{< gh-hovercard "10588" "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 {{< gh-hovercard "10718" "increasing the size of the buffer" >}} when copying files can more than triple the installation speed of updates and DLCs.
|
||||
|
|
@ -552,7 +551,7 @@ Of course, byte[] wasn’t happy with this, so by adding a file [LRU](https://en
|
|||
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…
|
||||
{{< gh-hovercard "10806" "A couple of optimizations," >}} and Windows users get to properly benefit too.
|
||||
{{< gh-hovercard "10806" "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 {{< gh-hovercard "10594" "fixing" >}} this oversight, byte[] further reduced game load times with mods.
|
||||
|
|
@ -589,7 +588,7 @@ Enter newcomer [keve1227](https://github.com/keve1227) who coded in the {{< gh-h
|
|||
Thanks!
|
||||
|
||||
{{< single-title-imgs
|
||||
"Gotta find’em all"
|
||||
"Gotta find ’em all"
|
||||
"./langbug.png"
|
||||
"./langfix.png"
|
||||
>}}
|
||||
|
|
@ -610,14 +609,14 @@ For some reason, Windows uses around 1-2 GB of VRAM only for rendering the deskt
|
|||
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 do perfectly fine for this purpose.
|
||||
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.
|
||||
|
||||
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 on display settings:
|
||||
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:
|
||||
|
||||
{{< single-title-imgs
|
||||
"On desktop PCs, Windows 10 fails here by not letting you select which card is which"
|
||||
|
|
@ -643,17 +642,17 @@ But hey, a free way to get a 4GB GPU to run `The Legend of Zelda: Tears of the K
|
|||
|
||||
### NVIDIA, no sign of progress
|
||||
|
||||
The new (at the time of writing) driver release that adds support for the RTX 4060, 536.40, hasn’t introduced any regression for yuzu.
|
||||
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 on 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.
|
||||
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.
|
||||
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](https://github.com/goldenx86) {{< gh-hovercard "10946" "blocked the affected bit" >}} while we monitor if future AMD driver releases manage to solve this problem.
|
||||
|
||||
{{< single-title-imgs-compare
|
||||
|
|
@ -672,10 +671,10 @@ We know it’s not fun having to switch to OpenGL to be able to play some games,
|
|||
|
||||
### Intel
|
||||
|
||||
Intel got its fair share of fixes this month too.
|
||||
First of all, as promised last month, byte[] added a translation for FP64 use in shaders, to turn uses into FP32.
|
||||
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 {{< gh-hovercard "10693" "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` when starting a new game.
|
||||
With this {{< gh-hovercard "10693" "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.
|
||||
|
|
@ -703,13 +702,13 @@ Hopefully future Intel products offer better FP16, higher performance, longer dr
|
|||
|
||||
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 got to learn about the depressing state of its GPU drivers…
|
||||
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.
|
||||
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!
|
||||
|
||||
|
|
@ -722,7 +721,7 @@ We can’t work on fixing regressions on a driver that is a work in progress; th
|
|||
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 in 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.
|
||||
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.
|
||||
|
|
|
|||
Loading…
Reference in a new issue