自从上次Buffer Cache Rewrite之后，最近很长一段时间yuzu都没有什么太多有意义的更新，所以我没有怎么关注更新进度；不过这两天去官方翻帖子，发现这个月初的更新还是有不错的性能提升的（虽然也带来了更多的新图像BUG），所以今天把翻译补一下。


新功能发布-快速内存存取
作者：CaptV0rt3x 发布日期：2021年6月8日
嘿，各位柚子粉们好！虽然你们都在急切地等待着Project Hades——我们的着色器反编译器重写的发布，但是我们现在带来的这个小惊喜想必也能吸引你足够的关注。向您介绍——yuzu不断更新的feature清单里的新成员——Fastmem（Fast Memory Access，快速内存存取）！
这一功能已加入最新的yuzu模拟器EA版本（版本号1759及以上），我们也将很快将其加入主线版本的模拟器。与以前一样，请您在这些版本下对各个游戏进行测试，如果遇到任何问题，BUG，或者崩溃，请通过Discord Patreon与我们联系。
注意：此功能默认开启。

什么是Fastmem？
Fastmem或者说Fast Memory Access，快速内存存取，对于模拟器开发者和模拟器爱好者来说是一项非常有名的功能。海豚模拟器、Citra安卓版等等，都已经应用了这项功能。
所有的现代操作系统，都存在着“虚拟内存”这一概念，其中，可寻址内存（addressablememory）——来自正在运行的进程——是一个只有这个进程才“知道”的内存地址空间；例如，你电脑上的Discord，你Switch上的马里奥奥德赛。当游戏正在运行时，这些地址由Switch的MMU（Memory Management Unit，内存管理单元）转换为Switch的RAM里的物理地址。

MMU示意图 (By Mdjango,Andrew S. Tanenbaum)
在yuzu中，我们会为正在运行的进程模拟Switch的虚拟地址空间。但这就意味着，每次游戏尝试进行内存读/写时，我们都需要解码Switch的虚拟地址到底映射到了我们模拟的Switch内存（也就是分配给yuzu程序的你电脑的RAM）的哪个位置上，而这一过程在游戏的每一帧里都会进行数百万次。考虑到游戏的内存读/写量，这增加了非常大的开销。
而Fastmem的原理是，将正在模拟的Switch游戏的可寻址内存，映射到主机（Windows或者是Linux）上的偏移地址。偏移量是一个常量。

技术原理-如何实现？
在Switch上，我们有4GB的内存。硬件所支持的虚拟内存的大小是48bit（与x64是一致的）；不过，Switch内核实际将其限制到了39bit，以节省内存用于储存页表。因此最终可用的虚拟地址空间是512GB（2的39次方）。（页表：用于存储虚拟地址和物理地址之间映射的数据结构。）
为了模拟这一虚拟地址空间，我们分配了一个极其巨大的页表，这一页表里包含了Switch虚拟内存区域里，所有可寻址内存页的偏移量。仅这张页表本身就有1GB大小！每当游戏想要访问内存是，我们就得先查这张表，因此会产生大约10条x64 CPU指令，造成两倍的内存延迟——因为得先读取表里的值，然后才能再读取正确的内存位置。
而Fastmem，则使用主机（host）的MMU来重建相同的39bit的虚拟内存区域。幸好，任天堂把内存限制到了39bit——我们不可能给它分配48bit，因为主机自己的整个虚拟地址空间本身就只有这么大！（译者注：那还得是Linux，因为64位Windows实际限制到了44bit，也就是8TB，Linux才能使用x64 CPU允许的完整48bit，256TB）
这将访问内存的工作量减少到3+1条x64CPU指令，内存延迟也减少回1倍。其中，3条指令来检查指针是否小于39bit，1条指令来加载内存——我们需要通过这个检查来确保越界的内存访问不会返回任何物理地址。

我们面临的挑战
实现Fastmem，需要在我们的JIT重编译器——Dynarmic上完成两个主要任务：
第一：Dynarmic对A64Fastmem的支持、
Dynarmic很早以前就支持A32 Fastmem了（参见Citra安卓版）。A64 Fastmem 的支持则是最初在一年前由MerryMage和vdwjeremy开发的，但从未merge到master上。
degasus与MerryMage合作，进行了整理，并将这些更改merge到了master上，yuzu才可以从中获益。
第二：生成与Switch上一致的512GB的虚拟地址空间
degasus去年证明了，这在Linux上很容易实现，因为POSIX mmap调用提供了与Horizon OS非常相似的功能。但对于Windows而言，这是一个巨大的挑战，因为Windows的虚拟内存API缺少了一些功能。此外，虽然Windows的页表是4K对齐的，但Windows的内存管理因为过时的原因，还是64K对齐的。

解决方案
最终，微软也意识到了自己的问题，并且经常为自己的虚拟内存API发布更新。随着Win10 1803的发布，他们新的API支持新的“占位符”内存，因而不再受到之前存在的限制的影响。
感谢Breadfish64，在他们的Gameboy模拟器中使用了这个新的API，向我们展示了在Windows上实现对Fastmem的支持是可行的。不过不幸的是，这使得只有在Win10 1803或更高版本上，这一功能才可实现。
由于我们很久以前就已经实现了我们全新的Fastmem的基本需求，因此我们的开发人员能够很快就完成剩下的工作。bunnei实现了yuzu急需的内核修改，degasus整理了用于Linux的原始概念验证代码，而Rodrigo实现了Windows的Fastmem支持。Blinkhawk 提供了宝贵的意见，并协调了这些工作的进行，从而使得这一功能得以发布。

结果
意外之喜的是，由于这些改进，游戏的启动和加载时间都得到了改善。感谢开发者Rodrigo，现在普通GPU精度的设置，不会再在大乱斗的角色选择界面上产生数都数不清的错误了，而且性能也从10-20FPS，提升到了60的满帧率。


任天堂明星大乱斗 特别版

我们根据自己的推荐硬件规格，准备了一台PC，来对所有游戏进行基准测试。在本次测试中，我们在一些游戏性能需求最苛刻的区域，观察到了15%到60%之间的性能提升。请注意，对于下图中*标记的游戏，我们将处理器限制到了2.4Ghz，从而降低这些游戏的帧率，突出其性能上的提升。
（译者注：这次总算是搭了台大众化点的测试机，不像以前测试老是用10700k+3070）
点击查看大图
注：标记*的游戏是在2.4Ghz下测试的


（译者注：这位神仙把图里的宫门市Wyndon打成了Whydon，搞得我抠了半天脑壳）
（译者注2：每次更新展示性能必有路易吉鬼屋3，然而每次更新之后打开游戏必定发现还是没法玩；游戏正常启动全靠MOD，部分区域帧率低下，显示错误一堆，博物馆不显示地板，下水道卡得只有十来帧；也不知道为什么这个伴随yuzu一路走来的游戏，作为yuzu的主打游戏之一更了这么久，同为主打的其他游戏都不知道能完美通关多久了，鬼屋3还是现在这个鬼样子…）

以上就是目前的全部内容了，下次更新Project Hades的消息时我们再见！玩得开心！
=========分割线=========
这个帖子内容就是这些了，10号还发了一篇每月一篇的5月进度报告，没有什么有意义的内容，就不翻了；有人说yuzu一点鸡毛蒜皮就刷版本号，每个月进度报告里也确实体现了一点——一般就是零零碎碎几个游戏的小问题修复，还有内核一些没有重要影响的修改；但是，模拟器整体的进步确实是由这样的小打小闹一点点积累起来，最后才能逐步接近完美的，指望每个月都搞大动作是不切实际的。不过，5月进度报告里甚至把程序窗口标题栏多了个小点的删除过程放上去了……这就有点搞了……

除了鸡毛蒜皮之外，这半年yuzu还是进行了两次实打实的更新，一次是1月16日的BCR，缓冲区缓存重写（我也翻译了，精品区可看），另一次就是这次的Fastmem。我实测了一下，确实有性能提升：1080P下，塞尔达荒野之息的帧率上升了15%以上，原来稳定45帧的复杂区域现在在52帧，原来在50帧的区域现在在59帧。现在在我的电脑上，除了跑进密集的草地里和其他复杂情况之外，基本能稳定60帧左右，也就是说算是可以畅玩了。
点击查看大图
1757版本：

1830版本：

当然，代价是有了新的图像BUG，远处的云雾，例如上面两张图里火山上的烟云，会不停闪烁。希望以后的更新能尽快修复吧。
其他游戏应该也有进步，不过我没有测试，吧友们有体验的可以来分享一下

除了BCR和Fastmem这两次大更新之外，接下来会有一次Project Hades 的大更新。Hades这个项目已经念叨了很久了，如果你去yuzu官网翻更新帖子，你会发现从去年下半年开始就不断地出现这个项目的名字。连开发组自己都说，关于Project Hades的消息从information变成了teasing...
现在所有关注者对这个项目的期待都空前的高

从他们发的图来看，似乎这个项目能解决很多游戏的问题，特别是路易吉鬼屋3里的地板…
让我们还是继续期待一下吧

yuzu最新版本（1835）下载地址：
github.com/pineappleEA/pineapple-src/releases/download/EA-1835/Windows-Yuzu-EA-1835.7z

唉 什么时候模拟玩怪物猎人rise呢(A卡)

大佬 软件下载了没KEy 跟固件 能提供吗？谢谢 用旧版大地覆盖可以的吗？

厉害👍