Yuzu Nintendo Switch emulator details latest features in September progress report
Are you curious about how one of the two major Nintendo Switch emulators is doing? Lucky day for you then, as the development team behind Yuzu has put out their latest progress report. Published this week, it details all the new features and improvements made to the emulator throughout September. Many hardware specific problems were ironed out, and if you were prone to crashes, then this update might fix performance for you. You can check out the full changelog below.
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_KHRpresentation 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.
Source
] 