

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. 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. When the Vulkan memory allocator was under pressure, causing low VRAM GPUs to crash when trying to actually use a recycled allocation. While investigating very low VRAM devices, byte found that yuzu used incompatible memory property flags 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. Not pictured, GTX 1650 4GB, GTX 1660 SUPER 6GB, and RTX 3060 Ti 8GB What if this hypothetical game made use of dozens and dozens of huge ASTC textures? 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.īut 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?

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. (The Legend of Zelda: Tears of the Kingdom)Īs 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.
