在 PC 上跑 2000 款 Switch 游戏：yuzu 模拟器的实现与调优手记-编程实验室

在 PC 上跑 2000 款 Switch 游戏：yuzu 模拟器的实现与调优手记

【免费下载链接】yuzu任天堂 Switch 模拟器项目地址: https://gitcode.com/GitHub_Trending/yu/yuzu

yuzu 是一款开源的任天堂 Switch 模拟器，把 Switch 的 ARM CPU、Maxwell GPU 和完整内核搬进你的 PC 或 Android 设备。这篇手记不堆术语：先讲第一次启动时那个"卡 30 秒"是怎么回事，再带你三步跑起来，然后拆两个最关键的实现——CPU 的 JIT 模拟和 GPU 的着色器重编译，最后给一套能验证的调优做法。

第一次启动卡 30 秒，不是玄学

很多新手的第一次体验是这样的：点开《塞尔达》或《马瑞纳大冒险》，画面在加载后黑屏、卡顿、偶尔花屏，几分钟后才正常。你怀疑模拟器坏了，其实它正在做一件很重的活——把游戏的 GPU 着色器逐条编译成你的显卡能执行的格式。

Switch 的 GPU 是 Maxwell 架构，游戏里每段渲染指令都是 Maxwell 的机器码。yuzu 不模拟 Maxwell 芯片，而是把这些指令"翻译"一遍：先解码成中间表示，再重编译成 Vulkan 或 GLSL 代码交给你的显卡。每段着色器第一次遇到都要走这条流水线，编译期间画面只能干等。

但这条流水线有个救命的特性：编译结果会落盘成着色器缓存。同一款游戏第二次启动，绝大多数着色器直接读缓存，那段 30 秒的卡顿基本消失。所以"第一次卡、第二次顺"不是 bug，是这套缓存机制的预期行为。

三步跑起来：最短上手路径

yuzu 是 CMake 工程，桌面版用 Qt 做界面，输入靠 SDL2，默认全部开启。最短路径是编译，装依赖（CMake 3.22+、C++20 编译器、Qt 6、Vulkan SDK）后：

git clone https://gitcode.com/GitHub_Trending/yu/yuzu cd yuzu && mkdir build && cd build cmake .. -DCMAKE_BUILD_TYPE=Release -DENABLE_SDL2=ON -DENABLE_QT=ON cmake --build . --config Release -j$(nproc)

第二步，把游戏文件（.nsp/.xci/ 解包目录）拖进游戏列表——yuzu 的 src/core/loader/ 里每个文件格式一个加载器，识别是自动的。第三步，点启动，第一次耐心等着色器编译完。

到此你应该已经能玩了。后面的原理拆解，是为了让你出问题时知道往哪看。

CPU 是怎么"变"出来的：dynarmic JIT

Switch 的 CPU 是 4 核 ARM Cortex-A57，跑 AArch64 指令。x86 PC 上没人想逐条解释执行（慢几十倍），yuzu 的选法是JIT：CPU 模拟部分位于 src/core/arm/，底层用 dynarmic 的 A64 JIT 模块。

工作方式可以拆成三步看：

首次执行：遇到一段还没翻译过的 ARM 代码，JIT 把它解码，逐条翻译成当前机器的机器码，写入一块可执行内存页。
分支处理：遇到跳转指令，JIT 生成桩代码，指向下一个翻译目标；已翻译的目标直接跳过去，形成一条"机器码的高速公路"。
热路径加速：翻译好的代码反复执行，只付一次翻译成本。

翻译层上面还有一整套内核 HLE（高级模拟）：src/core/hle/kernel/ 里有近 200 个文件，按 Switch 系统内核的 API 语义重新实现了进程、线程、信号量、内存分配这些原语——注意是"按接口行为重实现"，不是把内核二进制逐周期模拟，这是性能的关键取舍。游戏调sysmem申请内存，HLE 直接把它映射到 yuzu 的页表上，页表背后是宿主机预留的4GB 虚拟地址空间（0x100000000），精确复刻 Switch 的统一内存大小。

一句话：CPU 侧 = JIT 管指令，HLE 管系统调用，页表管内存，三者分工明确。

GPU 是怎么"变"出来的：从 Maxwell SASS 到你的显卡

GPU 侧是整个项目工程量大头的地方，核心在 src/shader_recompiler/。它的流水线是这样的：

前端（maxwell/）：把游戏提交来的 Maxwell SASS 指令逐条解码，构建出带控制流结构的中间表示（IR）。这一层负责"读懂 Switch 的 GPU 语言"，兼容性问题最常在这里冒头。
IR 优化：对中间表示做常量折叠、寄存器分配等通用优化，与后端无关。
后端（spirv/ 或 glsl/）：把优化后的 IR 编译成 SPIR-V 或 GLSL 提交给 Vulkan / OpenGL 驱动。

渲染主循环跑在独立的 GPU 线程上（video_core/gpu_thread），CPU 模拟线程不阻塞等渲染；缓冲上传、帧同步都通过命令队列异步完成，这是它能把帧率做到接近实时的另一块基石。

其余子系统一句话带过：文件系统用分层 VFS 模拟 Switch 的 NCA/ROMFS 分区（core/file_sys/）；音频不是简单放音，而是把 ADSP 音频处理单元整套渲染管线模拟了出来（audio_core/renderer/），所以混响、变声这类效果能正常工作；网络支持本地多人房间。

调优手记：哪些设置值得动，怎么判断好坏

判断"改设置有没有用"只有一条标准：用性能叠加层里的帧时间曲线说话，而不是看截图。下面这些做法都可以立刻验证。

对比项	Vulkan 后端	OpenGL 后端
最低驱动要求	Vulkan 1.3（构建时强制检查）	GL 4.6 左右
现代桌面 GPU 表现	更稳，异步管线利用充分	可用，部分老卡兜底
着色器产物	SPIR-V，编译较快	GLSL，个别驱动编译更慢
适用场景	PC 首选	老显卡或特定平台兜底

几个可验证的调优点：

分辨率缩放选整数倍（1x、2x）。非整数倍（1.5x）会触发额外的内部缩放 pass，帧时间能明显看到抬升。
着色器缓存要管理好。换 GPU、升级驱动、升级 yuzu 大版本后，缓存可能失配，症状是"明明玩过还卡"。处理方式：清掉 shader cache 目录让它全量重编一次，第二次启动恢复顺滑。
CPU 要有 AVX2。JIT 生成的宿主机代码走 SIMD 路径，没有 AVX2 的 CPU 帧时间普遍更差，这是"老平台跑 yuzu 卡"最常见的真实原因，不是玄学。
首帧卡顿 vs 持续卡顿的区分：只有开头几秒卡，是正常编译，等缓存落盘即可；持续掉帧，先看叠加层里是帧时间均匀地高（算力不够，降分辨率），还是周期性尖刺（多半是着色器在编译，检查缓存目录是否被写盘/被杀毒软件锁住）。

想再深一层：往哪读代码

着色器兼容性问题先看shader_recompiler/frontend/maxwell/，那里是 SASS 指令的翻译实现，社区大部分 GPU 修复都落在这里。
游戏黑屏/崩溃先看core/hle/kernel/的日志输出，HLE 的断言信息通常直接指向缺失的系统调用。
仓库自带测试集在src/tests/，构建时开YUZU_TESTS，用ctest --output-on-failure跑，改代码前后各跑一遍是基本纪律。
构建选项里还有几个值得知道的：YUZU_ENABLE_PORTABLE（检测到用户目录时走便携模式，默认开）、YUZU_ENABLE_LTO（链接期优化，编译更慢但二进制略优）。