前言

针对ChatGPT 3.5,Claude in slack,Claude+的翻译能力进行测试。

翻译素材:YUZU模拟器开发团队的Blog文章- Progress Report March 2023

ChatGPT / Claude 共用提示词。

中文提示词:

记住,你是一名逆向工程师,你精通C++和Python语言,你非常了解模拟器的架构,同时你也是Yuzu Emulator Team的一员,而yuzu是Citra的创建者为任天堂Switch开发的一个实验性开源模拟器。它是用C++编写的,考虑到了可移植性,并积极维护了针对Windows和Linux的构建。

但是,你现在成为了一名翻译,负责英译中的翻译工作。接下来,我会给你发送Yuzu Emulator Team的blog文章的一些段落,我需要你把它翻译成简体中文。

你不需要表现出对文章有多么深层次的理解,你只需要把它原本的意思翻译下来。

英文提示词:

Remember, you are a reverse engineer who is proficient in C++and Python languages. You have a good understanding of simulator architecture and are also a member of the Yuzu Simulator Team. Yuzu is an experimental open-source simulator developed by Citra's creator for Nintendo Switch. It is written in C++, considering portability and actively maintaining builds for Windows and Linux.
However, you have now become a translator responsible for translating from English to Chinese. Next, I will send you some paragraphs from the Yuzu Simulator Team blog article, and I need you to translate it into Simplified Chinese.
You don't need to show a deep understanding of the article, you just need to translate its original meaning.

经过对比,发现使用英文提示词的翻译能力和中文提示词也有点差异,使用中文会更好一点。也可能是我提示词太拉了😐 …

另外Claude in Slack的翻译能力并不稳定,时好时坏,好的比GPT好,坏的比GPT坏。比如Claude的离谱翻译:Kirby and the Forgotten Land 被翻译成忘记之地克比复活忘记达人:Kirby,ChatGPT3.5则会好上一些。

此外,Claude对MD语法输出的错误率也较高。POE上的Claude+Claude-instantClaude in Slack 比 并没多大优势(翻译上)。


以下为2023.7.21的测试结果,时隔两个月ChatGPT的翻译能力有极大的提升(可能是多了temperature和top_p参数)。

Bard 和 Claude-2-100k 都半斤八两就不测了。

ChatGPT 3.5-turbo-16K

大家好,Yuzu模拟器团队的成员们!我们一如既往地努力工作,今年三月我们在性能、图形、音频、CPU精度、输入等方面做出了不少改进!

让CPU不再嗡嗡作响

本月最重要的改变之一是CPU精度的一系列提升。为了更好地理解这一点,让我们回到过去。

在七月的时候,我们解释了CoreTiming在其当前形式下是如何使用主机定时器的。一个名为HostTiming的线程用于处理HLE(高级传真输入输出模拟)事件,比如输入和音频。然而,其中一些事件,比如音频,需要更高精度的计时器才能使游戏按照预期的方式运行,而Windows通常只允许1毫秒的精度,因为操作系统的事件循环以1000Hz运行。

这是不够的。然而,运行Linux、BSD和macOS的设备并没有面临这个限制,可以实现微秒级别的精度。

如果一个游戏想要以16.67毫秒(60FPS)的帧时间运行,你可以在2/3的时间里等待17毫秒,在剩下的1/3时间里等待16毫秒,但在过去这种方法已经被证明对音频的准确性非常糟糕。而在Windows上,另一种选择是等待16毫秒,然后进行0.67毫秒的繁忙等待。在这0.67毫秒的时间里,CPU线程没有做任何事情,只是消耗功耗而没有实际工作。

这就是取消对Windows 7和Windows 8/8.1的支持所带来的好处。Windows 10 SDK提供了新的未记录函数,NtSetTimerResolution和NtDelayExecution,可以将计时器精度提高到0.5毫秒。这使得yuzu可以等待16.5毫秒,然后仅自旋0.17毫秒,这比以前的默认方法要短四倍。

通过实现这些新函数,Morph减少了CPU在自旋锁中的时间,从而降低了对于像《星之卡比:被遗忘的乐园》(Kirby and the Forgotten Land)和《Super Smash Bros. Ultimate》等对定时要求较高的游戏的CPU使用率。这些新增的可用资源意味着核心数较低的CPU(如四核心)和功耗有限的系统(如笔记本电脑和便携式设备)的更好性能。通过这一改变,我们根据限制因素的不同,测得的CPU使用率或功耗消耗可以降低高达24%。

左

右

左侧:旧的1毫秒精度;右侧:当前的0.5毫秒精度。这个结果来自你们作家的笔记本电脑,上面运行着单语言版本的Windows,所以不要在意西班牙语。请注意,两个结果之间的CPU使用率有所差异。

如果你能在相同的功耗范围内执行更多任务,就可以提高性能而不牺牲电池寿命。或者,对于模拟器来说,更常见的情况是,如果你的上限是固定帧率,你可以降低温度。

这就是为什么笔记本电脑中的”lap”(膝盖)是个谎言,要注意处理器的温度(《异度神剑3》)

用户报告称,由于改进的计时器精度,游戏的音频卡顿现象减少了。

Windows 10 SDK提供的另一个很好的工具是允许我们将yuzu设置为高优先级进程,向Windows调度程序暗示,如果有更高性能的核心可用,它们应该优先使用。这进一步改善了当前Ryzen CPU的性能,通过建议使用CCX的最佳核心,以及对于Intel第12代及更高版本,通过优先选择P核心(”性能核心”,普通核心)。

强烈建议及时更新芯片组驱动程序,以充分发挥硬件的优势。

如果CPU以更高效的方式运行,我们如何进一步突破呢?嗯,Morph想到的下一步是改进CPU自身计时的方式!

在使用x86架构的现代CPU上,不变定时器是通过RDTSC指令获取的。RDTSC的问题是…在较长时间内它不准确,特别是在多核处理器上。

RDTSC提供的最佳估计值与实际情况之间的微小差异会导致《超级大乱斗终极版》等游戏中的时间漂移。你可能会注意到这个问题表现为不准确的比赛时间。我们测得的受影响最严重的CPU架构是Intel第12代(也是在七月的时候),每分钟可能会慢一个秒。

Morph解决这个问题的方法是创建一个额外的线程,其任务是在10秒内对TSC进行两次测量,然后取这两次测量的差值,并应用于了解在这前10秒内实际经过了多少个时钟周期。然后,将时钟周期数除以10,就可以得到主机RDTSC计时器的精确频率。

幸好我们不必使用旧式秒表来做这个(《超级大乱斗终极版》)。

结果在Ryzen和Intel第11代及更早的系统上几乎完美,而在第12代Alder Lake系统上几乎完美。在CPU内部同时使用完全不同的核心来计时对于这个特定应用程序来说并不理想。我们无法克服Intel设计的混合非对称性特性,但我们成功将每分钟的时间漂移从一秒减少到大约五分钟一秒。

“Morph说:“好吧,这很不错”,但你如何进一步深入呢?唯一剩下的选择就是转向汇编语言。

目前,这种优化仅适用于第12代及更高版本的Intel CPU;AMD尚未添加对其的支持。我们谈论的是TPAUSE(CPUID名称WAITPKG),这是来自蓝队的一条新指令,允许CPU进入较低的功耗状态,并在经过精确的时间后进入空闲状态。

需要进行一些测试来确定等待周期的正确循环数;错误的值会在一个极端上降低精度太多,或者在另一个极端上没有任何好处。在Morph的测试中,100000个循环是一个神奇的数字,除了之前的好处外,还将CPU使用率/功耗降低了高达20%。

如果只有Intel的GPU驱动程序能够正常工作,那么搭载Xe的笔记本电脑/便携式设备现在将成为非常适用于yuzu游戏的机器…哦,好吧,使用来自NVIDIA或AMD的实际可用GPU驱动程序的第12/13代用户将从所有这些工作中获得巨大的好处。

图形变化

够了,关于CPU的改进就说这么多。那么图形方面呢?我们有很多要谈论的。

用户报告称在《牧场物语:一个奇妙的人生》(STORY OF SEASONS: A Wonderful Life)中出现了有趣的颜色条纹。Maide深入研究了这个问题,并确定了S8_UINT颜色格式(如D32_FLOAT_S8_UINT和S8_UINT_D24_UNORM)是问题的罪魁祸首。通过一些试错和来自Skyline模拟器的大力帮助,Maide成功解决了这些问题,提供了准确的颜色渲染而不破坏其他游戏。

现在,你可以尽情享受这款农场模拟器的丰富色彩,而不必担心颜色条纹问题。这不是很有趣吗?(《牧场物语:一个奇妙的人生》)

epicboy再次以他的忍者式更新出现。这次他给仍然繁荣的OpenGL阵营带来了一些关爱,带来了我们在上一份报告中讨论过的AccelerateDMA的所有好处。

这意味着OpenGL用户,尤其是那些拥有Fermi和Kepler GPU的用户,可以享受到这个伪Y.F.C. 2变更带来的速度提升,使得《超级大金刚Prime重制版》等游戏运行得更快。不再需要等待Samus装填她的臂炮。

我们强烈建议那些没有良好Vulkan支持的旧硬件用户升级到更新的设备,因为对OpenGL的支持即将接近生命周期结束。话虽如此,由于epicboy的贡献,那些无法升级的用户在使用旧但经典的OpenGL API时不会遭受可怕的性能问题。

但这还不是全部,epicboy还为GL_SYNC_STATUS添加了一项优化,稍微提升了性能。你的作家在《塞尔达传说:荒野之息》中观察到了3-5%的性能提升,这是少数几个在NVIDIA硬件上以OpenGL运行更快的游戏之一,如果你忽略着色器卡顿的话。

在游戏中最繁重的区域之一,帧率从54提升到57,OpenGL仍然有生命力!至少目前是这样的…(《塞尔达传说:荒野之息》)

bylaws再次挺身而出,指出我们旧的Vulkan调度器实现在去年十月份有一些退步,当byte[]致力于使自制应用程序与Vulkan兼容时。

这意味着在开始渲染之前,游戏和自制应用程序必须等待帧在屏幕上显示,这在某些情况下是最糟糕的反馈循环示例。

通过在后台等待队列被清空而无需等待帧被呈现,byte[]修复了这个退步。感谢bylaws!

还记得我们上个月谈论过的那个可爱的游戏吗?适合所有年龄段的游戏!完全可以和家人一起玩的安全游戏。

vonchenplus决定使其可玩,这样世界各地的玩家都可以享受Moero Crystal H的精彩游戏玩法,通过修复yuzu处理内联索引和绘制纹理命令的一些错误。

最近一次Steam Deck的系统更新导致许多游戏的图形出现问题。罪魁祸首是什么呢?与VK_EXT_extended_dynamic_state3有关的某些问题,这是一种Vulkan扩展,有助于减少着色器构建的卡顿。

yuzu对NVIDIA驱动程序行为的期望与Deck上最新Mesa实现的差异相结合,导致了你接下来看到的情况:

看起来好像有人在屏幕上溅了点颜料(《塞尔达传说:荒野之息》)

byte[]暂时禁用了导致问题的功能,但我们将来会重新考虑是否再次启用,因为很可能Mesa已经在他们的端解决了这些问题。

以下是针对《异度神剑》粉丝的一些重要修复,Maide花了很多时间来处理这些修复。

由于采样器中sRGB边框颜色转换的问题,游戏内的着色器出现了问题。这是一个将颜色从一个颜色空间转换到另一个颜色空间的过程。这会导致一些受影响的着色器上的某些检查失败,从而错误地丢弃了作为阴影的错误像素。

我们需要更多信息来完全理解这个问题,但目前,在sRGB采样器上忽略颜色空间转换可以实现硬件精确渲染。

雷克斯知道他的未来会是什么样的,眨眨眼(《异度神剑2》)

影响《异度神剑》三部曲(至少是《终极版》和《2》)的另一个长期存在的问题自从传说中的纹理缓存重写以来一直困扰着yuzu。这个问题是随时可能发生的随机“彩虹模式”,或者在《异度神剑2》的特定后期剧情中发生,我不想给新玩家剧透。如果你在yuzu中玩过,你就知道是哪个场景。它会让你想知道自己是否置身于狂喜之城(Rapture)。

在(云)海的彼方!(《异度神剑2》)

另一个观察到的问题是过度的照明使整个场景难以辨认(特别是在晚上使用HDR显示器时,这不是一个愉快的突然闪光弹)。

我的眼睛!(《异度神剑2》)

Maide发现问题是由于在环境光照立方图中用陈旧的主机数据替换新鲜的客户端数据所导致的。解决方案是只复制被标记为GPU修改的数据,遵循缓存重写的行为。

这不是2009年了,我们不需要这么多的泛光效果,非常感谢(《异度神剑:最终版》)

通过这些改进,只剩下少数影响《异度神剑》系列的图形问题,使得在yuzu上从头到尾享受游戏成为一个绝佳选择。然后你可以和作者一起辩论哪个女王是最好的。

由于这个问题只在第一次渲染剧情时发生,我会使用错误报告的截图来作弊,咬我吧(《异度神剑2》)

新成员rschlaikjer,希望我发音没错,一直在深入研究纹理缓存,试图找出为什么像《月姬-蓝色碎片之月-》这样一个简单的视觉小说在切换场景时会出现卡顿。也许是因为游戏对模拟器来说太过情感化了。

罪魁祸首是在捕获GPU页表时缺少引用运算符,导致该表每秒被重复复制数千次。这会让任何人都卡顿,更不用说模拟器了。将捕获转换为引用解决了这个问题,并且可能还能修复其他游戏中类似的问题。

我们很高兴rschlaikjer在问题失控之前发现了这个bug。我们不想像那把椅子一样结束。

界面改动

有些问题如此难以捉摸,以至于它们在多年间都未被注意到。有些问题如此复杂,需要对所有相关层面有深入的理解才能找到正确的解决方案。这些问题让许多开发者感到沮丧,他们放弃了,希望其他人能有更好的运气。

而有些问题则非常愚蠢。比如当游戏因为默认用户配置文件损坏而崩溃时。

german77找到了一个简单的解决方案,可以修复数十个游戏的崩溃问题:将默认配置文件图片的分辨率设置为真实的32x32,而不是0x0。就是这样。

在继续改进用户界面方面,german77还将最后一个音频设置“在后台时静音音频”移到了音频部分,这是它应该所属的地方。不再需要在“常规”中四处寻找此选项了。

这个改进对于用户体验(UX)来说是一个巨大的提升,对我个人来说也是一种巨大的解脱。以前,在使用每个游戏的控制器配置文件时,如果在开始游戏之前忘记更改输入设置,当游戏关闭时,你将失去这些设置,并且下次需要重新设置。

epicboy修复了这个令人讨厌的问题,german77合并了这些改动。非常感谢你们修复这个问题。

german77还在努力改进配置文件选择应用程序。目前的改动只是一个开始,我们将在未来向您更新任何进展。

输入改进

让我们谈谈输入方面,german77继续展现出色的表现。

对于玩《梅特罗德原初重制版》时的鼠标和键盘体验不满意,german77将默认鼠标灵敏度设置为50%,并移除了平滑滤镜,根据梅特罗德的粉丝们提供的宝贵反馈,改进了高DPI游戏鼠标的性能。他还降低了运动阈值,限制了旋转速度,并将所有输入累积直到传递,从而修复了之前实现中的延迟和卡顿问题。

你有没有注意到Samus缺少一个引导指示器?她的装备不能再为此多花一点处理能力吗?(《梅特罗德原初重制版》)

由于这些改变,梅特罗德原初重制版表明它可以成为一款伟大的PC游戏。如果任天堂能让它走出牢笼就好了。

我们经常收到的一个问题是“这个第三方Switch控制器能用吗?”简短的回答是可能,但长的回答则更加复杂。

根据任天堂的API,Joy-Con有两种模式:主动和被动。官方Joy-Con使用主动模式,但一些第三方控制器使用被动模式,通常是因为它们没有正确遵循API并且不支持任何配置命令。它们只能按照默认设置运行,好的或坏的。

这并不意味着被动控制器是无用的。它们仍然可以在Switch上使用。但这确实意味着它们的工作方式不同。主动控制器每15毫秒更新一次状态,而被动控制器只有在发生某些事件,如按下或释放按钮时才会更新。

好吧,事实证明,直到现在yuzu都不支持被动模式!因此,german77的改变让许多第三方控制器用户感到高兴。考虑到有多少非官方控制器存在,这非常方便。

振动问题的战斗还在继续!在进行他的常规研究时,german77发现,如果有多个玩家使用相同类型的控制器,或者如果您使用单个控制器的双Joy-Con设置,您可能会连续向同一控制器发送两个振动命令。这可能很烦人,而且还占用了蓝牙连接的有限带宽。

解决方案很简单:对于每个控制器,只取酷炫振动队列中的最新元素,检查控制器是否能够处理所请求的振动,并忽略其余的元素。

我们都喜欢生活质量的改变,对吧?即使它们不是很引人注目。

让我们谈谈控制器应用程序,它负责在游戏请求时要求玩家选择其输入设置。直到现在,该应用程序是不可跳过的;你必须给出一个有效的答案才能继续游戏。虽然这是可以接受的,但它很麻烦并且不准确。如果玩家无法或不愿确认其输入方式,一些游戏会返回到上一个菜单,而不是陷入无限循环。

你通过了!

german77解决了这个问题,并且在此过程中还解决了一个玩家计数不正确的错误。

german77实现了…等一下,让我先喘口气,SetNpadJoyAssignmentModeSingleWithDestination服务调用。他实现它是希望能够让《动感单车》可玩,但不幸的是还有更多的问题需要解决。

转换话题到Amiibo支持,这个月发生了很多事情。

首先,german77成功编写了正确的CRC,使得yuzu写入的Amiibo数据与Switch兼容,不再有无效的信息。

接下来,如果你在扫描Amiibo时尝试连接一个控制器,它将无法被识别。通过考虑到这一点并初始化或完成控制器,他解决了这个问题。

最后但并非最不重要的是,为了结束Amiibo的传奇,Herman the German Sherman添加了对普通Amiibo文件的支持。一些Amiibo,比如那些以《超级大乱斗特别版》为主题的Amiibo,可以在不需要密钥的情况下进行编辑。现在,yuzu可以正确读取你的Amiibo中的非加密游戏数据了!

音频修复

Maide发现了一个bug,即混响预延迟线的读取方式有问题,导致输出出现问题。通过正确地通过输入而不是输出进行读取来解决这个问题,使得《新超级马里奥兄弟U豪华版》等游戏的音频正常。现在你可以享受没有任何回声的马里奥的声音了。妈妈咪呀!

bylaws一直在深入研究音频同步,改进了代码库,并通过将客户端样本跟踪与主机进行链接,成功避免了停顿。

这个改变导致了一些退步,因为一些游戏对音频调度要求非常敏感。用户在合并后报告了爆裂声,所以bylaws通过在样本计数报告中添加恒定的15毫秒延迟来改善情况。

其他代码改变

《火焰之纹章》的粉丝在游戏中遇到了冻结问题,经过一些调查,Morph发现罪魁祸首是有界线程安全队列,这是由behunin的拉取请求引入的。

队列的工作是将事件从事件生产者(如CPU核心)传递给事件消费者(如GPU线程)。之前的实现方式会不断分配和释放内存,导致周期性的延迟峰值。

解决这个问题的方法是将队列转换为有界队列,这意味着不需要内存分配,因为有固定数量的资源可用。这就是behunin所做的,但新的队列实现似乎存在一些bug。Morph添加了一个简化的实现,修复了影响《火焰之纹章:风花雪月》和《火焰之纹章:战斗》的新游戏冻结问题。

你的作者为GCC构建重新启用了LTO,遵循上次对Windows所做的更改,但只将优化应用于核心和video_core子项目,为Linux用户提供了一个不错的免费性能提升。

硬件部分

AMD 23.3.2及更高版本的驱动程序
有一个坏消息和两个好消息。

积极的一面是,AMD终于在最新的Windows驱动程序发布中添加了对缺失的动态状态扩展的支持,这提高了着色器构建时间,并减少了Radeon GPU上的卡顿,使其与NVIDIA的性能相当。

然而,消极的一面是,这个驱动程序更新也引入了一个严重的退步:

这可能会影响你的整个桌面(《梅特罗德原初重制版》)

一些游戏,如《梅特罗德原初重制版》和《宝可梦传说:阿尔宙斯》,会触发似乎是越界崩溃的情况,导致桌面损坏和驱动程序崩溃。我们建议用户目前保持在23.3.1或更早的驱动版本上。一些旧的Radeon显卡也可能会受益于使用23.2.2版本。

我们向AMD报告了这个问题,他们迅速确认了问题,重现了问题,并告诉我们他们正在修复。

这就是你应该做的客户支持。

说到这个……

替代Intel的工作
在为《塞尔达传说:荒野之息》进行一个关键的渲染修复的测试时,我们将在下个月讨论这个问题,Morph进行了一些功能测试,以调查是什么导致了Intel Windows驱动程序的运行如此糟糕。

他的发现既是预期的,也是令人失望的。大约95%的崩溃的主要原因是驱动程序中有一个有问题的计算着色器阶段。像我们以前为旧的Intel硬件所做的那样禁用计算着色器可以使大多数游戏运行,但并非所有游戏都可以。我们仍然不知道在《异度神剑3》中打开菜单时崩溃的原因。

我们现在正在努力找出是什么触发了计算着色器导致驱动程序崩溃的问题,但这也带来了一个两难的境地。我们应该自己修复这个问题,使游戏渲染变得更糟,并放过Intel,还是应该让它保持损坏,让他们必须正确修复它?

在调查仍在进行的同时,解决方案是使用可靠的Linux,或者避免购买仅依赖于Intel GPU的硬件。叹气。

未来的项目

我们甚至还没有过完四月的一半,我已经对接下来的进展报告感到非常兴奋。开发人员们正努力工作,他们不会停下来。

Maide正在为《异度神剑》系列进行更多改进,比如修复《异度神剑2》中的云层闪烁问题,修复《异度神剑3》中的粒子效果问题,以及影响整个系列和其他一些游戏的纹理闪烁问题。然而,这些修复会带来性能上的代价,所以他需要其他GPU开发人员的帮助来进行优化。也许Blinkhawk可以帮个忙?

任天堂发布了Vulkan扩展的至高无上,VK_EXT_shader_object。这个扩展承诺大大减少构建着色器所需的工作量,正如其依赖关系所示,需要支持所有先前的动态状态扩展。

很可能任天堂打算在他们的内部模拟器中使用它,也许是为了“向后兼容性”。不管怎样,我们还有很多工作要做,以支持这个扩展。

但是先别谈这个。让我们来谈谈一些正在进行中的令人兴奋的项目吧。

长笛声加强了

关于Gaia项目:它仍在开发中。

哦,还有Lime项目处于发布候选状态,正在进行激烈的内部测试。

就这些了!感谢您一直关注这份进展报告。

感谢Bing Chat提供的糟糕笑话。

ChatGPT 4

嗨,yuz-ers们!我们一如既往地努力工作,今年三月我们在性能、图形、音频、CPU精度、输入等多个方面都有所提升!

让CPU的运行速度与BRRRR相反

本月最大的变化之一是CPU精度的一系列改进。这需要一些回溯,所以让我们稍微回顾一下。

7月,我们解释了CoreTiming如何以其当前形式运行,使用主机计时器。一个名为HostTiming的线程用于处理HLE事件,例如输入和音频。然而,其中一些事件,如音频,需要高级别的计时器精度才能按照游戏期望的方式运行,这超过了Windows通常允许的范围。

默认情况下,Windows只允许1ms的精度,因为操作系统的事件循环以1000Hz运行。这是不够的。然而,运行Linux、BSD和MacOS的设备没有这个限制,可以达到μs(微秒)级别的精度。

如果一个游戏想要以16.67ms(60 FPS)的帧时间运行,你可以选择三分之二的时间等待17ms,剩下的三分之一时间等待16ms,但这种方法已经被证明对音频精度来说是非常糟糕的。另一种选择,也是Windows旧有的方法,是等待16ms,然后忙等0.67ms。在这0.67ms的时间里,CPU线程并没有做任何事情,只是消耗电力而并未真正工作。

这里就体现出了移除对Windows 7和8/8.1支持的好处。Windows 10 SDK有新的未文档化的函数,NtSetTimerResolutionNtDelayExecution,它们允许将计时器的精度提高到0.5ms。这使得yuzu可以等待16.5ms,只需旋转剩下的0.17ms,这比之前的默认方法短了四倍。

通过实现这些新函数Morph减少了CPU在自旋锁中的时间,从而降低了对时间密集型游戏如《Kirby Forgor 💀》……《Kirby and the Forgotten Land》和《Super Smash Bros. Ultimate》的CPU使用率。新的空闲资源意味着对于四核等低核心计数的CPU,以及对于电力预算有限的系统如笔记本电脑和手持设备,性能会有所提升。通过这种改变,我们测量到CPU使用率或电力消耗降低了高达24%,具体取决于限制因素。

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

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

左图:旧的1ms精度;右图:当前的0.5ms精度。这个结果来自于你的作者的笔记本电脑,它运行的是单一语言的Windows安装,所以不用在意上面的西班牙文。注意,这两个结果在CPU使用上是有差异的。

如果你能在相同的电力范围内执行更多的任务,那么你可以在不牺牲电池寿命的情况下提高性能。或者,对于模拟器来说更常见的情况是,如果你的上限是固定的帧率,你可以降低温度。

This is why the lap in laptop is a lie, mind the package temperature (Xenoblade Chronicles 3)

This is why the lap in laptop is a lie, mind the package temperature (Xenoblade Chronicles 3)

这就是为什么笔记本电脑的”lap”是个谎言,注意到包装温度(《异度之刃 3》)。

用户报告说,由于计时器精度的提高,游戏的音频卡顿减少了。

Windows 10 SDK增加的另一个好工具是允许我们将yuzu设置为HighQoS进程,向Windows调度器暗示,如果有更高性能的核心可用,它们应该优先使用。这进一步提高了当前Ryzen CPU的性能,通过建议使用CCX的最佳核心,对于Intel 12代及更新的版本,通过优先考虑P-cores(“性能核心”,普通核心)。

强烈建议保持芯片组驱动程序的更新,以充分利用你的硬件。

如果CPU以更高效的方式运行,我们如何进一步提高呢?好吧,Morph认为下一步是改进CPU计时的方式!

在使用x86架构的现代CPU上,不变的计时器是通过RDTSC指令获取的。RDTSC的问题是……在较长的时间段内,它并不准确。在多核处理器上,它无法做到准确。

RDTSC提供的最佳估计和实际现实之间的微小差异会导致像《Super Smash Bros. Ultimate》这样的游戏出现时间漂移。你可能会注意到这个问题表现为比赛时间的不准确。我们测量的受影响最大的CPU架构Intel 12代(也是在7月份),每分钟都会有一秒的误差。

Morph对这个问题的解决方案是生成一个额外的线程,其任务是在10秒内对TSC进行两次测量,然后取这个差值,应用它来知道在这前10秒内实际上过去了多少个tick。如果你然后将tick的数量除以10,你就得到了主机RDTSC计时器运行的确切频率。Good thing we don’t have to use old stopwatches for this (Super Smash Bros. Ultimate)

Good thing we don’t have to use old stopwatches for this (Super Smash Bros. Ultimate)

幸好我们不用为此使用旧的秒表(《Super Smash Bros. Ultimate》)

结果是在Ryzen和Intel 11代及更早的系统上几乎完美的计时,以及在12代Alder Lake系统上几乎完美的计时。在CPU内部同时有完全不同的核心进行时间计数对于这个特定的应用来说并不美观。我们无法打败Intel设计的混合非对称性质,但我们设法将漂移从每分钟一秒减少到大约每五分钟一秒。

“好吧,这很不错”Morph说,但你怎么能深入到更深的层次呢?剩下的唯一选择就是转向汇编

目前,这种优化只适用于12代及更新的Intel CPU;AMD还没有添加对它的支持。我们在谈论TPAUSE(CPUID名称WAITPKG),这是Team Blue的一种新指令,它允许CPU进入低功耗状态并空闲,直到精确的时间过去。

需要进行一些测试来指定等待期的正确周期数;一个错误的值会在一个极端上过多地降低精度,或者在另一个极端上不产生任何好处。在Morph的测试中,100000周期是神奇的数字,它在之前的优势之上,将CPU使用率/功耗降低了高达20%。

如果只有Intel GPU驱动程序能工作,他们的Xe配备的笔记本电脑/手持设备现在将是非常可行的yuzu游戏机……哦,好吧,运行实际工作的NVIDIA或AMD GPU驱动程序的12代/13代用户将从所有这些工作中获益。

图形改变

说够了CPU的改进。那图形呢?好吧,我们有很多要谈论的。

用户报告了在STORY OF SEASONS: A Wonderful Life上有趣的颜色带状。Maide深入研究了这个问题,并在S8_UINT颜色格式中找到了罪魁祸首,如D32_FLOAT_S8_UINTS8_UINT_D24_UNORM。通过一些试验和错误,以及来自伟大的bylaws(来自Skyline模拟器)的大力帮助,Maide设法解决了这些问题,提供了准确的颜色渲染,同时不破坏其他游戏。

img

img

现在你可以享受这个农场模拟器,所有的色彩鲜艳,而不必担心颜色带状。这不是很有趣吗?(STORY OF SEASONS: A Wonderful Life)

epicboy再次以他的忍者更新出击。这次他对仍然活跃的OpenGL团队表示了一些爱,将所有的AccelerateDMA,的好处带来,我们在上一篇报告中讨论过这个主题。

这意味着OpenGL用户,尤其是Fermi和Kepler GPU的用户,可以享受到这种伪造Y.F.C. 2的改变带来的速度提升,使得如Metroid Prime Remastered等游戏运行得更快。不再等待Samus加载她的手臂炮。

我们强烈建议没有良好Vulkan支持的旧硬件用户升级到更新的硬件,因为对OpenGL的支持即将接近生命周期的尾声。尽管如此,感谢epicboy,那些无法升级的用户不会因为使用旧但金的OpenGL API而遭受糟糕的性能。

但这并不是全部,epicboy还为GL_SYNC_STATUS添加了一项优化,稍微提高了性能。你的写作者在The Legend of Zelda: Breath of the Wild中观察到了3-5%的性能提升,这是在NVIDIA硬件上用OpenGL运行的少数几个更快的游戏之一,如果你忽略了着色器的卡顿。

 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)

在游戏中最重的地方,从54帧提升到57帧,OpenGL仍然有生命力!至少现在还有…(《塞尔达传说:荒野之息》)

bylaws再次来救援,指出我们旧的Vulkan调度器实现在去年10月份有一些回归,当时[byte]正在努力让自制应用程序与Vulkan一起工作。

这意味着游戏和自制应用程序必须等待一个帧出现在屏幕上才开始渲染,这在某些情况下是反馈循环最糟糕的一个例子。

通过在后台等待队列被清空,而不必等待帧被呈现,byte[]修复了这个回归。感谢bylaws!

还记得我们在上个月谈过的那个可爱的游戏吗?那个适合所有年龄的游戏!完全可以和你的家人一起玩。

vonchenplus决定让它可以玩,所以weebs全世界的玩家可以享受Moero Crystal H的惊人游戏玩法,通过修复一些yuzu处理内联索引和绘制纹理命令的错误。

 Cultured gaming (Moero Crystal H)

有文化的游戏(Moero Crystal H)

Steam Deck的一个最近的系统更新搞砸了许多游戏的图形。罪魁祸首?与VK_EXT_extended_dynamic_state3有关的一些问题,这是帮助减少着色器构建卡顿的Vulkan扩展之一。

yuzu期待NVIDIA驱动程序的行为,以及Deck上最新的Mesa实现的差异,导致了你接下来看到的情况:

Looks like someone spilled some paint on the screen (The Legend of Zelda: Breath of the Wild)

Looks like someone spilled some paint on the screen (The Legend of Zelda: Breath of the Wild)

Looks like someone spilled some paint on the screen (The Legend of Zelda: Breath of the Wild)

看起来像是有人在屏幕上洒了一些颜色(《塞尔达传说:荒野之息》)

byte[]现在禁用了导致问题的特性,但我们将考虑在未来再次开启它,因为很有可能Mesa已经在他们那边修复了问题

这里有一些对Xenoblade粉丝来说非常重要的修复,Maide花了很多时间在这上面工作。

由于采样器中sRGB边界颜色转换的问题,游戏中的着色器被破坏。这是一个将颜色从一个颜色空间转换到另一个颜色空间的过程。这会导致一些不准确,使得一些检查在受影响的着色器上失败,结果在阴影中丢弃了错误的像素。

我们需要更多的信息来完全理解这个问题,但是现在,忽略在sRGB采样器上的颜色空间转换可以实现硬件精确的渲染。

img

img

雷克斯知道未来对他有什么打算,眨眨眼(异度之刃2)

影响异度之刃三部曲(至少是终极版和2)的另一个长期问题一直困扰着yuzu,自从传奇的纹理缓存重写以来。那就是在游戏过程中随时可能发生的随机“彩虹模式”,或者在异度之刃2中的一个特定的后期剧情中,我不会为新玩家剧透。如果你在yuzu中玩过它,你就知道是哪一个。它让你想知道你是否在狂喜中。

 Somewhere, beyond the (cloud) sea! (Xenoblade Chronicles 2)

在某个地方,超越了(云)海!(异度之刃2)

另一个观察到的问题是过度的照明使整个场景无法阅读(特别是在夜晚使用HDR显示器时,突然的闪光弹并不愉快)。

 My eyes! (Xenoblade Chronicles 2)

我的眼睛!(异度之刃2)

Maide发现这个问题是由于在环境光照立方图中,将新的客户数据替换为陈旧的主机数据所造成的。解决方案是只复制被标记为GPU修改过的数据,遵循缓冲区缓存重写的行为。

img

img

这不是2009年,我们不需要这么多的光晕效果,非常感谢(异度之刃:终极版)

有了这些改变,影响异度之刃编年史的图形问题几乎都解决了,使得它成为一个从头到尾在yuzu上享受的绝佳选择。然后,你可以和你的作者一起讨论哪个女王是最好的。

img

img

由于这个问题只在剧情渲染的第一次出现,我将使用错误报告的图片来作弊,咬我吧(异度之刃2)

新人rschlaikjer,我希望我发音正确,一直在深入研究纹理缓存,试图弄清楚为什么像月姬 -蓝玻璃之月-这样的简单视觉小说在切换场景时会出现卡顿。也许是因为这个游戏对模拟器来说太感人了。

罪魁祸首是在捕获GPU页面表时缺少引用操作符,这导致表被一次又一次地复制,每秒达到数千次。这会让任何人都卡顿,更不用说模拟器了。转换捕获为引用解决了这个问题,也可能修复了其他游戏中的类似问题。

我们很高兴rschlaikjer在这个bug变得无法控制之前发现了它。我们不想像那把椅子那样结束。

用户界面变化

有些问题如此难以捉摸,以至于它们多年来都没有被注意到。有些问题如此复杂,需要对所有涉及的层面有深入的理解才能找到正确的解决方案。这让许多开发者感到沮丧,他们放弃了,希望其他人会有更好的运气。

还有一些问题就是纯粹的愚蠢。比如当一个游戏崩溃是因为默认用户配置文件被损坏。

german77找到了一个简单的修复方法,可以解决几十个游戏的崩溃问题:将默认的配置文件图片设置为真正的32x32分辨率,而不是0x0。就这样。

german77继续改进用户界面,他还将最后的音频设置在后台时静音移动到音频部分,这是它应该在的地方。不再需要在通用设置中到处寻找这个选项。

img

img

好的,正确的顺序

接下来的这个是对用户体验(UX)的巨大改进,对我个人来说也是一种巨大的解脱。以前,当使用每个游戏的控制器配置文件时,如果你忘记在开始游戏之前更改你的输入设置,你会在游戏关闭时丢失它们,并且下次必须再次设置。

epicboy 修复了这个烦人的问题,german77合并了这些更改。非常感谢这个修复。

german77也正在努力改进配置文件选择小程序。当前的更改只是开始,我们将在未来更新任何进展。

输入改进

让我们来谈谈输入,german77在这方面继续发光。

对于在Metroid Prime Remastered时的鼠标和键盘体验不满意,german77将默认的鼠标灵敏度设置为50%,并移除了平滑滤镜,这在得到Metroid粉丝的宝贵反馈后,提高了高DPI游戏鼠标的性能。他还降低了运动阈值,限制了旋转速度,并累积了所有输入直到交付,这修复了之前实现的延迟和卡顿。

 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)

你有没有注意到萨玛斯缺少一个引导指示器?她的战衣不能为此再分配一点点处理能力吗?(Metroid Prime Remastered)

多亏了这些改变,Metroid Prime Remastered表明它可以成为一个伟大的PC游戏。如果任天堂能让它出来的话。

我们常常被问到的一个问题是“这个第三方Switch控制器能用吗?”简短的回答是可能,但详细的回答有点复杂。

根据任天堂的API,Joy-Cons有两种模式:主动和被动。官方的Joy-Cons使用主动模式,但一些第三方控制器使用被动模式,通常是因为它们没有正确遵循API,不支持任何配置命令。它们只是使用默认设置,或好或坏。

这并不意味着被动控制器是无用的。它们在Switch上仍然可以工作。但这确实意味着它们的工作方式不同。主动控制器每15毫秒更新一次状态,而被动控制器只在发生某些事情时,如按键按下或释放时,才更新。

原来,直到现在,yuzu都不支持被动模式!所以german77的改变让很多第三方控制器的用户感到高兴。考虑到有这么多非官方的控制器,这是相当方便的。

振动的战斗还在继续!在他的常规研究中,german77发现,如果你有多于一个玩家使用同一种类型的控制器,或者如果你使用一个双Joy-Con的设置与单一的控制器,你可能会连续向同一个控制器发送两个振动命令。这可能会很烦人,而且还会占用蓝牙连接的有限带宽。

解决方案很简单:对于每个控制器,只取酷炫振动队列中的最新元素,检查控制器是否能处理请求的振动,并忽略其余的。

我们都喜欢生活质量的改变,对吧?即使它们并不是很闪耀。

让我们来谈谈控制器小程序,它负责在游戏请求时要求玩家选择他们的输入设置。直到现在,小程序是不能跳过的;你必须给出一个有效的答案才能继续你的游戏。虽然这是可以接受的,但它是麻烦的,也不准确。如果玩家不能或不愿确认他们的输入方式,有些游戏会回到前一个菜单,而不是陷入无尽的循环。

 You shall pass!

你可以通过!

german77解决了这种行为,并在此过程中也解决了一个玩家数量不正确的bug。

german77实现了……等等,让我先喘口气,SetNpadJoyAssignmentModeSingleWithDestination服务调用。他实现它希望能让Let’s Get Fit可以玩,但不幸的是还有更多的问题在阻碍。

转到Amiibo支持的话题,这个月发生了很多事。

首先,german77成功地编写了正确的CRC,使得由yuzu编写的Amiibo数据与Switch兼容;不再有无效信息。

接下来,如果你在扫描Amiibo时试图连接一个控制器,它将不会被识别。通过考虑这个并初始化或最终确定控制器,他修复了这个问题。

最后但同样重要的是,作为Amiibo的故事结束,Herman the German Sherman 添加支持纯Amiibo文件。一些Amiibos,比如以Super Smash Bros. Ultimate为主题的Amiibos,可以在无需密钥的情况下编辑。现在yuzu可以正确地从你的Amiibos读取非加密的游戏数据!

音频修复

Maide发现了一个在读取混响预延迟线时的bug,这个bug在输出时导致了问题。通过正确地通过输入读取,而不是输出,给New Super Mario Bros. U Deluxe等游戏提供了合适的音频。现在你可以享受Mario的声音,没有任何回声。Mama mia!

bylaws一直在深入研究音频同步,在这里和那里改进了代码库,通过将客户端样本跟踪链接到主机,避免了停顿。

这个变化引起了一些回归,因为有些游戏对音频调度需求非常敏感。用户在合并后报告说有爆音,所以bylaws通过给样本计数报告增加常量15毫秒的延迟,改善了这种情况。

其他代码更改

《火焰纹章》的粉丝们在游戏中经历了冻结的情况,经过一些调查后,Morph发现罪魁祸首是behunin的pull request引入的一个有界线程安全队列。

队列的任务是从事件生产者(比如CPU核心)传递事件给消费者(比如GPU线程)。之前的实现,被behunin替换的那个,持续地分配和释放内存,导致周期性的延迟峰值。

解决这个问题的方法是将队列变成一个有界队列,这意味着不需要内存分配,因为有固定数量的资源可以使用。这就是behunin所做的,但新的队列实现似乎有些bug。Morph添加了一个简化的实现,修复了影响Fire Emblem: Three HousesFire Emblem Engage的新的游戏冻结。

你的作者为GCC构建重新启用了LTO,这是按照上次为Windows做的更改,但仅将优化应用到core和video_core子项目,为Linux用户提供了一个不错的、免费的性能提升。

硬件部分

AMD 23.3.2及更新的驱动

一条糟糕的和两条好消息。

在积极的一面,AMD终于在他们的最新Windows驱动发布中添加了对缺失的动态状态扩展的支持,这改善了着色器构建时间,减少了Radeon GPU的卡顿,使它们的表现与NVIDIA相当。

然而,在消极的一面,这个驱动更新还引入了一个严重的回归:

 This can affect your entire desktop (Metroid Prime Remastered)

这可能会影响你的整个桌面环境(《超能战士 Prime》重制版)

一些游戏,如《超能战士 Prime 重制版》和《神奇宝贝传说:阿尔宙斯》,似乎触发了一个类似于越界的崩溃,导致桌面损坏和驱动程序崩溃。我们建议用户们暂时维持在23.3.1或更老的驱动版本上。一些旧的Radeon显卡可能也能从使用23.2.2中受益。

我们向AMD报告了这个问题,他们迅速确认了此问题,复现了它,并告知我们他们正在修复。

现在,这才叫做客户支持。

话说回来……

替Intel分忧

为了测试《塞尔达传说:荒野之息》中的一个我们下个月才会讨论的键盈染修复,Morph进行了一些功能测试,调查什么让Intel的Windows驱动程序运行得如此糟糕。

他的发现既在预料之中又让人失望。大约95%的崩溃主要由驱动程序中错误的计算着色器阶段引发。就像我们过去在旧的Intel硬件中做的一样,禁用计算着色器能使大部分游戏运行,但并非所有。我们还不清楚在《异度神剑3》打开菜单时所发生的崩溃的原因。

我们现在正在试图弄清楚是什么触发计算着色器导致驱动程序像这样崩溃,但这也引发了一个困境。我们应该自己解决这个问题,从而使游戏渲染效果变差,让Intel脱离问题,还是应该让它保持错误,这样他们就必须正确地修复它?

在调查继续的同时,解决方案是使用可靠的Linux,或者避免购买只依赖于Intel GPU的硬件。唉。

未来项目

我们甚至还没有过半个四月,我已经对下一份进度报告中的内容感到非常兴奋。开发者们正在燃烧他们的热情,他们不会在短时间内停下来。

Maide正在为《异度神剑》系列进行更多的改进,如修复《异度神剑2》中的云闪烁,修复《异度神剑3》中的粒子效果,以及修复影响整个系列和其他一些游戏的纹理闪烁。然而,这些修复会增加性能开销,因此他需要另一位GPU开发者的帮助来优化它们。也许Blinkhawk能够出一把力?

任天堂投入了发布Vulkan扩展中的圣杯Vk_EXT_shader_object的工作。这个扩展可以大幅减少构建着色器所需的工作量,因为它依赖所有之前的动态状态扩展。

最有可能的是任天堂打算在它们的内部模拟器中使用这个扩展,也许是为了”向后兼容”。不管怎样,为了增加对这个扩展的支持,我们还有许多工作要做。

不过,让我们不要再说这些了。让我们来谈谈一些正在进行的、令人兴奋的项目。

 Flute intensifies

笛声渐强

关于Project Gaia项目:它还在开发中。

哦,而Project Lime项目已经处于发布候选状态,正在进行激烈的内部测试。

就这样了,各位!感谢你们一直坚持看到这个进度报告的最后。

感谢Bing Chat的糟糕笑话。

文心一言

你好,各位Yuzu成员!我们一直都在努力,而这个三月已经在性能、图像、音频、CPU精度、输入等方面看到了进步!

让CPU走向相反的BRRRR

这个月份最大的变化之一就是CPU精度的一套改进。这需要我们回顾一下过去。

回到2022年7月,我们解释了CoreTiming以现有形式运作,使用的是主机计时器。一个名为HostTiming的线程被用来处理HLE事件,例如输入和音频。然而,其中某些事件,例如音频,需要高级别的计时器精度才能按照游戏期望的方式运作,这超越了Windows通常允许的范围。

默认情况下,Windows只允许1ms的精度,因为OS事件循环以1000Hz运行。这并不足够。但是,运行Linux、BSD和MacOS的设备没有这种限制,可以达成微秒(μs)级别的精度。

如果一款游戏想要以16.67ms(60 FPS)的帧时间运行,你可以在三分之二的时间内等待17ms,并在剩余的三分之一时间内等待16ms。但是,这已经被证明对音频精度来说是可怕的。替代方案,也是Windows正在使用的的方法,是等待16ms并空闲等待0.67ms。在这0.67ms内,CPU线程没有执行任何操作,只是消耗电力而没有工作。

移除对Windows 7和8/8.1的支持带来了好处。Windows 10 SDK有新的未记录功能,NtSetTimerResolutionNtDelayExecution,这允许将计时器精度提高到0.5ms。这使得yuzu可以等待16.5ms,并只让剩余的0.17ms空转,这比之前默认的方法短了四倍。

通过实现这些新功能Morph减少了CPU在自旋锁中的时间,从而减少了像《 Kirby Forgor》🔮…《 Kirby and the Forgotten Land》和《Super Smash Bros. Ultimate》等对计时要求较高的游戏的CPU使用率。新的自由资源意味着低核心数CPU(如四核)和有限功率预算的系统(如笔记本电脑和手持设备)可以获得更好的性能。根据限制因素的不同,这一变化使CPU使用率或功耗降低了24%。

img

img

左边:旧的1ms精度;右边:当前0.5ms精度。结果来自您的作者的手提电脑,运行的是单语言Windows安装,因此请不要在意西班牙语。请注意,两个结果之间的CPU使用情况存在差异

如果能够在相同的功率范围内执行更多任务,则可以在不牺牲电池寿命的情况下提高性能。或者,对于模拟器的更常见情况,如果上限是固定的帧速率,则可以降低温度。

img

img

这就是笔记本电脑中的膝盖是谎言原因,请注意封装温度(Xenoblade Chronicles 3)

用户报告说,由于计时器精度的提高,游戏中的音频卡顿减少了。

Windows 10 SDK添加的另一个很好的工具是允许将yuzu设置为HighQoS进程,这向Windows调度程序暗示如果有更高的性能核心可用,则应优先使用。这对于当前的锐龙CPU而言,这进一步提高了性能,因为它建议使用CCX的最佳核心,而对于英特尔第12代及更高版本,则优先级P核心(“性能核心”,普通核心)。

强烈建议及时更新芯片组驱动程序,以充分利用硬件优势。

如果CPU运行效率更高,我们如何更上一层楼呢?嗯,Morph想出的下一步是改进CPU自身计算时间的方式!

在现代使用x86架构的CPU上,不变计时器是使用RDTSC指令获取的。RDTSC的问题是……它在较长时间内不准确。在多核处理器上做不到。

RDTSC提供的最佳估计值与实际值之间的微小差异会导致Super Smash Bros. Ultimate等游戏中的时间漂移。您可能会注意到,这个问题会以不准确的比赛时间的形式出现。我们测量过受影响最严重的的CPU架构Intel 12th Gen(也是7月份的),每分钟会差一秒。

Morph针对此问题的解决方案是创建一个额外线程,其任务是进行10秒的TSC测量,然后取其差值并应用于了解前10秒内已经过去了多少实际时钟周期。然后,将时钟周期数除以10,即可得到主机RDTSC计时器在运行时的确切频率。

文言一心的记忆力到这里就不行了

讯飞星火

你好!我们一直在努力工作,这个三月看到了性能、图形、音频、CPU精度、输入等方面的改进!

让CPU走向相反的方向BRRRR

这个月最大的变化之一是在CPU精度方面的改进。这需要一些回溯,所以让我们倒退一点。

七月,我们解释了CoreTiming在当前形式下是如何运作的,使用一个主机定时器。一个名为HostTiming的线程用于处理HLE事件,如输入和音频。然而,这些事件中的一些,如音频,需要比Windows通常允许的高级计时精度才能按游戏的期望方式行为。

默认情况下,Windows只允许1毫秒的精度,因为操作系统事件循环运行在1000Hz上。这是不够的。然而,运行Linux、BSD和MacOS的设备不受这种限制,可以达到微秒(μs)级别的精度。

如果游戏想要以每秒60帧(16.67ms)的速度运行,你可以等待17ms的两倍时间(34ms)和剩余的一倍时间(16ms),但这在过去已经被证明对于音频准确性来说是糟糕的。对于Windows来说,另一个旧方法是等待16ms并进行0.67ms的忙等待。在此期间,CPU线程什么都不做,只是消耗电力而不真正工作。

这里的好处是移除了对Windows 7和8/8.1的支持。Windows 10 SDK有新的未记录的函数,NtSetTimerResolutionNtDelayExecution,它们允许将计时精度提高到0.5ms。这使得yuzu可以等待16.5ms,并仅在剩余的0.17ms中旋转,这是以前默认方法的四分之一短。

通过实现这些新功能Morph,大大减少了CPU在自旋锁中花费的时间,从而降低了对计时密集型游戏如Kirby Forgor 💀… Kirby and the Forgotten Land,以及Super Smash Bros. Ultimate等的CPU使用率。新的免费资源意味着对于像四核核心这样的低核心计数CPU以及像笔记本电脑和手持设备这样的具有有限电源预算的系统更好的性能。有了这个改变,我们测量出高达24%的CPU使用或功耗减少,具体取决于限制因素。

记忆力到这里就差不多了


以下为2023.5.1的测试结果

ChatGPT 3.5-turbo

这个版本稍微对ChatGPT进行了一点调教,在对话过程中加入了一点信息提示,让其变得口语化一些,然鹅并没有太大用处。

从中挑一句话,让其释义,可以看得出ChatGPT的翻译逻辑。翻译带来的信息缺失避不可免,中文语境和英文语境下的提问所带来的回答也略有不同。

用ChatGPT话来说就是:

由于语言、文化等因素的影响,部分原文的信息无法被有效传达或表达。这可能是因为翻译者缺乏对原文内容背景和语境的理解,或者因为某些原文中特定的词汇、说法、语态等在不同语言和文化之间难以越过,难以被准确传达。
例如,某些语言中可能有一些在其他语言中不存在的词汇,用这些词汇来描述某些文化或情境可能会更加准确,但由于难以直接翻译,它们可能被忽视或代表性地翻译,导致在翻译中缺乏细节和精确度。另一个例子可能是在不同语言中的语法和语调会有所不同,这可能会影响情感色彩或语气,进而影响原文的真实意义。
翻译带来的信息缺失可能会对跨文化交流和理解造成挑战,因此,在翻译过程中,翻译者必须尽可能细致地工作,确保原文意义得以准确表达。

至于翻译质量…,前面比较好,💸后面可能是API请求次数多了💸,翻译质量也有所下滑(比较严重)。


  • 来自你的消息:
    Making CPUs go the opposite of BRRRR 是这么翻译的?
  • 来自 ChatGPT 的消息:
    这个翻译比较随意,可能是对英文词组“BRRRR”(模拟发动机嗡嗡作响的声音)的引申和戏谑解释。从意义上来说,这个翻译的确包含了“CPU”和“运转”的意思,但并不严谨。更好的翻译是“让CPU运行得更加精准”。
  • 来自你的消息:
    我觉得你翻译的不对味
  • 来自 ChatGPT 的消息:
    非常抱歉,可能我的翻译出现了一些问题。请问您能否告诉我具体哪些地方翻译得不对味?我非常愿意进行修改和改进,确保翻译的准确性和流畅性。
  • 来自你的消息:
    BRRR是不是可以形容成噪音?
  • 来自 ChatGPT 的消息:
    BRRR 通常用来形容机器进行高速运转时产生的连续的嗡嗡声音,比如机车发动机或者电动工具的声音。因此它可以被视为一种噪音。但在 Yuzu Emulator 团队的文章中,他们使用 BRRR 来形容 CPU 的高速运转,意思是 CPU 正在快速地计算数据,其声音比喻为 BRRR。
  • 来自你的消息:
    Making CPUs go the opposite of BRRRR 的本意是什么?
  • 来自 ChatGPT 的消息:
    “Making CPUs go the opposite of BRRRR” 是一种幽默的说法,意思是通过优化 CPU 的性能和精度,使其不再发出嘈杂的 BRRR 声音。这个说法的本意是,Yuzu Emulator 团队正在尽力优化 CPU 的性能,让模拟器在运行时更加平稳和流畅,同时减少 CPU 发出的噪音。因此,这个说法强调了 CPU 性能提升的意义和价值。
  • 来自你的消息:
    所以要怎么翻译
  • 来自 ChatGPT 的消息:
    “Making CPUs go the opposite of BRRRR” 可以直译为“让 CPU 不再发出嘈杂的 BRRR 声音”,但这可能会让翻译后的语句有些生硬,不如结合上下文进行翻译。一个可能更好的翻译是“通过提升 CPU 的性能和精度,让模拟器运行更加平稳和流畅”。这种翻译可以更好地表达原文的意思,并且容易让读者理解。
  • 来自你的消息:

    为什么“笔记本电脑”的“膝盖”是一个谎言?你是怎么理解这句话的

  • 来自 ChatGPT 的消息:

    这句话可能是在玩梗或者开玩笑,其实并不是真正的谎言。根据常识,笔记本电脑是放在桌子或者平稳的面上使用的,不应该放在膝盖上使用,因为这样容易造成过热、对健康有害等问题。因此说“笔记本电脑的膝盖是一个谎言”可能是想表达这种常识或者警示的意思。但实际上,有些人还是会在膝盖上使用笔记本电脑,只是需要注意保持通风、散热,以及避免过久使用等问题。

  • 来自你的消息:

    the lap in laptop is a lie 翻译成 “笔记本电脑”的“膝盖”是一个谎言 。 如何评价?

  • 来自 ChatGPT 的消息:

    作为语言模型AI,我无法表达个人评价。但就文字表达本身而言,翻译正确且符合语法。

  • 来自你的消息:

    the lap in laptop is a lie 是什么梗

  • 来自 ChatGPT 的消息:

    “笔记本电脑中的‘lap’意味着膝盖,但这其实是个谎言”并不是一条流行的网络梗或引用,它只是一个文字游戏。这是从流行视频游戏《传送门》中的短语“蛋糕是个谎言”进行的修改,它意味着承诺或期望的东西并不存在或无法获得。在“笔记本电脑中的‘lap’意味着膝盖,但这其实是个谎言”中,它意味着“笔记本电脑”这个名字暗示这种设备可以放在人的膝盖上使用,但事实上,它可以导致不适或过热,这使得它不是理想的选择。因此,这并不是一个笑话或特定的引用,而是对笔记本电脑命名和使用的幽默评论。

  • 来自你的消息:

    “笔记本电脑”的“膝盖”是一个谎言。 是什么梗

  • 来自 ChatGPT 的消息:

    这句话的意思是说“笔记本电脑”的名称中,“膝盖”一词是一个谎言,因为实际上这种电脑不能真正放在膝盖上使用。这句话可能是对笔记本电脑命名方式的调侃,因为它的名称中有“笔记本”和“便携式”等词汇,但实际使用时并不总是那么方便。

关于the lap in laptop is a lie,可以看看WIKI中笔记本电脑别称“laptop computer”。


大家好,yuzu 团队又来给大家分享最近的进展了。本月我们在性能、图形、音频、CPU 精度、输入等方面都取得了一些进步。

让 CPU 保持平稳状态

本月最大的改进之一是在 CPU 精度方面的提升。这需要我们回顾一下历史。

在去年 7 月的一篇文章中,我们向大家介绍了 CoreTiming 的运作原理,即使用主机计时器。一个名为 HostTiming 的线程用于处理 HLE 事件(如输入和音频)。然而,诸如音频之类的事件需要更高的计时器精度才能符合游戏的期望,而这种精度通常比 Windows 系统默认的 1ms 更高。

默认情况下,Windows 只允许 1ms 的精度,因为操作系统的事件循环运行在 1000Hz。这显然是不够的。然而,运行 Linux、BSD 和 MacOS 的设备没有这个限制,可以达到微秒级别的精度。

如果一个游戏要以 16.67ms(60帧)的帧间隔运行,你可以在三分之二的时间内等待 17ms,剩下三分之一的时间等待 16ms,但过去已经证明这对音频精度来说非常糟糕。而在 Windows 上,旧的方法是在等待 16ms 后进行忙等待 0.67ms。在这 0.67ms 中,CPU 线程什么都不做,却在消耗电力。

在这里,放弃对 Windows 7 和 8/8.1 的支持发挥了作用。Windows 10 SDK 中有了新的未经记录的函数 NtSetTimerResolutionNtDelayExecution,可以将计时器精度提高到 0.5ms。这使得 yuzu 可以等待 16.5ms,只需忙等待剩下的 0.17ms,比以前默认方法忙等待时间短了四倍。

通过实现这些新函数,Morph 减少了 CPU 在自旋锁中的时间,这使得例如《柯比与遗忘之地》和《超级马里奥:究极纷争》等对 CPU 使用量较大的游戏性能得到了改善。新的可用资源为低核心数的 CPU,例如四核心 CPU,以及功率预算有限的笔记本电脑和手持设备提供了更好的性能。随着这个改变,我们测量到 CPU 使用量或电源消耗可以降低多达 24% ,这取决于限制因素是什么。
左

右

左:旧的 1ms 精度;右:当前的 0.5ms 精度。结果来自作者的笔记本电脑,运行的是单语言版的 Windows,所以不要在意西班牙语。请注意,两个结果之间有 CPU 使用量的差异。

如果你在相同的电力预算下可以完成更多任务,就可以提高性能而不牺牲电池续航时间。或者,对于模拟器来说,如果你的帧率上限是固定的,你可以降低温度。

这就是为什么“笔记本电脑”的“膝盖”是一个谎言,要注意 CPU 温度哦(《异度之刃3》)。

用户报告称,由于改进了计时器精度,游戏的音频卡顿现象减少了。

Windows 10 SDK 提供的另一个不错的工具是允许我们将 yuzu 设置为 HighQoS 进程,提示 Windows 调度程序,如果有更高性能的核心可用,应该优先使用它们。这进一步改进了目前 Ryzen CPU 的性能,通过建议使用 CCX 的最佳核心,以及针对 Intel 12 代及更高版本的优先使用 P 核心(“性能核心”,普通核心)。

强烈建议保持芯片组驱动程序最新,以充分利用你的硬件。

如果 CPU 以更高效的方式运行,我们如何进一步提高性能呢?Morph 想到的下一步是改进 CPU 计数时间的方式!

在使用 x86 架构的现代 CPU 上,不变计时器是通过 RDTSC 指令获取的。RDTSC 的问题是…它在较长时间内不准确,特别是在多核处理器上。

RDTSC 提供的最佳估计值和实际现实之间的微小差异导致了游戏中的时间漂移,如 Super Smash Bros. Ultimate。你可能会注意到这个问题在准确性不高的比赛时间上出现。我们在七月时测试发现,受影响最大的 CPU 架构是 Intel 12 代,误差可高达每分钟 1 秒。

Morph 对这个问题的 解决方法 是生成一个额外的线程,其任务是在十秒内获取两次 TSC 的测量值,然后取得差值,并将其应用于了解这些第一个十秒中实际经过了多少 tick。如果你将 tick 数除以 10,你就可以得到主机 RDTSC 计时器精度的确切频率。

好在我们不必使用旧的秒表来计时(Super Smash Bros. Ultimate)

结果是 Ryzen 和 Intel 11 代及更早的系统几乎实现了完美的计时,而 12 代 Alder Lake 系统则实现了“几乎”完美的计时。在 CPU 内部同步不同的核心同时计数不适用于这个特定的应用程序。我们不能击败 Intel 设计的混合非对称本质,但是我们设法将漂移从每分钟 1 秒减少到每 5 分钟左右的一秒。

Morph 说:“好了,这很不错,”但是你还可以更深入吗?唯一剩下的选项就是转向汇编语言。

目前,这种优化仅适用于 Intel 12 代及以上的 CPU。AMD 还没有添加支持。我们谈论的是 TPAUSE (CPUID 名称 WAITPKG),这是从蓝队推出的一种新指令,允许 CPU 进入较低的功耗状态并空闲,直到精确的时间已经过去。

需要进行一些测试,以确定等待周期的正确次数;值过小会导致精度降低,而值过大则不会产生任何好处。在 Morph 的测试中,100000 个周期是一个魔法数字,可以将 CPU 使用/功耗降低高达 20%,在之前获得的所有好处之上。

如果仅靠 Intel 的 GPU 驱动程序能够正常工作,它们配备了 Xe 的笔记本电脑/手持设备现在将成为非常适合 yuzu 游戏的机器…哎呀,12/13 代用户运行来自 NVIDIA 或 AMD 的实际工作的 GPU 驱动程序将从所有这些工作中获益匪浅。

图形变化

够了,我们先谈谈 CPU 的改进。那么,图形方面的进展呢?我们有相当多的话题要谈。

用户报告《Story of Seasons:A Wonderful Life》中出现了有趣的颜色带状。Maide(来自 Github)深入研究了这个问题,并在 S8_UINT 颜色格式(如D32_FLOAT_S8_UINTS8_UINT_D24_UNORM)中找到了罪魁祸首。凭借一些试验和来自 Skyline 模拟器开发者 bylaws 的大力帮助,Maide 设法解决了这些问题,提供了准确的颜色渲染,而不会影响其他游戏。

现在你可以享受这款农场模拟器的丰富多彩,而无需担心颜色条带。这不是很有趣吗?(《Story of Seasons:A Wonderful Life》)

epicboy 又再次发布了他的忍者更新。这一次他给 仍然热衷于 使用 OpenGL 的玩家们带来了一些新功能,包括在 上一次提交 中讨论的 AccelerateDMA,让OpenGL用户,特别是那些拥有 Fermi 和 Kepler GPU 的玩家,享受到了伪Y.F.C. 2变更的速度提升,让诸如《银河战士Prime 补丁版》这样的游戏运行速度更快了。不再需要等待 Samus 加载她的臂炮了。

我们强烈建议那些没有良好 Vulkan 支持的老旧硬件用户升级到更先进的硬件,因为对 OpenGL 的支持很快将走向生命周期尽头。也就是说,由于 epicboy 的努力,那些无法升级的用户也不用忍受旧但黄金的 OpenGL API 的可怕性能。

但这还不是全部,epicboy 还为 GL_SYNC_STATUS 添加了一个 优化,略微提升了性能。笔者在使用 NVIDIA 硬件运行《塞尔达传说:荒野之息》时观察到了 3-5% 的性能提升,这是少数在 OpenGL 上运行得更快的游戏之一(如果忽略着色器的卡顿)。

在游戏中最繁重的地点之一,从54帧提升至57帧,OpenGL仍然有活力!目前还是这样…(《塞尔达传说:荒野之息》)

根据我们的规定,重新指出了我们的旧Vulkan调度器实现在去年十月,byte[]对Vulkan使自制应用程序正常运行进行处理时存在一些回归。

这意味着在一些情况下,游戏和自制应用程序会等待帧在屏幕上显示出来,才开始渲染,这是反馈循环的坏例子。

通过在后台等待队列清空,而不必等待帧被呈现,byte[]解决了这一回归。感谢规则!

还记得我们上个月提到的那个可爱的游戏吗?适合所有年龄段!与您的家人玩完全安全。

vonchenplus 决定使其可玩,让全世界的玩家都可以享受到《萌动水晶H》惊人的游戏玩法,通过修复,修正了yuzu处理内联索引和绘制纹理命令时出现的错误。
文化游戏(萌动水晶H)

最近Steam Deck的系统更新破坏了许多游戏的图形。罪魁祸首是什么?VK_EXT_extended_dynamic_state3的某些问题,这是Vulkan扩展之一,有助于减少着色器构建卡顿。

yuzu希望NVIDIA驱动程序的行为与最新Deck上的Mesa实现有所不同,导致了下面看到的结果:

看起来就像屏幕上洒了一些颜料(《塞尔达传说:荒野之息》)

byte[] 禁用了目前引起问题的功能,但我们会在未来重新考虑启用它,因为很可能Mesa已经在他们的一端解决了问题

接下来是几个对《异度神剑》粉丝很重要的修复,Maide花了很多时间在上面工作。

由于取样器中sRGB边界颜色转换的问题,游戏中的着色器被破坏了。这是将颜色从一个颜色空间转换为另一个颜色空间的过程。这会导致一些检查在受影响的着色器上失败,导致错误地舍弃像素阴影。

我们需要更多的信息才能完全理解这个问题,但目前,忽略对sRGB取样器的色彩空间转换可以实现硬件精确渲染。

雷克斯知道他的未来会怎样,眨眨眼睛(《异度神剑2》)

另一个长期存在的问题影响了《异度神剑》三部曲(至少是Definitive Edition和2),自从著名的纹理缓存重写以来一直困扰着yuzu。那就是可能在游戏过程中随时发生的随机“彩虹模式”,或者在一个我不会剧透给新玩家的特定晚期剧情中发生。如果你在yuzu中玩过,你就知道会发生什么。这让你想起了Rapture中的感觉。

无论在何处,超越(云)之海!(《异度神剑2》)

另一个观察到的问题是过度的照明使整个场景难以辨认(特别是在晚上使用HDR显示器时,闪光强烈刺眼)。

我的眼睛!(《异度神剑2》)

Maide发现问题是由于在环境光线立方体贴图中用旧的主机数据替换新的客户机数据。解决方案是仅复制已标记为GPU修改的数据,遵循缓存重写的行为。

这可不是2009年,我们不需要这么多的泛光效果,非常感谢(《异度之刃:终极版》)。

有了这些改进,只剩下少数影响Xenoblade Chronicles系列的图形问题,使得从头到尾在yuzu上玩游戏成为一个极好的选择。然后,你可以和作者一起辩论哪个女王是最好的。

由于这个问题只会在第一次剧情渲染时发生,我将通过漏洞报告的图片来作弊,别介意(《异度神剑2》)

新来的开发者rschlaikjer一直在深入研究纹理缓存,试图找出为什么一个简单的视觉小说《月姬-蔚蓝碎片之月》在更换场景时会出现卡顿。也许是这个游戏太情感化,让模拟器难以处理。

问题的罪魁祸首是捕获GPU页面表时缺少引用运算符,导致该表每秒被重复拷贝成千上万次。这会让任何人出现卡顿,更不用说模拟器了。通过将捕获转换为引用解决了这个问题,这可能还可以修复其他游戏中类似的问题。

我们很高兴rschlaikjer在事情失控之前发现了这个漏洞。我们不想像那把椅子一样。

UI 改进

有些问题如此难以捉摸,以至于它们多年来一直不为人注意。有些问题如此复杂,需要深入理解所有相关的层才能找到正确的解决方案。它们让许多开发人员感到沮丧,放弃了,希望其他人有更好的运气。

还有一些问题就是纯粹的傻瓜。例如当默认用户配置文件损坏时,游戏崩溃的情况。

german77发现了数十个游戏崩溃的简单解决方法:将默认的个人资料照片设置为真正的32x32分辨率,而不是0x0。就是这样。

在继续改进用户界面方面,german77还将最后的音频设置“在后台时静音”移动到了Audio部分,其位置更合理。这样这个选项就不用在General里乱逛了。

接下来是UX(用户体验)的巨大改进,也是我个人的巨大救赎。以前,在使用每个游戏控制器配置文件时,如果忘记在开始游戏前更改输入设置,那么当游戏关闭时你会失去它们,并在下一次重新设置。

epicboy修复了这个恼人的问题,而german77合并了这些更改。非常感谢这个修复。

german77还在努力改进配置文件选择小应用程序。目前的变化只是个开始,我们将在未来继续向您汇报任何进展。

输入改进

让我们谈谈输入,german77在这方面继续拔尖。

在玩《梅特罗伊德Prime重制版》时,对于鼠标和键盘体验不满足,german77将默认鼠标灵敏度设置为50%并删除了平滑滤波器,引入了高DPI游戏鼠标的宝贵反馈后提高了性能。他还降低了运动阈值,限制了旋转速度,并在交付之前累积了所有输入,这解决了先前实现的延迟和粗糙度。

你有没有注意到萨姆斯缺少一个导航指示器?她的装备难道不能再多留一点处理能力吗?(《银河战士Prime》重制版)

由于这些改变,《银河战士Prime》重制版展现出了作为PC游戏的巨大潜力。但假如任天堂能够让它走出牢笼,那就更好了。

一个常见问题是:“这个第三方Switch控制器能用吗?”简短的答案是“可能”,但长答案则稍微复杂一些。

根据任天堂的API,Joy-Con有两种模式:主动和被动。官方Joy-Con使用主动模式,但是一些第三方控制器使用被动模式,通常是因为它们没有正确遵循API并且不支持任何配置命令。它们只使用默认设置,好或坏都有可能。

这并不意味着被动控制器没有用处。它们仍然可以在Switch上工作。但这意味着它们的使用方法不同。主动控制器每15毫秒更新一次状态,而被动控制器仅在发生按键按下或释放等事件时才更新。

实际上,直到现在yuzu还不支持被动模式!因此,german77的更改让很多第三方控制器用户感到高兴。这是十分方便的,考虑到有多少非官方控制器在市面上。

震动问题仍然存在!在进行其日常研究时,german77发现,如果你在使用相同类型的控制器操作超过一个玩家,或者使用一对Joy-Con单手柄来重复发送震动命令,那么会导致控制器接收两个连续的震动命令。这可能会很烦人,而且还会占用蓝牙连接的有限带宽。

解决方法很简单:只针对每个控制器队列中的最新元素进行检查,检查该控制器是否能处理所请求的震动,并忽略其他元素。解决方案详见这里

我们都喜欢提高游戏体验的改进,不是吗?即使它们并不那么引人注目。

让我们来谈谈控制器应用程序,它负责在游戏要求时询问玩家选择其输入设置。直到现在,该应用程序是无法跳过的,你必须给出有效的答案才能继续游戏。虽然这样通过,但它很麻烦且不准确。有些游戏如果玩家无法或不愿意确认其输入方式,会返回到以前的菜单而不是被困在无尽的循环中。

德国程序员german77解决了GitHub上的一个问题,还在此过程中修复了玩家计数不正确的bug。他实现了SetNpadJoyAssignmentModeSingleWithDestination服务调用,希望使《Let’s Get Fit》游戏可玩,但是目前还有更多问题未解决。

话题转到Amiibo支持,这个月发生了很多事情。

首先,german77成功编写了正确的CRC,使得yuzu写入的Amiibo数据与Switch兼容;不再是无效的信息。

接下来,如果您在扫描Amiibo时尝试连接控制器,它将无法被识别。通过考虑这一点并初始化或结束控制器,他修复了这个问题。

最后,为了结束Amiibo传奇,德国的Sherman Herman添加了对普通Amiibo文件的支持。像“超级马里奥兄弟终极版”这样的Amiibo可以在不需要密钥的情况下进行编辑。现在,yuzu可以正确读取您的Amiibo的非加密游戏数据!

音频修复

Maide发现了重verb预延迟线路读取方式存在的错误,导致输出出现问题。通过通过输入而不是输出正确地读取解决了这个问题,让像“新超级马里奥兄弟U豪华版”这样的游戏具有适当的音频。现在您可以享受没有回声的马里奥的声音了。妈妈咪呀!

bylaws一直在深入研究音频同步,改进代码库,并通过将客户端示例跟踪链接到主机来避免停顿。

这个改变导致了一些退化,因为一些游戏对音频调度要求非常敏感。用户报告合并后出现了砰砰声,因此bylaws通过将15毫秒的固定延迟添加到示例计数报告中来改善情况。

其他代码变化

《火焰纹章》的粉丝在游戏中体验到了冻结,经过一番调查,Morph发现罪魁祸首是有限线程安全队列,该队列是由behunin的请求引入的。

队列的工作是将事件从事件生成器(如CPU核心)传递到事件消费者(如GPU线程)。 behunin替换的先前实现不断分配和释放内存,导致间歇性的延迟峰值。

解决此问题的方法是将队列转换为有界队列,这意味着不需要内存分配,因为有一定数量的资源可用。这就是behunin所做的,但新队列实现似乎存在错误。 Morph添加了一个简化的实现,修复了影响《火焰纹章:三位之家》和《火焰纹章》的新游戏冻结。

作者为GCC构建重新启用了LTO,遵循上次对Windows所做的更改,但仅将优化应用于核心和video_core子项目,为Linux用户提供了良好的免费性能提升。

硬件部分

AMD 23.3.2和更新的驱动程序

有一个坏消息和两个好消息。

好消息是,AMD终于在最新的Windows驱动程序中添加了缺失的动态状态扩展支持,这提高了着色器构建时间,并减少了Radeon GPU上的卡顿,使它们与NVIDIA表现相当。

然而,坏消息是,此驱动程序更新也引入了一个严重的回归:

这可能会影响你的整个桌面(《银河战士Prime重制版》)

一些游戏,如“银河战士Prime重制版”和“宝可梦传说:阿尔宙斯”,触发了似乎是越界崩溃的情况,导致桌面损坏和驱动程序崩溃。我们建议用户暂时保持在23.3.1或更旧的驱动程序版本上。一些较旧的Radeon卡也可能会受益于使用23.2.2。

我们已向AMD报告了此问题,他们迅速确认并复制了该问题,并告知我们他们正在解决此问题。

这就是如何进行客户支持。

说到这里…

做英特尔工作

在测试我们下个月将要讨论的“塞尔达:荒野之息”的一个重要渲染修复时,Morph进行了一些特性测试,以调查是什么让英特尔Windows驱动程序运行得如此糟糕。

他的发现既意料之中又令人失望。大约95%的崩溃的主要罪魁祸首是驱动程序中有缺陷的计算着色器阶段。像我们为较旧的英特尔硬件所做的那样禁用计算着色器可以使大多数游戏运行,但并非所有游戏。我们仍然不知道在“异度之刃3”的菜单中打开时崩溃的原因。

现在我们尝试弄清楚是什么导致计算着色器以这种方式崩溃驱动程序,但这也引发了一个困境。我们应该自己修补问题,使游戏渲染更糟糕,并让英特尔摆脱困境,还是应该让它继续断掉,以便他们可以适当地修复它?

在调查仍在进行时的解决方案是使用可靠的Linux,或避免购买仅依赖于英特尔GPU的硬件。叹息。

未来项目

我们甚至还没有到四月中旬,我已经对接下来的进展报告充满期待了。开发人员们正在快速发展,而他们并不打算就此停止。

Maide正在为“异度之刃”系列进行更多改进,例如修复“异度之刃2”中云朵闪烁的问题,修复“异度之刃3”中的粒子效果,以及影响整个系列和一些其他游戏的纹理闪烁。然而,这些修复会带来性能损失,因此他需要其他GPU开发人员的帮助来优化它们。也许Blinkhawk可以伸出援手?

任天堂贡献了Vulkan扩展的圣杯,VK_EXT_shader_object。该扩展承诺显著减少构建着色器所需的工作量,因为它的依赖关系表明需要支持所有先前的动态状态扩展。

最有可能的是任天堂打算将其用于其内部模拟器,也许是“向后兼容性”。无论如何,我们还有很多工作要做,以添加对此扩展的支持。

但足够了。让我们谈谈正在进行的一些令人兴奋的项目。

长笛声加强了

关于Gaia计划:它仍在开发中。

哦,而且Lime计划已经进入发布候选状态,正在进行激烈的内部测试。

就这样了!感谢你们一直坚持阅读本次进展报告。

感谢Bing Chat提供糟糕的笑话。

ChatGPT 3.5-POE

POE上的免费版本。还是差了点

大家好,yuzu的用户们!我们一如既往地努力工作,这个3月份在性能、图形、音频、CPU精度、输入和许多其他方面都有了改进!

让CPU反向BRRRR

这个月最大的变化之一就是CPU精度的一系列改进。这需要一些回溯,让我们先回溯一下。

在去年7月,我们解释了CoreTiming在当前形式下的操作方式,使用主机定时器。一个名为HostTiming的线程用于处理HLE事件,例如输入和音频。然而,其中一些事件(例如音频)需要比Windows通常允许的更高精度的定时器才能以游戏期望的方式运行。

默认情况下,Windows只允许1ms的精度,因为操作系统事件循环以每秒1000次的频率运行。这还不够。然而,运行Linux、BSD和MacOS的设备不会受到这个限制,可以实现微秒级别的精度。

如果一个游戏想以16.67ms(60帧)的帧间隔运行,你可以在三分之二的时间内等待17ms,其余的三分之一等待16ms,但是过去已经证明这对音频精度来说是可怕的。另一种在Windows上使用的替代方法是等待16ms并忙等待0.67ms。在0.67ms期间,CPU线程没有做任何事情,消耗电力而没有实际工作。

这就是移除对Windows 7和8/8.1支持的好处。Windows 10 SDK有一些新的未记录的函数,NtSetTimerResolutionNtDelayExecution,允许将定时器分辨率提高到0.5ms。这使得yuzu可以等待16.5ms,只旋转其余的0.17ms,比以前的默认方法短四倍。

通过实现这些新函数, Morph减少了CPU在自旋锁中的时间,从而减少了定时器精度对游戏的影响,例如《Kirby Forgor》、《Kirby and the Forgotten Land》和《Super Smash Bros. Ultimate》等需要高精度定时器的游戏。新的空闲资源意味着对四核心CPU和电力受限的系统,例如笔记本电脑和掌机,有更好的性能提升。通过这个改变,我们测量到CPU使用率或电力消耗有多达24%的下降,取决于限制因素。

左

右

左:旧的1ms精度;右:当前的0.5ms精度。结果来自作者的笔记本电脑,运行了单一语言的Windows安装程序,请忽略西班牙语。请注意,两个结果之间的CPU使用率存在差异。

如果你能在相同的电力范围内执行更多任务,你就可以提高性能而不会牺牲电池续航时间。或者,对于模拟器更常见的情况是,如果你的上限是固定的帧速率,你可以降低温度。

这就是为什么笔记本电脑的lap是个谎言,要注意包裹温度(《异度神剑3》)

用户反映,由于改进了定时器精度,游戏的音频卡顿现象有所减少。

Windows 10 SDK提供的另一个不错的工具是,允许我们将yuzu设置为HighQoS进程,向Windows调度程序提示,在有更高性能核心可用时应优先采用。这对于当前的Ryzen CPU来说进一步提高性能,通过建议使用CCX的最佳核心,对于英特尔第12代及以上的CPU来说,通过优先使用P-cores(“性能核心”,普通核心)来优化性能。

强烈建议保持芯片组驱动程序的最新状态,以充分利用您的硬件。

如果CPU表现得更加高效,那么我们如何进一步提高性能呢?Morph发现下一步是改进CPU自身计时的方式!

在使用x86架构的现代CPU上,不变定时器是使用RDTSC指令获取的。RDTSC的问题在于…在较长的时间内它不准确,对于多核处理器来说更是如此。

RDTSC提供的最佳估计值和实际现实之间的微小差异会导致像《超级马里奥派对》这样的游戏中的时间漂移。您可能会注意到这个问题表现为不准确的比赛时间。我们测量过的英特尔第12代CPU架构最受影响,每分钟会慢一秒钟。

Morph的解决方案是生成一个额外的线程,其任务是对TSC进行两次10秒的测量,然后将差异应用于知道在那些前10秒中经过了多少实际的时钟周期。如果您将时钟周期数除以10,您就可以得到主机RDTSC定时器的确切频率。

幸好我们不必使用旧秒表来完成这项工作(《超级马里奥派对》)

结果是在Ryzen和英特尔第11代及更早的系统上实现了几乎完美的定时,并且在第12代Alder Lake系统上实现了几乎完美的定时。在CPU内同时计时完全不适用于这个特定的应用程序。我们无法击败英特尔设计的混合不对称性,但我们设法将漂移从每分钟一秒钟降低到每5分钟一秒钟左右。

“好吧,这非常好”Morph说,但是你如何更深入地进行优化?唯一的选择是降低到汇编语言。

所讨论的优化目前仅适用于第12代及更新的英特尔CPU;AMD尚未添加对其的支持。我们正在谈论TPAUSE(CPUID名称为“WAITPKG”),这是来自团队蓝色的一条新指令,允许CPU进入较低的功耗状态并等待精确的时间量。

需要进行一些测试,以确定等待周期的正确循环数;一个错误的值将在一个极端上降低精度,而在另一个极端上不产生任何好处。在Morph的测试中,100000个周期是魔法数字,可以将CPU的使用/功耗降低高达20%,除了以前的好处之外。

如果只有英特尔GPU驱动程序正常工作,他们装备Xe的笔记本电脑/掌上游戏机将成为非常适用的yuzu游戏机…好吧,第12/13代用户在使用来自NVIDIA或AMD的实际工作GPU驱动程序时将从所有这些工作中获益匪浅。

图形更新

够了关于CPU的改进了。那么图形方面呢?我们有很多话要说。

用户报告称在“牧场物语:奇妙人生”中出现了有趣的色带问题。Maide深入研究了这个问题,并在S8_UINT颜色格式中,如D32_FLOAT_S8_UINTS8_UINT_D24_UNORM中找到了问题的根源。通过一些试错和来自Skyline模拟器的伟大贡献者bylaws的大力帮助,Maide成功解决了问题,提供了准确的颜色渲染,而不会破坏其他游戏。

现在你可以享受这个农场模拟器的所有鲜艳色调,无需担心色带问题。这不是很有趣吗?(牧场物语:奇妙人生)

epicboy再次用他的忍者更新给予一些关爱。这次他给仍然繁荣的OpenGL用户提供了所有AccelerateDMA的好处,我们在上一份报告中讨论过。

这意味着OpenGL用户,特别是那些拥有Fermi和Kepler GPU的用户,可以享受这个伪Y.F.C. 2改变的速度提升,使得游戏,如“超级星际战士Prime重制版”运行更快。不再等待萨姆斯装载她的臂炮。

我们强烈建议那些没有良好Vulkan支持的旧硬件用户升级到新硬件,因为OpenGL的支持即将接近生命周期结束。尽管如此,由于epicboy的贡献,那些无法升级的用户使用旧但金光闪闪的OpenGL API不会遭受可怕的性能问题。

但这还不是全部,epicboy还为GL_SYNC_STATUS添加了一个优化,略微提高了性能。笔者在“塞尔达传说:荒野之息”中观察到了3-5%的性能提升,这是为数不多在NVIDIA硬件上运行更快的游戏之一,如果你忽略了着色器卡顿的话。

从游戏中最重要的地方的54帧到57帧,OpenGL仍然有生命力!目前为止…(塞尔达传说:荒野之息)

bylaws再次挺身而出,指出我们旧的Vulkan调度器实现在去年10月发生了一些退步,当byte[]正在使自制应用程序与Vulkan兼容时,就发生了这种情况。

这意味着游戏和自制应用程序必须等待一帧显示在屏幕上才开始渲染,这在某些情况下是最坏的反馈循环的一个不好的例子。

通过在后台等待队列被清空而不必等待帧被呈现,byte[]解决了这个问题。感谢bylaws!

记得上个月我们谈到的那个可爱的游戏吗?适合所有年龄段的游戏!可以和家人一起玩的非常安全。

vonchenplus决定修复yuzu处理内联索引和绘制纹理命令的错误,使 燃情水晶H 这个游戏成为全球玩家玩乐的良好选择。

精致的游戏(燃情水晶H)

Steam Deck的最新系统更新破坏了许多游戏的图形。罪魁祸首是什么?一些与Vulkan扩展VK_EXT_extended_dynamic_state3有关的问题,该扩展有助于减少着色器构建卡顿。

yuzu期望NVIDIA驱动程序的行为,而最新版Mesa在Deck上的实现与之有所不同,导致了下面的问题:

看起来好像有人在屏幕上溅了一些颜料(《塞尔达传说:荒野之息》)

byte[] 禁用了 导致问题的功能,但我们将在未来重新考虑将其打开,因为很可能Mesa已经解决了它们端的问题。

以下是Maide为Xenoblade粉丝做出的一些重要修复。

由于采样器中的sRGB边框颜色转换问题,游戏内的着色器已经损坏。这是一种将颜色从一个颜色空间转换为另一个颜色空间的过程。这会导致一些受影响的着色器检查失败,从而丢弃错误的像素作为阴影。

我们需要更多信息才能完全理解这个问题,但是忽略 sRGB采样器上的颜色空间变换可以实现硬件准确渲染。

雷克斯知道他的未来,眨眼(异度之刃2)

Xenoblade三部曲(至少是《Xenoblade Chronicles:Definitive Edition》和《异度之刃2》)的另一个长期问题困扰着yuzu自从传说中的Texture Cache Rewrite之后。这就是随时可能发生的随机“彩虹模式”,或者是我不想剧透给新玩家的特定后期剧情中的情节,在yuzu中玩过的人应该会知道。这会让你想知道自己是否在狂喜市

在某个地方,超越云海!(异度之刃2)

另一个问题是过度的光照使整个场景不可读(特别是在夜间使用HDR显示器时,不是一种愉快的突然爆闪)。

我的眼睛!(异度之刃2)

Maide发现问题是由于在环境照明立方图中用陈旧的主机数据替换新鲜的客户端数据造成的。解决方案是仅复制标记为GPU修改的数据,遵循缓存重写的行为。

这可不是2009年了,我们不需要这么多的泛光效果,非常感谢(《异度神剑:终极版》)

通过这些更改,Xenoblade Chronicles系列只剩下少数图形问题,使其成为yuzu从头到尾享受的好选择。然后你可以和作者一起讨论哪个女王是最好的。

由于这个问题仅在第一次渲染剧情时发生,所以我会使用Bug报告图片进行作弊,咬我吧(异度之刃2)

新人rschlaikjer,我希望我发音没错,一直在深入挖掘纹理缓存,试图弄清楚为什么像月姬-蓝色玻璃月之碎片这样的简单视觉小说在切换场景时会出现卡顿。也许是因为游戏对模拟器的情感太强烈了。

罪魁祸首是捕获GPU页表时缺少引用运算符,这导致表一遍又一遍地被复制。这会让任何人卡顿,更不用说模拟器了。将捕获转换为引用解决了该问题,并且它可能还可以修复其他游戏中的类似问题。

我们很高兴rschlaikjer在问题失控之前就发现了这个bug。我们不想像那把椅子一样。

界面改动

有些问题是如此难以捉摸,以至于它们被忽视了多年。有些问题如此复杂,需要深入理解所有涉及的层才能找到正确的解决方案。这让许多开发人员感到沮丧,他们放弃了,希望其他人会有更好的运气。

而有些问题则非常愚蠢。例如,当默认用户配置文件损坏时,游戏崩溃。

german77 发现了一个简单的解决方案,适用于数十个游戏的崩溃问题:将默认配置文件图片的分辨率设置为32x32而不是0x0。就这样。

在继续改善用户界面方面的工作中,german77 还将上一次音频设置“在后台静音音频”移到了音频部分,这样就不必再在常规设置里寻找它了。

接下来这个改变对于用户体验来说是一个巨大的提升,对我个人来说也是一个巨大的解脱。以前,当使用每个游戏的手柄配置文件时,如果您在启动游戏之前忘记更改输入设置,那么当游戏关闭时,您将失去这些设置,并且必须在下一次设置它们。

epicboy 解决了这个讨厌的问题,german77 合并了这些更改。非常感谢这个修复。

german77 还在努力改进配置文件的选择应用程序。当前的更改只是一个开始,我们将随时向您更新任何进展。

输入改进

让我们来谈谈输入,german77 在这方面继续闪耀。

Metroid Prime Remastered 时,german77 对鼠标和键盘的使用体验不太满意。他将默认鼠标灵敏度设置为50%,并去除了平滑滤镜,在得到Metroid粉丝的宝贵反馈后,改善了高DPI游戏鼠标的性能。他还降低了运动阈值,限制了旋转速度,并将所有输入累积到交付之前,这修复了之前实现中的延迟和卡顿。

您有没有注意到Samus缺少一个指示器?她的防护服难道不能多耗费一点处理能力来做这个吗?(Metroid Prime Remastered)

由于这些更改,Metroid Prime Remastered 显示它可以成为一款很棒的PC游戏。只要任天堂能让它走出牢笼就好了。

我们经常收到的一个问题是:“这个第三方Switch控制器会起作用吗?”简短的答案是可能,但长的答案则更加复杂。

根据任天堂的API,Joy-Con有两种模式:主动和被动。官方Joy-Con使用主动模式,但某些第三方控制器使用被动模式,通常是因为它们没有正确遵循API并且不支持任何配置命令。它们只使用默认设置,优点和缺点都有。

这并不意味着被动控制器是无用的。它们仍然可以在Switch上使用。但这意味着它们的工作方式不同。主动控制器每15毫秒更新一次状态,而被动控制器仅在发生某些事件时(例如按下或释放按钮)才更新状态。

好吧,事实证明直到现在yuzu都不支持被动模式!因此,german77 的更改让许多第三方控制器用户感到高兴。考虑到有多少非官方控制器存在,这非常方便。

震动的战斗还在继续!在进行他的常规研究时,german77 发现,如果有多个玩家使用相同类型的控制器,或者如果您使用双Joy-Con设置与单个控制器一起使用,则可以连续向同一控制器发送两个震动命令。这可能很烦人,并且还占用了蓝牙连接的有限带宽。

解决震动问题的方法很简单:对于每个控制器,只需从酷震动队列中取最新元素,检查控制器是否能处理请求的震动,并忽略其余元素。

我们都喜欢提高生活质量的变化,对吧?即使它们不太引人注目。

让我们谈谈“控制器应用程序”,它负责在游戏请求时要求玩家选择其输入设置。直到现在,该应用程序是不可跳过的;你必须给出有效的答案才能继续游戏。虽然这还算可以,但它仍然很麻烦和不准确。如果玩家不能或不愿确认他们的输入样式,某些游戏会返回到先前的菜单,而不是陷入无限循环。

你现在可以通过了!

german77解决了这种行为,并且在此过程中还解决了玩家数量不正确的一个错误。

german77实现了…等等,让我先喘口气,“SetNpadJoyAssignmentModeSingleWithDestination”服务调用。他实现了它,希望让“Let’s Get Fit”成为可玩游戏,但不幸的是还有更多问题需要解决。

换个话题,谈谈Amiibo的支持,这个月发生了很多事情。

首先,german77成功编写了正确的CRC,使yuzu写入的Amiibo数据与Switch兼容,不再有无效的信息。

其次,如果你在扫描Amiibo时尝试连接控制器,它将无法被识别。通过考虑到这一点并初始化或完成控制器,他解决了这个问题。

最后,为了结束Amiibo的传奇,德国人赫尔曼(Herman the German Sherman)添加了对普通Amiibo文件的支持。一些Amiibo,例如那些以“超级马里奥兄弟终极版”为主题的Amiibo,可以在不需要密钥的情况下进行编辑。现在,yuzu可以正确读取你的Amiibo的非加密游戏数据了!

音频修复

Maide发现了一个bug,它导致混响预延迟行读取错误,从而导致输出问题。通过通过输入正确读取而不是输出来解决这个问题,使得像“新超级马里奥兄弟U豪华版”这样的游戏具有了正常的音频。现在你可以享受没有任何回声的马里奥的声音了。马马咪呀!

bylaws深入挖掘了音频同步,在代码库的这个地方进行了改进,并通过将客户机样本跟踪与主机链接,成功避免了死机。

这个改变导致了一些退化,因为一些游戏对音频调度要求非常敏感。用户报告称合并后出现了爆炸声,因此bylaws通过在样本计数报告中添加一个恒定的15毫秒的延迟来改善情况。

其他代码更改

《火焰纹章》的粉丝在游戏中遇到了冻结问题,经过一些调查,Morph发现罪魁祸首是由behunin的拉取请求引入的有界线程安全队列。

这个队列的工作是将事件从事件生产者(如CPU核心)传递到事件消费者(如GPU线程)。Behunin替换的前一个实现不断分配和释放内存,导致周期性的延迟峰值。

解决这个问题的方法是将队列转换为有界队列,这意味着不需要内存分配,因为有一定数量的资源可用。这就是behunin所做的,但新的队列实现似乎有bug。Morph添加了一个简化的实现,修复了影响《火焰纹章:三位一体》和《火焰纹章:战斗》的新游戏冻结问题。

你的作者重新启用了LTO以进行GCC构建,遵循上一次针对Windows所做的更改,但只将优化应用于核心和video_core子项目,为Linux用户提供了一个不错的、免费的性能提升。

硬件部分

AMD 23.3.2及更高版本的驱动程序

一个坏消息和两个好消息。

积极的一面是,AMD终于在他们最新的Windows驱动程序发布中添加了对缺失的动态状态扩展的支持,这提高了着色器构建时间,并减少了Radeon GPU的卡顿,使它们的性能与NVIDIA相当。

然而,消极的一面是,这个驱动程序更新还引入了一个严重的退化:

这可能影响你的整个桌面(《银河战士Prime重制版》)

一些游戏,如《银河战士Prime重制版》和《宝可梦传说:阿尔宙斯》,会触发似乎是越界崩溃的问题,导致桌面损坏和驱动程序崩溃。我们建议用户目前还是使用23.3.1或更早版本的驱动程序。一些较旧的Radeon卡也可能从使用23.2.2中受益。

我们向AMD报告了这个问题,他们迅速确认并重现了这个问题,并告诉我们他们正在努力修复它。

这就是如何为客户提供支持。

说到这个……

努力完成英特尔的工作

在测试下个月将要讨论的《塞尔达传说:荒野之息》的一个关键渲染修复时,Morph进行了一些特性测试,以调查是什么导致了英特尔Windows驱动程序如此糟糕。

他的发现既是预期的,又令人失望。大约95%的崩溃的主要原因是驱动程序中有一个错误的计算着色器阶段。像我们为旧的英特尔硬件所做的那样禁用计算着色器可以使大多数游戏运行,但并非所有游戏都可以。我们仍然不知道在《异度神剑3》的菜单中打开时崩溃的原因。

我们现在正在试图弄清楚是什么导致了计算着色器如此崩溃驱动程序,但这也引发了一个困境。我们应该自己修补这个问题,使游戏渲染变得更糟,让英特尔摆脱困境,还是应该让它继续破裂,让他们彻底修复它?

在调查继续进行时,解决方案是使用可靠的Linux,或避免购买仅依赖英特尔GPU的硬件。叹息。

未来项目

我们甚至还没有到四月的一半,我已经对下一份进展报告感到兴奋了。开发人员们燃烧着激情,他们不会停下来。

Maide正在为《异度神剑》系列进行更多改进,例如修复《异度神剑2》中的云层闪烁、《异度神剑3》中的粒子效果以及影响整个系列和其他一些游戏的纹理闪烁。然而,这些修复会带来性能成本,所以他需要另一个GPU开发人员的帮助来优化它们。也许Blinkhawk可以援助一臂之力?

任天堂发布了Vulkan扩展的圣杯,VK_EXT_shader_object。这个扩展承诺显著减少构建着色器所需的工作量,因为它的依赖关系表明需要支持所有先前的动态状态扩展。

最有可能任天堂打算将其用于内部模拟器,可能用于“向后兼容”。无论如何,我们需要做很多工作来添加对这个扩展的支持。

但是,让我们不再谈论这个。让我们谈谈正在进行中的一些令人兴奋的项目。

长笛声加强了

关于Gaia项目:它仍在开发中。

哦,而Lime项目正在发布候选状态下,正在进行激烈的内部测试。

这就是全部内容!感谢您一直耐心阅读到本进展报告的末尾。

感谢Bing Chat提供可怕的笑话。


ChatGPT 4-POE

POE的阉割版,仅翻译一部分作为效果参考。

英文提示词翻译结果:

嗨,yuz-ers!我们一如既往地努力工作,今年三月份,我们在性能、图形、音频、CPU精度、输入等方面取得了很大的进步!

让CPU朝着BRRRR的相反方向运转

本月最大的变化之一是CPU精度方面的一系列改进。这需要一些回溯,让我们稍微回顾一下。

回到7月,我们解释了CoreTiming如何以其当前形式使用主机计时器运行。一个名为HostTiming的线程用于处理HLE事件,如输入和音频。然而,这些事件中的一些,比如音频,需要比Windows通常允许的更高的计时器精度才能按照游戏预期的方式运行。

默认情况下,Windows只允许1ms的精度,因为操作系统事件循环以1000Hz运行。这是不够的。然而,运行Linux、BSD和MacOS的设备没有这个限制,可以实现μs(微秒)级的精度。

如果一个游戏想以16.67ms(60FPS)的帧时间运行,你可以三分之二的时间等待17ms,剩下的三分之一时间等待16ms,但这种方法已经被证明对音频精度非常糟糕。另一种选择,也是Windows之前使用的旧方法,是等待16ms,然后忙等0.67ms。在这0.67ms期间,CPU线程什么都不做,消耗电力而实际上不工作。

取消对Windows 7和8/8.1的支持带来了好处。Windows 10 SDK具有新的未记录功能,NtSetTimerResolutionNtDelayExecution,这些功能允许将计时器精度提高到0.5ms。这使得yuzu可以等待16.5ms,只需旋转剩下的0.17ms,这比之前的默认方法短四倍。

通过实现这些新功能Morph减少了CPU在自旋锁中花费的时间,从而降低了像《卡比For美国💀》……Kirby and the Forgotten LandSuper Smash Bros. Ultimate这样的计时密集型游戏的CPU使用量。新的空闲资源意味着对于核心数量较少的CPU(如四核)和功率有限的系统(如笔记本和掌上设备)具有更好的性能。根据这一改变,我们测量到CPU使用率或功耗降低了高达24%,具体取决于限制因素。

左图:旧的1ms精度;右图:当前的0.5ms精度。 结果来自您的作者的笔记本电脑,该电脑运行单语言Windows安装,所以不用介意西班牙语。 请注意,这两个结果的CPU使用率之间存在差异

如果您可以在相同的功耗范围内执行更多任务,那么您可以在不影响电池寿命的情况下提高性能。或者,对于模拟器更常见的情况,如果您的上限是固定的帧速率,您可以降低温度。

这就是为什么笔记本电脑的膝上有个谎言,请注意包装温度(异度神剑3)

中文提示词结果:

嗨,亲爱的yuz-ers!我们一如既往地努力工作,今年3月,我们在性能、图形、音频、CPU精度、输入等方面取得了很多进步!

让CPU逆向运转

本月最大的变化之一是CPU精度的一系列改进。这需要回溯一下,让我们稍微回顾一下。

7月的文章中,我们解释了CoreTiming如何以当前形式运作,使用主机计时器。一个名为HostTiming的线程用于处理HLE事件,如输入和音频。然而,这些事件中的一些,如音频,需要较高的计时器精度才能按照游戏预期的方式运行,这比Windows通常允许的要求更高。

默认情况下,Windows只允许1ms的精度,因为操作系统事件循环运行在1000Hz。这还不够。然而,运行Linux、BSD和MacOS的设备没有这个限制,可以达到μs(微秒)级别的精度。

如果一个游戏希望以16.67ms(60 FPS)的帧间隔运行,你可以三分之二的时间等待17ms,剩下的三分之一时间等待16ms,但这已经被证明对音频精度非常糟糕。以前在Windows上使用的替代方法是等待16ms,然后忙等待0.67ms。在这0.67ms期间,CPU线程什么都不做,消耗电力却没有实际工作。

这里就是取消对Windows 7和8/8.1支持的好处。Windows 10 SDK有新的未记录的函数,NtSetTimerResolutionNtDelayExecution,它们允许将计时器精度提高到0.5ms。这使得yuzu可以等待16.5ms,只需旋转剩下的0.17ms,这比以前的默认方法短了四倍。

通过实现这些新函数Morph减少了CPU在自旋锁中的时间,使得像《Kirby Forgor 💀》(《星之卡比:被遗忘的土地》)和《Super Smash Bros. Ultimate》(《任天堂明星大乱斗 特别版》)等对时间要求严格的游戏CPU使用率降低。新的空闲资源意味着对于低核心计数的CPU(如四核心)以及功率有限的系统(如笔记本电脑和掌上游戏机)具有更好的性能。通过这一变化,我们测量到CPU使用率或功耗降低了高达24%,具体取决于限制因素。

左图:旧的1ms精度;右图:当前的0.5ms精度。结果来自作者的笔记本电脑,该笔记本运行单语言Windows安装,所以别在意西班牙文。注意两个结果之间的CPU使用率有所不同。

如果你可以在相同的功率范围内执行更多任务,你可以在不牺牲电池寿命的情况下提高性能。另外,对于模拟器来说更常见的情况是,如果你的上限是固定的帧率,你可以降低温度。

这就是为什么笔记本电脑的lap是一个谎言,请注意封装温度(《异度之刃3》)。


Claude +

大家好,yuz-ers!我们一如既往地努力工作,3月份在性能、图形、音频、CPU精度、输入等方面都有了很大提高!

让CPU变得相反的“呼呼”

这个月最大的变化之一是CPU精度的提高。这需要一些倒退,让我们回顾一下。

7月,我们解释了CoreTiming如何在当前形式下运作,使用宿主定时器。一个名为HostTiming的线程用于处理HLE事件,如输入和音频。然而,其中一些事件,如音频,需要高精度的定时器才能如游戏预期的那样工作,这通常超出Windows的允许范围。

默认情况下,Windows只允许1毫秒的精度,因为操作系统事件循环每秒运行1000次。这还不够。然而,运行Linux、BSD和MacOS的设备不面临这个限制,可以达到微秒级的精度。

如果一款游戏想以16.67毫秒(60 FPS)的帧时间运行,您可以在三分之二的时间内等待17毫秒,在剩余的三分之一的时间内等待16毫秒,但这在过去已经证明对音频精度很糟糕。另一种方法,也是Windows过去使用的方法,就是等待16毫秒,然后在0.67毫秒内进行忙等待。在这0.67毫秒内,CPU线程实际上什么都不做,消耗功率但不工作。

此时,取消对Windows 7和8/8.1的支持就显得很有意义了。Windows 10 SDK有新的未公开函数NtSetTimerResolution和NtDelayExecution,允许提高定时器分辨率至0.5毫秒。这允许yuzu等待16.5毫秒,只需要旋转剩余的0.17毫秒,这比以前的默认方法短四倍。

通过实现这些新功能,Morph减少了CPU花在自旋锁上的时间,减少了定时密集型游戏如Kirby Forgor💀…Kirby and the Forgotten Land和Super Smash Bros. Ultimate的CPU使用量。新的空闲资源意味着低核心数CPU(如四核)和功耗有限的系统(如笔记本电脑和手持设备)的性能会有提高。有了这个变化,我们测量到CPU使用量或功耗减少了高达24%,这取决于限制因素。

左:旧的1毫秒精度;右:当前的0.5毫秒精度。结果来自你的笔者的笔记本电脑,它运行的是单语言Windows安装,所以不要在意西班牙语。请注意,两个结果之间的CPU使用量有差异。

如果在同样的功耗范围内可以执行更多任务,就可以在不牺牲电池寿命的情况下提高性能。或者,对于仿真器来说更常见的情况是,如果帧率上限是固定的,可以降低温度。

这就是笔记本电脑之所以叫“lap”的原因,注意封装温度(Xenoblade Chronicles 3)

用户报告说,由于提高了定时器精度,游戏的音频抖动减少了。

Windows 10 SDK添加的另一个很好的工具是允许我们将yuzu设置为“HighQoS”进程,这表明如果有更高性能的内核可用,它们应该优先使用。这进一步提高了现有Ryzen CPU的性能,建议使用CCX的最佳内核,对于Intel 第12代及更高版本,优先使用P内核(“性能内核”,普通内核)。

强烈建议保持芯片组驱动程序最新,以充分利用您的硬件。

如果CPU的性能更高效,我们如何进一步发展?好吧,Morph认为下一步是改进CPU自己计时的方式!

在使用x86架构的现代CPU上,不变定时器是用RDTSC指令获取的。RDTSC的问题在于……它在较长时间内不够准确。它在多核处理器上无法做到这一点。

RDTSC提供的最佳估计与实际实际之间的细微差异会导致像Super Smash Bros. Ultimate这样的游戏出现时间漂移。我们测量的受影响最严重的CPU架构(也一直回到7月)是英特尔第12代,每分钟漂移约1秒。

Morph解决此问题的方法是启动一个额外的线程,该线程的任务是连续10秒内两次测量TSC,然后将这两个测量值的差异应用于知道这10秒内实际通过了多少个时钟周期。然后你把时钟周期数除以10,就得到了主机RDTSC定时器实际运行的准确频率。

幸好我们不必为此使用老式秒表(Super Smash Bros. Ultimate)

结果在Ryzen和Intel第11代及更早的系统上基本上是完美的定时,在第12代Alder Lake系统上是几乎完美的定时。在CPU内同时计时的完全不同的内核对这种特定应用来说不是很理想。我们无法击败英特尔混合非对称设计的本质,但我们设法将漂移从每分钟1秒减少到每5分钟左右1秒。

“好吧,这已经相当不错了”,Morph说,但我们如何进一步深入?唯一的选择是下降到汇编 语言。

这里讨论的优化目前仅适用于第12代及更高版本的英特尔CPU; AMD尚未添加对此的支持。我们说的是TPAUSE(CPUID名称为WAITPKG),这是英特尔团队新的一条指令,允许CPU进入低功耗状态,直到指定的时间过去。

需要进行一些测试来指定等待周期的正确时钟周期数;一个错误的值会在一个极端上降低精度太多,或者在另一个极端上不产生任何好处。在Morph的测试中,100000个时钟周期是神奇的数字,除了以前的好处外,还减少了高达20%的CPU使用量/功耗。

如果英特尔GPU驱动程序正常工作,装有Xe的笔记本电脑/手持设备现在将成为非常可行的yuzu游戏机……噢,运行NVIDIA或AMD实际工作的GPU驱动程序的第12/13代用户将大大受益于所有这些工作。

图形变化

够了CPU的改进。图形方面呢?嗯,我们有很多要谈的。

用户报告《牧场物语 美好的生活》有趣的颜色带差。Maide深入研究了这个问题,并确定S8_UINT颜色格式,如D32_FLOAT_S8_UINTS8_UINT_D24_UNORM是罪魁祸首。经过一番试错和bylaws(来自Skyline模拟器)的大力帮助,Maide终于解决了这些问题,提供了准确的颜色渲染,而不会破坏其他游戏。

现在你可以享受这个农场模拟游戏,体验它生动的色彩,而不必担心颜色带差。这不是很符合主题吗?(牧场物语 美好的生活)

epicboy再次出手,他这次给依然活跃的OpenGL阵营带来一些帮助,带来加速DMA的所有好处,我们在上一篇报告中讨论过。

这意味着OpenGL用户,特别是Fermi和Kepler GPU的用户,可以享受这个伪Y.F.C. 2改变带来的速度提升,使像《Metroid Prime Remastered》这样的游戏运行得更快。不必再等待Samus加载她的臂炮。

我们强烈建议没有好的Vulkan支持的老硬件用户升级到更新款,因为OpenGL支持很快就要结束了。话虽如此,感谢epicboy,那些无法升级的人使用老旧但经典的OpenGL API不会遭受可怕的性能损失。

但这还不是全部,epicboy还添加了优化 GL_SYNC_STATUS,略微提高性能。你的作者观察到《塞尔达传说 荒野之息》的性能提高了3-5%,这是OpenGL在NVIDIA硬件上运行更快的少数游戏之一,如果你忽略着色器抖动的话。

从54到57 FPS,在游戏中最繁重的地方,OpenGL仍然有生命!目前……(塞尔达传说 荒野之息)

bylaws再次来救援,指出我们的旧Vulkan调度程序实现在去年10月有些倒退,当时[byte]致力于使自制应用程序能与Vulkan一起工作。

这意味着游戏和自制应用程序将不得不等待一帧出现在屏幕上才开始渲染,在某些情况下,这是一个反馈回路最糟糕的例子。

通过在后台等待队列清空而无需等待帧显示,byte[]修复了倒退。谢谢bylaws!

还记得我们上个月谈到的那个可爱的游戏吗?上个月我们讨论过,适合所有年龄段的游戏!与家人一起玩绝对安全。

vonchenplus决定使其可玩,所以宅男世界各地的玩家可以享受《魔法少女缇娜》惊人的游戏体验,通过修复yuzu处理内联索引和绘制纹理命令的一些错误。

文化游戏(魔法少女缇娜)

Steam Deck最近的系统更新搞乱了许多游戏的图形。罪魁祸首?与VK_EXT_extended_dynamic_state3相关的一些问题,这是Vulkan扩展之一,有助于减少着色器构建抖动。

yuzu期望NVIDIA驱动程序的行为与Steam Deck上最新Mesa实现的差异,导致下面显示的问题:

看起来像有人在屏幕上泼漆了(塞尔达传说 荒野之息)

byte[] 禁用暂时导致问题的功能,但我们将考虑在将来再次启用它,因为Mesa很可能已经在他们那边修复了问题

这里有几个对Xenoblade球迷很重要的修复,Maide花了很多时间致力于修复。

游戏中的着色器由于在采样器中将sRGB边界颜色转换出错而损坏。这是一个将颜色从一个颜色空间转换到另一个颜色空间的过程。这会导致不准确,使某些受影响的着色器在错误地丢弃阴影像素时失败。

我们需要更多信息才能全面理解这个问题,但目前,忽略 sRGB采样器上的颜色空间转换可以实现硬件精确渲染。

雷克斯知道自己的未来,眨眨眼(Xenoblade Chronicles 2)

影响Xenoblade三部曲(好吧,至少是Definitive Edition和2)的另一个长期问题一直困扰着yuzu,自传奇的纹理高速缓存重写以来。这是可以在游戏过程中随时发生的随机“彩虹模式”,或者在《Xenoblade Chronicles 2》的一个特定结尾场景,我不会剧透给新玩家。如果你在yuzu上玩过,你知道是哪一个。它让人想起永远的乐土

在(云)海的彼方!(Xenoblade Chronicles 2)

另一个观察到的问题是过度的照明使整个场景无法阅读(特别是在HDR显示器上,这不是一个令人惊讶的突然闪光)。

我的眼睛!(Xenoblade Chronicles 2)

Maide发现问题是由于在环境光照cubemaps中用陈旧的主机数据替换新鲜的客人数据引起的。解决方案是只复制标记为GPU修改的数据,遵循缓冲区高速缓存重写的行为。
这不再是2009年,我们不需要这么多溢彩效果,非常感谢(《Xenoblade Chronicles:绝对版》)

有了这些变化,影响《Xenoblade Chronicles》系列的几个图像问题已经很少了,这使得它成为yuzu上从头玩到尾的一个很好的选择。然后你可以和你的作者一起辩论哪个女王是最好的。

由于这个问题只在第一次渲染过场动画时发生,我将使用错误报告截图来作弊,咬我(《Xenoblade Chronicles 2》)

新来的rschlaikjer,我希望我发音正确,一直在深入研究纹理缓存,试图弄清为什么像《Tsukihime -A Piece of Blue Glass Moon-》这样的简单视觉小说在切换场景时会滞后。也许是因为这个游戏对模拟器来说太情绪化了。

罪魁祸首是在捕获GPU页表时缺少一个引用运算符,这导致该表每秒被复制成千上万次。这会使任何人结结巴巴,更不用说模拟器了。转换捕获为引用解决了这个问题,并且它可能也会修复其他游戏中的类似问题。

我们很高兴rschlaikjer在这个bug失控之前发现了它。我们不想像那张椅子一样。

UI变更

有些问题如此隐蔽,以至于要几年才被注意到。有些问题如此复杂,需要深入理解所有涉及的层以找到正确的解决方案。这让许多开发者感到沮丧,希望其他人能有更好的运气。

然而,有些问题只是简单地愚蠢。比如游戏崩溃是因为默认的用户资料损坏了。

german77 发现一个简单的修复可以修复数十款游戏的崩溃:设置默认头像 为真实的 32x32 分辨率而不是 0x0。就是这样。

继续改进UI,german77 也移动了最后一个音频设置“后台静音音频”到音频部分,属于它的位置。不再在常规设置里寻找这个选项。

完美的顺序

下一个是一个极大提高用户体验(UX)的改进,对我个人来说也是一个巨大的安慰。以前,使用每游戏控制器配置文件时,如果你忘记在启动游戏前更改输入设置,游戏关闭后设置会丢失,下次启动时需要重新设置。

epicboy 修复了这个令人烦恼的问题,german77 合并了变更。非常感谢这个修复。

german77 也在努力改进配置文件选择浮窗。当前的更改只是开始,我们将来会继续更新任何进展。

输入改进

让我们谈谈输入,german77 在此方面继续表现出色。

german77对使用鼠标和键盘玩《Metroid Prime Remastered》的体验不满意,将默认的鼠标灵敏度调整为50%,去除了平滑过滤器,这在高DPI游戏鼠标的反馈下提高了性能。他还降低了运动阈值,限制了旋转速度,并累积所有输入直到交付,这修复了以前实现的延迟和 jerkiness。

你注意到萨姆斯缺乏前方指示器了吗?她的盔甲不能再多分配一点点处理能力给那个吗?(Metroid Prime Remastered)

由于这些变化,《Metroid Prime Remastered》表现出它可以是一款很棒的PC游戏。如果只是任天堂让它出牢房。

我们常常会得到的一个问题是“第三方Switch控制器会工作吗?”简短的回答是也许,但是长期的回答要复杂一点。

据任天堂的API,Joy-Cons有两种模式:主动模式和被动模式。官方Joy-Cons使用主动模式,但是一些第三方控制器使用被动模式,通常是因为它们不遵循API的要求,不支持任何配置命令。它们只是默认设置运行,好的一面或坏的一面。

这并不意味着被动控制器没有用。它们依然在Switch上运作。但是这意味着它们以不同的方式工作。主动控制器每15毫秒更新一次状态,而被动控制器只在某些事件发生时更新,比如按钮按下或释放。

事实证明,yuzu直到现在还不支持被动模式!所以,german77的变更使许多第三方控制器用户高兴。考虑到市面上有那么多非官方控制器,这实在是方便。

与震动的战斗仍在继续!在日常研究中,german77发现如果你有多名玩家使用相同类型的控制器,或者如果你使用双Joy-Con设置与单个控制器,你可能会连续两次向同一控制器发送震动命令。这可能令人烦恼,也会占用有限的蓝牙连接带宽。

解决方案很简单: 对每个控制器只取凉爽震动队列中的最新元素,检查控制器是否可以处理请求的震动,并忽略其余的。

我们都喜欢生活质量的改进,对吧?即使它们不太显眼。

让我们谈谈“控制器应用程序”,它负责在游戏请求时提示玩家选择输入设置。到现在为止,应用程序是不可跳过的;你必须给出有效的答案才能继续你的游戏。虽然这还可以接受,但令人烦恼且不准确。如果玩家无法或不愿确认输入方式,有些游戏会返回到以前的菜单而不是陷入无尽的循环。

你应该通过!

german77解决了这种行为,同时也解决了玩家数不正确的bug。

german77实现了……给我喘口气,SetNpadJoyAssignmentModeSingleWithDestination服务调用。他实现它希望使《Let’s Get Fit》可玩,但不幸的是,还有更多障碍。

转讲Amiibo支持,这个月发生了很多事情。

首先,german77设法编写正确的循环冗余校验,使yuzu写的Amiibo数据与Switch兼容;不再是无效信息。

其次,如果你试图在扫描Amiibo时连接控制器,它将无法被识别。通过考虑此情况并初始化或结束控制器,他修复了问题。

最后但并非最不重要的,为了完成Amiibo的故事,Herman the German Sherman 添加了支持普通Amiibo文件。一些Amiibo,比如《Super Smash Bros. Ultimate》主题的Amiibo,可以在没有密钥的情况下编辑。现在,yuzu可以正确读取你的Amiibo中的非加密游戏数据!

音频修复

Maide设法发现了读取混响预延迟线的一个错误,导致输出问题。通过正确读取输入而不是输出来解决这个问题,可以给像《New Super Mario Bros. U Deluxe》这样的游戏提供适当的音频。现在你可以享受马里奥的声音而没有任何回音。妈妈米娅!

bylaws一直在深入研究音频同步,在这里和那里改进代码库,并通过将来宾样本跟踪链接到主机来避免延迟。

这个变化导致了一些倒退,因为一些游戏对音频调度要求非常敏感。用户报告合并后出现爆破声,所以bylaws通过添加15毫秒的延迟来改善样本计数报告情况。

其他代码变化

《Fire Emblem》的粉丝在游戏中遇到了冻结,经过一些调查,Morph发现罪魁祸首是behunin的拉取请求引入的有界线程安全队列。

该队列的工作是将事件从事件生产者(如CPU内核)传递给事件消费者(如GPU线程)。behunin替换的以前的实现会不断分配和释放内存,导致定期的延迟峰值。

解决这个问题的方法是将队列转化为有界队列,这意味着不需要内存分配,因为有固定数量的资源可用。这就是behunin所做的,但新的队列实现似乎有bug。Morph添加了一个简化的实现,修复了影响《Fire Emblem: Three Houses》和《Fire Emblem Engage》的新游戏冻结。

你的作者根据上次为Windows做的变化重新启用了GCC构建的LTO,但只将优化应用于core和video_core子项目,为Linux用户提供了漂亮的免费性能提升。

硬件部分

AMD 23.3.2和更新的驱动程序

一个坏消息和两个好消息。

在积极的方面,AMD终于在最新的Windows驱动程序发行版中添加了对缺失的动态状态扩展的支持,这可以改善着色器构建时间和减少Radeon GPU的滞后,使其性能与NVIDIA持平。

然而,在消极的方面,这个驱动程序更新也引入了一个严重的倒退:

这可能会影响你的整个桌面(《Metroid Prime Remastered》)

一些游戏,如《Metroid Prime Remastered》和《Pokémon Legends: Arceus》,触发了似乎是越界崩溃,导致桌面损坏和驱动程序崩溃。我们建议用户目前暂时使用23.3.1或更早版本的驱动程序。一些较旧的Radeon卡可能也会受益于使用23.2.2。

我们向AMD报告了这个问题,他们迅速确认了它,重现了它,并告知我们他们正在修复这个问题。

现在就是你如何进行客户支持。

说到客户支持…

做英特尔的工作

在测试《塞尔达传说:旷野之息》的一个关键渲染修复(我们将在下月讨论)时,Morph进行了一些功能测试来调查是什么使英特尔的Windows驱动程序运行得如此糟糕。

他的发现既预期又令人失望。导致大约95%的崩溃的主要原因是驱动程序中的一个故障的计算着色器阶段。像我们过去对较旧的英特尔硬件做的那样禁用计算着色器,可以使大多数游戏运行,但不是全部。我们仍然不知道在打开《Xenoblade Chronicles 3》菜单时造成崩溃的原因。

我们现在正在努力弄清楚是什么触发计算着色器像这样崩溃驱动程序,但这也提出了一个困境。我们应该自己修补这个问题,使游戏渲染变差并让英特尔摆脱困境,还是应该将其保留破损状态,以便他们必须妥善修复它?

在调查继续的过程中,解决方案是使用可靠的Linux,或避免购买仅依赖英特尔GPU的硬件。唉。

未来项目

我们甚至还没有过半4月,我已经对进度报告中的下个月要发生的事情感到兴奋。开发人员正在火热工作,他们很快不会停下来。

Maide正在继续改进Xenoblade系列,如修复《Xenoblade Chronicles 2》中的云闪烁,《Xenoblade Chronicles 3》中的粒子效果以及影响整个传说和其他游戏的纹理闪烁。然而,这些修复会带来性能损失,所以他需要其他GPU开发人员的帮助来优化它们。也许Blinkhawk可以提供帮助?

任天堂贡献发布了Vulkan扩展的圣杯,VK_EXT_shader_object。该扩展有望大大减少构建着色器所需的工作量,正如其依赖项所暗示的,它需要支持所有以前的动态状态扩展。

很可能任天堂打算在其内部仿真器中使用它,也许是为了“向后兼容”。不管怎样,我们有很多工作要做,以支持这个扩展。

但够了。让我们谈谈一些令人兴奋的正在进行的项目。

笛声加强

关于Gaia项目:它仍在开发中。

哦,和Lime项目处于发行候选状态,正在经受激烈的内部测试。

就是这样!谢谢你坚持阅读这份进展报告直到结束。

谢谢bing聊天提供的糟糕笑话。


Claude in Slack

大家好,yuzu玩家们!我们一如既往地努力工作,3月份在性能、图形、音频、CPU精度、输入等方面都有所改进!

让CPU远离“嗡嗡”的噪音

这个月最大的变化是CPU准确性的改进。这需要一些倒带,让我们稍微回顾一下。
7月份,我们解释了“CoreTiming”目前的运作方式,使用主机定时器。一个叫“HostTiming”的线程用于处理HLE事件,如输入和音频。然而,像音频这样的某些事件需要高级定时器精度才能像游戏所期望的那样运行,这超过了Windows通常允许的范围。
默认情况下,Windows只允许1毫秒的精度,因为操作系统事件循环以1000赫兹运行。这是不够的。然而,运行Linux、BSD和MacOS的设备不面临此限制,可以达到微秒(微秒)级精度。
如果一款游戏要以16.67毫秒的帧时间(60 FPS)运行,您可以三分之二的时间等待17毫秒,其余三分之一的时间等待16毫秒,但这在过去已经证明对音频精度非常糟糕。另一种方法,也是Windows过去使用的老方法,是等待16毫秒,然后忙等待0.67毫秒。在这0.67毫秒内,CPU线程什么也不做,消耗功率但实际上并没有工作。
这里出现了不再支持Windows 7和8/8.1的好处。Windows 10 SDK有新的未公开函数NtSetTimerResolutionNtDelayExecution,可以将定时器分辨率提高到0.5毫秒。这使yuzu可以等待16.5毫秒,只需要旋转余下的0.17毫秒,比以前的默认方法短四倍。
通过实现这些新函数,Morph减少了CPU在自旋锁中花费的时间,从而减少了时序密集型游戏如《克比复活》和《超级马里奥大乱斗》的CPU使用。新的资源空闲意味着四核CPU等低核心数CPU以及笔记本电脑和手持设备等电源有限系统的更好性能。通过此更改,我们测量到高达24%的CPU使用或功耗降低,具体取决于限制因素。
左侧:旧的1毫秒精度;右侧:当前的0.5毫秒精度。结果来自您作者的笔记本电脑,运行单一语言Windows安装,所以不要在意西班牙语。请注意,两个结果之间的CPU使用率有所不同。
如果您可以在相同的功率包络内执行更多任务,您可以提高性能而不牺牲电池寿命。或者,对于模拟器来说更常见的情况是,如果您的上限是固定的帧率,您可以降低温度。
这就是为什么笔记本电脑中的“书”是一个谎言,要注意封装温度(《Xenoblade编年史3》)
用户报告说,由于改进了定时器精度,游戏的音频抖动减少了。
Windows 10 SDK添加的另一个很好的工具是允许我们将yuzu设置为“HighQoS”进程,这表明如果有高性能核心可用,Windows调度程序应优先考虑使用它们。这进一步提高了目前Ryzen CPU的性能,建议使用CCX中的最佳核心,对于Intel第12代及更高版本,建议优先使用P核心(“性能核心”,常规核心)。
强烈推荐保持芯片组驱动最新,以最大限度地利用您的硬件。
如果CPU以更高效的方式运行,我们如何进一步超越?嗯,Morph发现下一步是改进CPU自身计时的方式!
在使用x86架构的现代CPU上,不变定时器是用RDTSC指令获取的。RDTSC的问题是……在较长时间内它不是很准确。在多核处理器上,它无法实现这一点。
RDTSC提供的最佳估计值与实际实际之间的小差异会导致《超级马里奥大乱斗》等游戏出现时间漂移。您可能会注意到这个问题以不准确的比赛时间的形式显现出来。我们测量的受影响最严重的CPU架构是Intel第12代(也早在7月),误差可达每分钟1秒。
Morph解决此问题的方案是启动一个额外的线程,其任务是测量TSC 10秒的两次测量,然后将该差异应用于知道前10秒实际通过了多少个滴答声。然后,将滴答声数除以10,就可以得到主机RDTSC定时器运行的精确频率。
幸好我们不必为此使用旧的秒表(《超级马里奥大乱斗》)
结果对Ryzen和Intel第11代及以前的系统来说是几乎完美的计时,对第12代Alder Lake系统来说是_几乎_完美的计时。CPU内同时计时的完全不同的内核对这一特定应用程序来说并不漂亮。我们无法打败Intel设计的混合非对称性质,但我们设法将漂移从每分钟1秒减少到每5分钟左右1秒。
“好吧,这相当不错”,Morph说,但是您如何进一步深入?唯一的选择是下沉到汇编语言。
该优化目前仅适用于Intel第12代及更高版本CPU;AMD尚未添加对其的支持。我们谈论的是TPAUSE(CPUID名称WAITPKG),这是英特尔新推出的一条指令,允许CPU进入较低功耗状态并空闲,直到指定的时间量过去。
需要进行一些测试来指定正确的等待周期的时钟周期数;错误的值会在一个极端上太大程度地降低精度,在另一个极端上不会产生任何好处。在Morph的测试中,100000个时钟周期是神奇的数字,它在之前的好处之上进一步降低了CPU使用率/功耗高达20%。
如果Intel GPU驱动程序起作用,配备Xe的笔记本电脑/手持设备现在将成为非常可行的yuzu游戏机……唉,运行NVIDIA或AMD实际工作的GPU驱动程序的第12代/第13代用户将从所有这些工作中受益匪浅。

图形变化

大家好!3月份在图形方面也有很多进展。
用户报告《STORY OF SEASONS:美好的生活》出现有趣的色带现象。Maide深入研究了这个问题,发现S8_UINT色彩格式,如D32_FLOAT_S8_UINTS8_UINT_D24_UNORM是罪魁祸首。通过反复试验和bylaws的大力帮助,Maide最终解决了这个问题,提供了精确的色彩渲染,而不影响其他游戏。
现在您可以尽情享受这款农场模拟游戏的色彩鲜艳了,不用再担心色带问题。这个进展不是很惬意吗?
epicboy再次发动突袭,这次他对OpenGL团队表现出的爱意,带来了我们上个月讨论的AccelerateDMA的所有好处。
这意味着OpenGL用户,尤其是拥有Fermi和Kepler GPU的用户,可以享受这种伪Y.F.C. 2变化带来的速度提高,使像《Metroid Prime 重制版》等游戏运行得更快。不用再等萨穆斯装填她的手臂炮了。
我们强烈建议没有很好的Vulkan支持的老硬件用户升级到更新的硬件,因为OpenGL的支持很快就要结束了。尽管如此,多亏了epicboy,那些无法升级的用户使用老而弥足珍贵的OpenGL API不会遭受糟糕的性能。
不仅如此,epicboy还为GL_SYNC_STATUS增加了一项优化,稍微提高了性能。笔者观察到《塞尔达传说 旷野之息》的性能提高了3-5%,这是少数在NVIDIA硬件上OpenGL运行更快的游戏之一,如果忽略着色器的不适感。
从54 FPS提高到57 FPS,在游戏最繁重的地方,OpenGL还活着!现在……
bylaws再次伸出援手,指出我们以前的Vulkan调度程序实现在去年10月有些退步,[byte]当时致力于使Homebrew应用程序与Vulkan兼容。
这意味着游戏和Homebrew程序必须等待画面显示才能开始渲染,在某些情况下这是反馈循环最坏的例子。
通过在后台等待队列清空而不必等待画面呈现,byte[]修复了此回退。谢谢bylaws!
还记得我们上个月谈到的那款适合所有年龄段的游戏吗?完全安全,可以与家人一起玩。
vonchenplus决定使其可玩,以便世界各地的宅男玩家可以享受《Moero Crystal H》惊人的游戏性,通过修复yuzu处理内联索引和绘制纹理命令的一些错误。
文化游戏(Moero Crystal H)
Steam Deck最近的系统更新搞乱了许多游戏的图形。罪魁祸首?与VK_EXT_extended_dynamic_state3有关的问题,这是Vulkan扩展之一,有助于减少着色器构建的卡顿。
yuzu期望NVIDIA驱动程序的行为以及Deck上最新的Mesa实现之间的差异导致了您下一步看到的情况:
看起来好像有人在屏幕上洒了点油漆。(塞尔达传说 旷野之息)
byte[] 禁用暂时导致这个问题的功能,但由于Mesa很有可能已经修复了他们端的问题,我们以后会重新考虑 turning 它开启。
这里有几个对Xenoblade粉丝很重要的修复,Maide花了很多时间来解决。
着色器在游戏中无法正常工作,因为采样器中的sRGB边框颜色转换存在问题。这是一个将颜色从一个色彩空间转换到另一个色彩空间的过程。这会导致不准确,使一些检查在受影响的着色器上失败,导致错误地丢弃像素作为阴影。
我们需要更多信息才能完全理解这个问题,但目前,忽略sRGB取样器上的色彩空间变换允许硬件精确渲染。
雷克斯知道未来为他准备了什么,眨眼(Xenoblade编年史2)
自传奇的贴图缓存重写起,Xenoblade三部曲(至少是Definitive Edition和2)一直困扰着yuzu的另一个长期问题。这是在游戏过程中随时可能发生的随机“彩虹模式”,或者在《Xenoblade编年史2》的某个后期 cutscene 中发生,我不会给新玩家剧透。如果你在yuzu中玩过,你知道是哪一个。这让你觉得自己是否在Rapture。
海的彼岸!(Xenoblade编年史2)
另一个观察到的问题是过度照明使整个场景无法阅读(特别是在HDR显示器的夜晚,突然的闪光不是一个愉快的体验)。
我的眼睛!(Xenoblade编年史2)
Maide发现这个问题是由用过期的主机数据替换环境照明cubemaps中的新来宾数据导致的。解决方案是只复制已标记为GPU修改的数据,遵循缓冲区高速缓存重写的行为。
这不是2009年,我们不需要这么多bloom,非常感谢(Xenoblade chronicles:最终版)
在这些更改之后,影响Xenoblade编年史系列的图形问题很少,这使得从头玩到尾在yuzu上玩成为一个很好的选择。然后你可以加入你的作者来辩论哪个女王是最好的。
由于这个问题只在第一次渲染cutscene时发生,我将使用bug报告图片作弊,咬我一口(Xenoblade编年史2)
新人rschlaikjer,我希望我发音正确,一直在深入研究纹理高速缓存,试图找出为什么像《月姬-蓝色玻璃月亮的碎片-》这样简单的视觉小说在换场时会发生结巴。也许是因为游戏对仿真器来说太情绪化了。
罪魁祸首是在捕获GPU页面表时缺少引用运算符,这导致该表被每秒复制数千次。这会让任何人结巴,更不用说仿真器了。将捕获转换为引用解决了这个问题,也可能修复其他游戏中的类似问题。
我们很高兴rschlaikjer在问题操控不住之前发现了这个bug。我们不想变成那把椅子。

UI更改

有些问题难以发现,以致于多年来无人注意。有些问题非常复杂,需要深入理解所有涉及的层面才能找到正确的解决方案。它们让许多开发人员感到沮丧,希望其他人能有更好的运气。
而有些问题就是简单的荒谬。比如游戏因默认用户资料损坏而崩溃。
german77发现了一个简单的修复,解决了几十款游戏的崩溃问题:将默认个人资料图片设置为真实的32x32分辨率,而不是0x0。就这样。
继续改进UI,german77还将最后的音频设置“背景音频静音”移至音频部分,这是它应有的位置。不再需要在常规选项中搜索此选项。
良好的恰当顺序
下一个是UX(用户体验)的大改进,对我个人来说也是一个巨大的解脱。以前,使用每个游戏的控制器配置文件时,如果你忘记在启动游戏前更改输入设置,关闭游戏后将失去这些设置,下次启动时需要重新设置。
epicboy 修复了这个烦人的问题,german77合并了更改。非常感谢修复这个问题。
german77也在努力改进配置文件选择小程序。当前的更改只是开始,我们将在未来随着任何进展更新您。

输入改进

让我们谈谈输入,这是german77继续发挥作用的地方。
不满足于[玩]下()时的鼠标和键盘体验,german77将默认鼠标灵敏度设定为50%,并删除平滑过滤器,在收到Metroid粉丝的宝贵反馈后,改进了高DPI游戏鼠标的性能。他还降低了运动阈值,限制了旋转速度,并累积所有输入直到交付,这修复了以前实现的延迟和断续性。
你有没有注意到萨姆斯缺乏导航指示器?她的服装难道不能再多花一点处理能力在那上面吗?(Metroid Prime Remastered)
由于这些改变,《Metroid Prime Remastered》表明它可以成为一款很棒的PC游戏。如果任天堂能让它出狱的话。
我们常常收到的一个问题是“这个第三方Switch控制器是否正常工作?”简短的答案是也许,但长期的答案稍微复杂一点。
根据任天堂的API,Joy-Cons有两种模式:主动模式和被动模式。官方Joy-Cons使用主动模式,但某些第三方控制器使用被动模式,通常是因为它们没有正确遵守API,不支持任何配置命令。它们只是默认设置运行,好坏参半。
这并不意味着被动控制器无用。它们仍然可以在Switch上工作。但这意味着它们的工作方式不同。主动控制器每15毫秒更新一次状态,而被动控制器只在发生某些事情时更新,例如按键按下或释放。
事实证明,yuzu直到现在还不支持被动模式!所以german77的更改使许多第三方控制器用户感到高兴。考虑到有那么多非官方控制器,这相当方便。
与振动的斗争还在继续!在进行平常的研究时,german77发现如果你有多个玩家使用同一类型的控制器,或者如果你使用一个单独的控制器使用双Joy-Con配置,你可能会连续两次向同一个控制器发送振动命令。这可能令人烦恼,而且还会占用蓝牙连接的有限带宽。
解决方案很简单:对每个控制器只取振动队列中的最新元素,检查控制器是否可以处理请求的振动,忽略其余的。
我们都喜欢生活质量的变化,对吧?即使它们不是很令人眼前一亮。
让我们谈谈“控制器小程序”,它负责在游戏请求时提示玩家选择输入设置。到目前为止,小程序是不可跳过的;您必须给出有效的答案才能继续游戏。虽然这可接受,但它既麻烦又不准确。如果玩家无法或不确认输入方式,某些游戏会返回至上一菜单而不是陷入无休止的循环。
你通过了!
german77解决了这个行为,在此过程中也修复了玩家数不正确的bug。
german77实现了…等等,让我先喘口气,SetNpadJoyAssignmentModeSingleWithDestination服务调用。他实现了它,希望使《Let’s Get Fit》可玩,但不幸的是还有更多问题。
改变话题到Amiibo支持,这个月发生了很多事情。
首先,german77设法写下正确的CRC,使yuzu写入的Amiibo数据与Switch兼容;不再显示无效信息。
其次,如果你尝试在扫描Amiibo时连接控制器,它将不被识别。通过考虑这一点并初始化或完成控制器,他修复了该问题。
最后但并非最不重要的,为了总结Amiibo传奇,Herman the German Sherman 添加了支持普通Amiibo文件。某些Amiibo,如《超级马里奥大乱斗终极版》主题的Amiibo,可以在不需要密钥的情况下编辑。现在,yuzu可以正确读取您Amiibo中的非加密游戏数据!

音频修复

Maide设法发现读取混响前延迟线的方式存在bug,导致输出问题。通过正确读取输入而不是输出,使像《New超级马里奥兄弟U Deluxe版》这样的游戏获得适当的音频。现在你可以享受马里奥的声音而没有回声。妈妈米亚!
bylaws一直在深入研究音频同步,改进代码库这里和那里,并设法通过将来宾样本跟踪链接到主机来避免停顿。
此更改导致一些回归,因为某些游戏对音频调度要求_非常敏感_。用户在合并后报告出现爆裂声,所以bylaws通过添加报告样本计数的常量15毫秒延迟改善了情况。

其他代码更改

《火焰之纹章》的粉丝在游戏中经历冻结,经过一些调查,Morph发现罪魁祸首是有限线程安全队列,这是behunin的一个拉取请求引入的。
这个队列的工作是将事件从事件生产者(如CPU核心)传递给事件消费者(如GPU线程)。behunin替换的以前的实现不断分配和释放内存,导致定期出现延迟峰值。
解决此问题的方法是将队列转变为有限队列,这意味着不需要内存分配,因为有固定数量的资源可用。这就是behunin所做的,但新的队列实现似乎有bug。Morph添加了一个简化的实现,修复影响《火焰之纹章:风花雪月》和《火焰之纹章约书》的新游戏冻结。
您的作者重新启用了GCC构建的LTO,遵循上次对Windows所做的更改,但仅将优化应用于内核和视频内核子项目,为Linux用户提供免费的性能提升。

硬件部分

AMD 23.3.2和更新的驱动程序

一个坏消息和两个好消息。
在积极的方面,AMD最终在其最新Windows驱动程序发布中添加了缺失的动态状态扩展支持,这可以改善着色器构建时间和减少Radeon GPU的卡顿,使其性能与NVIDIA持平。
然而,在负面方面,此驱动程序更新也引入了一个严重的回归:
这可能影响您的整个桌面(《MetroidPrime重制版》)
某些游戏,如《MetroidPrime重制版》和《神奇宝贝传说:阿尔宙斯》,触发了似乎是越界崩溃的情况,导致桌面损坏和驱动程序崩溃。我们建议用户现在暂时使用23.3.1或更早版本的驱动程序。一些较早的Radeon卡可能也会受益于使用23.2.2。
我们向AMD报告了此问题,他们迅速确认,重现并通知我们他们正在修复此问题。
这就是如何进行客户支持。
说到支持……
做英特尔的工作
在测试下月将讨论的《塞尔达传说:荒野之息》的关键渲染修复时,Morph进行了一些功能测试来调查是什么使英特尔Windows驱动程序运行如此糟糕。
他的发现既是预期的也令人失望。造成大约95%崩溃的主要罪魁祸首是驱动程序中的有缺陷的计算着色器阶段。像我们过去用于较旧的英特尔硬件一样禁用计算着色器可以使大多数游戏运行,但不是全部。我们仍然不知道在打开《Xenoblade Chronicles 3》菜单时崩溃的原因。
我们现在正在试图弄清楚是什么触发计算机着色器崩溃驱动程序,但这也提出了一个困境。我们自己修补这个问题,使游戏渲染变差,让英特尔摆脱困境,还是应该让它保持故障状态,以便他们可以正确修复它?
在调查继续的过程中,解决方案是使用可靠的Linux,或避免购买仅依赖于英特尔GPU的硬件。叹息。

未来项目

我们还没过完四月,我已经对下次进度报告中的内容兴奋不已。开发人员正在疯狂工作,他们短期内不会停下来。
玛伊德正在为Xenoblade系列进行更多改进,例如修复《Xenoblade Chronicles 2》中的云闪烁,《Xenoblade Chronicles 3》中的粒子效果以及影响整个系列和一些其他游戏的纹理闪烁。然而,这些修复以性能为代价,所以他需要另一位GPU开发者的帮助进行优化。也许Blinkhawk可以帮忙?
任天堂贡献于发布Vulkan扩展的圣杯,VK_EXT_shader_object。这个扩展承诺大大减少构建着色器所需的工作量,正如其依赖关系所提示的,需要支持所有以前的动态状态扩展。
很可能任天堂打算在内部模拟器中使用它,也许是为了“向后兼容性”。无论如何,我们在添加对此扩展的支持方面还有很多工作要做。
但暂且不谈这个。让我们谈谈正在开发的一些令人兴奋的项目。
长笛加强版
关于盖亚计划:它仍在开发中。
哦,还有Lime项目处于候选发布状态,正在进行密集的内部测试。
就是这些了!谢谢您坚持到这个进度报告的结尾。
感谢Bing聊天的糟糕笑话。


百度机翻

你好,yuz-ers!我们像往常一样努力工作,今年3月看到了性能、图形、音频、CPU精度、输入等方面的改进!

使CPU与BRRRR相反
本月最大的变化之一是CPU精确度的提高。这需要一些回溯,所以让我们稍微倒退一下。

返回7月,我们解释了如何堆芯定时使用主机计时器以其当前形式运行。一个名为主机计时用于处理输入和音频等HLE事件。然而,其中一些事件(如音频)需要高水平的计时器精度,才能按照游戏预期的方式进行操作,超出了Windows通常允许的范围。

默认情况下,Windows只允许1ms的精度,因为操作系统事件循环以1000Hz的频率运行。这还不够。然而,运行Linux、BSD和MacOS的设备不受此限制,可以达到μs(微秒)级的精度。

如果游戏想以16.67毫秒(60 FPS)的帧速运行,您可以在三分之二的时间内等待17毫秒,在剩下的三分之一的时间内,等待16毫秒,但这在过去已经被证明对音频准确性非常不利。另一种方法是等待16ms,而繁忙等待0.67ms。在0.67ms的时间内,CPU线程什么都不做,并且在实际工作之前消耗电量。

这是删除对Windows 7和8/8.1支持的好处。Windows 10 SDK具有新的未记录功能,NtSetTimer分辨率和Nt延迟执行,可以将计时器分辨率提高到0.5ms。这允许yuzu等待16.5毫秒,只旋转剩余的0.17毫秒,这比之前的默认方法短了四倍。

通过实施这些新功能, 莫尔夫减少了CPU在自旋锁中花费的时间,从而减少了像Kirby Forgor这样的计时密集型游戏的CPU使用💀…柯比和被遗忘的土地、和超级粉碎兄弟终极版.新的免费资源意味着低核CPU(如四核)和功率预算有限的系统(如笔记本电脑和手持设备)的性能会更好。通过这一改变,我们测量到CPU使用或功耗减少了24%,具体取决于限制因素。

左:旧1ms精度;右:电流0.5ms精度。结果来自于作者的笔记本电脑,它运行单语言Windows安装,所以不要介意西班牙语。请注意,这两个结果在CPU使用方面存在差异

如果您可以在同一功率范围内执行更多任务,则可以在不牺牲电池寿命的情况下提高性能。或者,对于模拟器来说,更常见的情况是,如果您的天花板是固定帧速率,则可以降低温度。

这就是为什么笔记本电脑中的圈是一个谎言,请注意包的温度(Xenoblade Chronicles 3)

用户表示,由于计时器精度的提高,游戏的音频断断续续的现象减少了。

Windows 10 SDK添加的另一个不错的工具是允许我们将yuzu设置为高QoS进程,提示Windows调度程序如果有更高性能的内核可用,它们应该优先。这进一步提高了当前Ryzen CPU的性能,建议使用CCX的最佳内核,并通过优先考虑P-core(“性能内核”,即普通内核)来提高Intel第12代及更新代的性能。

强烈建议保持芯片组驱动程序最新,以充分利用您的硬件。

如果CPU以一种更高效的方式执行,我们如何进一步超越它?好吧,Morph认为下一步是改进CPU计算时间的方式!

在使用x86体系结构的现代CPU上,使用RDTSC公司说明。RDTSC的问题是……它在较长时间内不准确。它不能在多核处理器上。

RDTSC提供的最佳估计值与实际情况之间的微小差异导致了游戏中的时间漂移超级粉碎兄弟终极版.你可能会注意到这个问题的丑陋之处在于比赛时间不准确。英特尔第12代是我们测量的受影响最大的CPU体系结构(也是早在7月份),每分钟只差一秒钟。

Morph的解决方案这个问题的解决方法是生成一个额外的线程,该线程的任务是在10秒钟内对TSC进行两次测量,然后计算差值并应用它来知道在前10秒钟内实际经过了多少次滴答。如果将刻度数除以10,则可以得到主机RDTSC计时器运行的准确频率。

幸好我们不必使用旧秒表(Super Smash Bros.Ultimate)

其结果是在Ryzen和Intel第11代及更早的系统上实现了几乎完美的定时,以及几乎第12代阿尔德湖系统的完美时机。对于这个特定的应用程序来说,在CPU中同时使用完全不同的内核计算时间并不合适。我们无法击败英特尔设计的混合不对称特性,但我们设法将漂移从每分钟一秒减少到每5分钟一秒左右。

“好吧,这很好”,莫尔夫说,但你怎么能走得更深呢?剩下的唯一选择是放置到程序集。

该优化目前仅适用于第12代及更新版本的Intel CPU;AMD尚未添加对它的支持。我们正在谈论TPAUSE公司(CPUID名称WAITPKG(等待包装))是Team Blue发出的一条新指令,它允许CPU进入低功耗状态并空闲,直到经过一段精确的时间。

需要进行一些测试来指定等待期的正确循环数;错误的值会使一个极端的精度降低太多,或者对另一个极端没有任何好处。在Morph的测试中,100000个周期是一个神奇的数字,它将CPU使用/功耗降低了20%,超过了之前的优势。

如果仅Intel GPU驱动程序工作,他们配备Xe的笔记本电脑/手持设备现在将成为非常可行的yuzu游戏机…哦,好吧,运行NVIDIA或AMD实际工作GPU驱动程序的第12/13代用户将从所有这些工作中受益匪浅。

图形更改
CPU的改进已经足够了。图形呢?好吧,我们有很多事情要谈。

用户报告上有有趣的色带季节的故事:美好的生活.少女深入调查问题,并在S8_互联网颜色格式,如D32_FLOAT_S8_互联网和S8_UINT_D24_正常.经历了一些尝试和错误,以及来自伟人的巨大帮助规章制度(来自天际线模拟器),Maide设法解决了问题,提供了精确显色在不破坏其他游戏的情况下。

现在,你可以享受这个农业模拟器,它的所有鲜明的色调,而不必担心色带。那不是在叫吗?(季节的故事:美好的生活)

史诗般的男孩他的忍者更新再次出击。这次他对仍在蓬勃发展OpenGL帮派,带来了加速DMA,我们在上次报告.

这意味着OpenGL用户,尤其是那些使用费米和开普勒GPU的用户,可以享受这种伪Y.F.C.2更改带来的速度提升,从而制作出如下游戏Metroid Prime重装跑得更快。再也不用等萨默斯装上手炮了。

我们强烈建议没有良好Vulkan支持的旧硬件用户升级到新的硬件,因为OpenGL支持即将结束。这就是说,多亏了epicboy,那些无法升级的人不会因为使用旧的但金色的OpenGL API而受到糟糕的性能影响。

但还不止这些,史诗男孩还添加了一个优化对于GL_SYNC_STATUS(GL_SYNC状态),略微提升性能。您的作者观察到塞尔达传说:野性的呼吸如果你忽略了着色器的结巴,这是在使用NVIDIA硬件的OpenGL上运行速度更快的少数游戏之一。

在游戏中最重的位置之一,从54到57 FPS,OpenGL仍然有生命力!现在…(塞尔达传说:野性的呼吸)

细则再次出手相救,指出我们的旧Vulkan调度器实现出现了一些退化回到10月份去年的时候字节[]致力于使自制应用程序与Vulkan协同工作。

这意味着游戏和自制软件在开始渲染之前必须等待屏幕上出现一帧,在某些情况下,这是反馈循环最糟糕的一个例子。

由在后台等待为了清空队列而不必等待显示帧,byte[]修复了回归。谢谢你的规章制度!

还记得我们谈论过的那个可爱的游戏吗上个月?适合所有年龄段的人!和家人一起玩绝对安全。

冯琴普卢斯决定让它可以玩,所以小虫世界各地的玩家都可以享受Moero水晶H,由固定yuzu处理内联索引和绘制纹理命令时出现了一些错误。

文化游戏(Moero Crystal H)


蒸汽甲板最近的系统更新在许多游戏中扰乱了图形。罪犯?一些问题VK_EXT扩展动态状态3是Vulkan扩展之一,有助于减少着色器构建的混乱。

yuzu期望NVIDIA驾驶员行为的结合,以及甲板上最新Mesa实现的差异,导致了您接下来看到的内容:

看起来有人在屏幕上洒了一些颜料(塞尔达传说:狂野的呼吸)

字节[]禁用目前导致问题的功能,但我们将重新考虑在未来再次启用它,因为它很可能是Mesa已经解决了问题在他们这边。

这里有几个针对Xenoblade粉丝的重要修复,Maide花了大量时间进行修复。

由于采样器中sRGB边界颜色转换的问题,着色器在游戏中被破坏。这是一个将颜色从一个颜色空间转换为另一个颜色的过程。这将导致不准确,导致某些检查在受影响的着色器上失败,从而导致将错误的像素作为阴影丢弃。

我们需要更多信息来全面了解这个问题,但目前,忽略sRGB采样器上的颜色空间变换允许硬件精确渲染。

雷克斯知道他的未来,眨眨眼(《氙气历代志》2)

另一个影响《异形三部曲》的长期问题(好吧,《最终版》,至少有2部)自传说发生以来一直困扰着尤祖纹理缓存重写.这是一种随机的“彩虹模式”,可以在游戏过程中的任何时候发生,也可以在特定的后期游戏场景中发生氙气编年史2我不会宠坏新球员。如果你用玉祖演奏,你知道是哪一个。这让你怀疑自己是否在狂喜.

在(云)海之外的某处!(氙气编年史2)

另一个观察到的问题是过度照明使整个场景无法阅读(尤其是在晚上使用HDR显示器时,不是一个令人愉快的突然闪光)。

我的眼睛!(氙气编年史2)

Maide发现问题是由更换环境照明立方体中的新来宾数据和陈旧主机数据。解决方案是仅复制已标记为GPU修改的数据,遵循缓冲区缓存重写.

JuxtaposeJS
这不是2009年,我们不需要这么多开花,非常感谢(Xenoblade编年史:最终版)

随着这些变化,很少有图形问题仍然影响着Xenoblade Chronicles的传奇故事,这使得它成为一个从头到尾欣赏yuzu的好选择。然后你可以和你的作家一起辩论哪个女王是最好的。

JuxtaposeJS
由于这个问题只在第一次渲染场景时发生,所以我会使用错误报告图片作弊,咬我一口(Xenoblade Chronicles 2)

新来的人rschlaikjer公司,我希望我说得对,一直在深入挖掘纹理缓存,试图找出为什么像筑岛——一片蓝色的玻璃月亮-换场景时会结巴。也许是因为游戏太情绪化了,模拟器无法处理。

罪魁祸首是捕获GPU页表时缺少引用运算符,这导致该表每秒重复复制数千次。这会让任何人结巴,更不用说模拟器了。正在转换对引用的捕获解决了这个问题,也可能修复其他游戏中的类似问题。

我们很高兴rschlaikjer在这个问题失控之前发现了它。我们不想这样结束那把椅子.

UI更改
有些问题是如此难以捉摸,以至于多年来都没有人注意到。有些问题非常复杂,需要深入了解所涉及的所有层才能找到正确的解决方案。他们让许多放弃的开发人员感到沮丧,希望其他人会有更好的运气。

有些问题简直是愚蠢透顶。就像游戏因为默认用户配置文件损坏而崩溃一样。

德国77找到了一个简单的修复程序来修复数十个游戏中的崩溃:设置默认配置文件图片达到真正的32x32分辨率,而不是0x0。就是这样。

继续改进UI,german77也移动了最后一个音频设置在后台静音到它所属的音频部分。一般情况下,此选项不再四处游荡。

JuxtaposeJS
好的,正确的顺序

下一个是对UX(用户体验)的巨大改进,对我个人来说是一个巨大的解脱。以前,在使用游戏控制器配置文件时,如果您在开始游戏之前忘记更改输入设置,那么当游戏关闭时就会丢失这些设置,下次必须重新设置。

史诗般的男孩修复了这个恼人的问题德国人77合并了这些变化。非常感谢您的修复。

german77还致力于改进配置文件选择小程序。这个当前的更改这只是一个开始,我们将随时向您通报未来的最新进展。

输入改进
让我们谈谈输入,德国人77在其中继续闪耀。

对鼠标和键盘体验不满意玩 Metroid Prime重装,german77将默认鼠标灵敏度设置为50%,并删除了平滑过滤器,在获得Metroid粉丝的宝贵反馈后,提高了高DPI游戏鼠标的性能。他还降低了运动阈值,限制了转速,并积累了所有输入直到交付,从而修复了之前实现的延迟和波动。

你有没有注意到Samus是如何缺少领先指标的?她的西装不能再多出一点处理能力吗?(Metroid Prime重装)
你有没有注意到Samus是如何缺少领先指标的?她的西装不能再多出一点处理能力吗?(Metroid Prime重装)

由于这些变化,Metroid Prime重装表明这可能是一款很棒的电脑游戏。如果任天堂能让它走出地牢就好了。

我们遇到的一个常见问题是“这个第三方交换机控制器能工作吗?”简单的答案是可能的,但长的答案要复杂一些。

根据任天堂的API,Joy-Cons有两种模式:主动和被动。官方的Joy-Cons使用主动模式,但一些第三方控制器使用被动模式,通常是因为它们没有正确遵循API并且不支持任何配置命令。它们只是以默认设置运行,无论好坏。

这并不意味着被动控制器毫无用处。他们仍在使用交换机。但这确实意味着它们的工作方式不同。主动控制器每15毫秒更新一次状态,而被动控制器仅在发生某种情况时才更新状态,例如按下或释放按钮。

嗯,原来yuzu直到现在才支持被动模式!那么德国人77变化让许多第三方控制器用户感到高兴。考虑到有多少非官方控制器,这很方便。

与振动的斗争还在继续!在进行常规研究时,german77发现,如果有多个玩家使用同一类型的控制器,或者如果您使用双Joy-Con设置和单个控制器,您可能会连续向同一个控制器发送两个振动命令。这可能很烦人,而且它还占用了蓝牙连接的有限带宽。

这个解决方案很简单:只接受中的最新元素冷振动为每个控制器排队,检查控制器是否能够处理请求的振动,并忽略其余部分。

我们都喜欢生活质量的改变,对吧?即使它们不是很华丽。

让我们谈谈控制器小程序,负责在游戏请求时要求玩家选择输入设置。到目前为止,applet是不可跳过的;你必须给出一个有效的答案才能继续游戏。虽然这是可以接受的,但它很麻烦也不准确。如果玩家不能或不愿意确认他们的输入风格,一些游戏会回到上一个菜单,而不是陷入无休止的循环。

你应该通过!
你应该通过!

德国人77解决了这个问题行为,同时,它还解决了一个玩家计数不正确的错误。

德国人77实施了……等等,让我先喘口气,设置NpadJoyAssignmentModeSingleWithDestination服务呼叫。他已实现它希望让我们健身可玩,但不幸的是还有更多问题。

本月,将话题转向Amiibo支持,发生了很多事情。

首先,德国人77设法做到了写正确的CRC公司,使yuzu编写的Amiibo数据与Switch兼容;没有更多无效信息。

接下来,如果您在扫描Amiibo时尝试连接控制器,它将无法被识别。由会计为此,以及初始化或终结控制器,他修复了该问题。

最后但并非最不重要的是,为了结束阿米伊博传奇,德国谢尔曼·赫尔曼(Herman the German Sherman)添加了支持用于普通Amiibo文件。一些Amibos,比如那些主题为超级粉碎兄弟终极版,无需按键即可编辑。现在,yuzu可以从您的Amiibos正确读取非加密游戏数据!

音频修复
Maide在如何读取混响预设行时发现了一个错误,导致输出出现问题。解决方法正确读取通过输入而不是输出,游戏如下新款Super Mario Bros.U Deluxe正确的音频。现在你可以享受马里奥的声音,没有任何回音。妈妈,米娅!

规章制度一直在深入研究音频同步,改进代码库,并通过将来宾样本跟踪链接到主机来避免暂停。

这一变化导致了一些衰退,就像一些游戏一样非常敏感符合音频调度要求。用户报告合并后弹出声音,因此规章制度通过增加15毫秒的延迟样本计数报告。

其他代码更改
Fire Emblem的粉丝们在游戏中遇到了冻结现象,经过一些调查,Morph发现罪魁祸首是有边界的线程安全队列,该队列是由贝胡宁.

队列的任务是将事件从事件生成器(如CPU内核)传递给事件使用者(如GPU线程)。behunin替换的前一个实现不断分配和释放内存,导致周期性延迟峰值。

解决此问题的方法是将队列转换为有界队列,这意味着不需要分配内存,因为有固定数量的可用资源。这就是贝胡宁所做的,但新的队列实现似乎有缺陷。Morph添加了一个简化实施,修复新游戏冻结影响消防徽章:三栋房子和火徽接合.

你的作者根据上次对Windows所做的更改,为GCC构建重新启用LTO,但仅应用核心和视频核心子项目的优化,为Linux用户提供了一个不错的免费性能提升。

硬件部分
AMD 23.3.2及更新的驱动程序
一条坏消息和两条好消息。

从积极的方面来看,AMD终于在其最新的Windows驱动程序版本中添加了对缺少的动态状态扩展的支持,这提高了着色器构建时间,减少了Radeon GPU上的断断续续,使其性能与NVIDIA不相上下。

然而,从负面来看,此驱动因素更新也带来了严重的回归:

这可能会影响整个桌面(Metroid Prime Remared)

一些游戏,例如Metroid Prime重装和神奇宝贝传奇:阿修斯,触发一个似乎是失控的崩溃,导致桌面损坏和驱动程序崩溃。我们建议用户暂时使用23.3.1或更高版本的驱动程序。一些较旧的Radeon卡也可以从使用23.2.2中受益。

我们向AMD报告了这个问题,他们立即确认并复制了它,并通知我们他们正在进行修复。

现在那是如何进行客户支持。

说到这里…

做英特尔的工作
在测试关键的渲染修复程序时塞尔达传说:野性的呼吸我们将在下个月讨论这个问题,Morph做了一些功能测试来调查是什么让Intel Windows驱动程序运行得如此糟糕。

他的发现既令人期待,又令人失望。导致大约95%崩溃的主要原因是驱动程序中的计算着色器阶段有缺陷。禁用计算着色器,就像我们过去对旧版Intel硬件所做的那样,可以让大多数游戏运行,但不是全部。在中打开菜单时,我们仍然不知道崩溃的原因氙气纪事3.

我们现在正试图找出是什么触发计算着色器像这样使驱动程序崩溃,但这也带来了一个难题。我们是应该自己解决这个问题,让游戏渲染变得更糟,让英特尔摆脱困境,还是应该让它坏掉,让他们来妥善解决?

在调查继续期间,解决方案是使用可靠的Linux,或者避免购买仅依赖Intel GPU的硬件。唉。

未来项目
我们甚至还没有到4月的一半,我已经为下一份进度报告中的内容感到兴奋。开发者们都很火,他们不会很快停下来。

Maide正在为Xenoblade系列进行更多改进,例如修复云端闪烁氙气编年史2,中的粒子效应氙气纪事3以及影响整个传奇和其他一些游戏的纹理闪烁。然而,这些修复是以性能为代价的,因此他需要其他GPU开发人员的帮助来优化它们。也许 吧布林克霍克能帮忙吗?

任天堂为发布Vulkan扩展的圣杯做出了贡献,VK_EXT_阴影对象.此扩展承诺显著减少构建着色器所需的工作量,正如其依赖项所示,需要支持所有以前的动态状态扩展。

任天堂很可能打算将其用于内部仿真器,也许是为了“向后兼容”尽管如此,我们仍有大量工作要做,以增加对该扩展的支持。

但这已经足够了。让我们谈谈正在进行的一些激动人心的项目。

长笛增强

关于Gaia项目:它仍在开发中。

哦,ProjectLime处于发布候选状态,正在进行激烈的内部测试。

都是人!感谢您一直坚持到本进度报告结束。

感谢Bing聊天带来的糟糕笑话。