Cemu 着色器编译原理 — 为什么第一次进游戏会疯狂卡顿
Wii U vs PC 的着色器语言
这是理解 Cemu 着色器卡顿的关键。
Wii U 的 GPU 使用自己的一套着色器语言(基于 GLSL 的变体,但不完全相同)。PC GPU(NVIDIA/AMD/Intel)使用的是标准的 OpenGL GLSL 或 Vulkan SPIR-V 着色器。
Cemu 运行 Wii U 游戏时:
- 游戏代码发送 Wii U 原生着色器指令
- Cemu 接收到,需要把它翻译成 PC GPU 能理解的着色器代码
- 翻译完成后交给 PC GPU 执行
这个「翻译」过程就是着色器编译。
为什么第一次运行会卡
着色器有个特性:第一次遇到新的着色器代码时才需要编译,之后缓存起来复用。
具体到 Cemu:
- 你第一次启动一个游戏 → Cemu 逐帧检查 Wii U 发来的着色器 → 遇到新的就编译 → 编译期间游戏画面短暂停顿
- 你在游戏里切换到新场景 → Wii U 发来一批新的着色器(不同场景有不同的光影、材质效果)→ 又要编译 → 又卡一下
- 你玩了几个小时、探索了大部分场景后 → 几乎所有着色器都编译过了 → 之后游戏基本不卡
这就是为什么 Cemu 第一次玩旷野之息可能卡得像幻灯片,玩了 20 分钟后突然丝滑。
卡顿是永久的吗
不是。编译过的着色器会缓存在本地(Shader Cache)。下次启动同一个游戏,Cemu 直接从缓存加载预编译的着色器,不再重新编译——几乎不会卡。
缓存位置:
Cemu/resources/shadercache/
注意:缓存是每个游戏独立的(文件名里含游戏 ID),而且 Vulkan 和 OpenGL 的缓存格式不同——切换图形 API 后需要重新编译。
为什么 Vulkan 卡顿更少
Vulkan 后端在着色器编译上有两个优化:
- 异步编译——把编译工作放到后台线程,游戏主线程不被阻塞(详见下一节)
- pipeline cache——Vulkan 管线缓存,比 OpenGL shader cache 更完整
OpenGL 后端没有异步编译能力——遇到新着色器时必须停住游戏等编译完。
Shader Cache 可以手动导入
如果觉得自己编译太慢,可以下载别人编译好的 Shader Cache 直接导入——详见 Shader Cache 导入章节。社区有人把热门游戏的完整缓存打包分享,直接放进 Cemu 目录就能用,省去自己编译的时间。
着色器缓存为什么会膨胀
Shader Cache 文件会随着你在游戏里探索更多场景而增长。复杂 3D 游戏(如旷野之息)完整的 Shader Cache 可以到 几百 MB。这是正常的,不用删——删了就得重新编译。
着色器缓存能跨机器用吗
理论上可以,实际操作有讲究:
- OpenGL Shader Cache 不区分硬件/区域——同游戏跨机器通用
- Vulkan Shader Cache + Pipeline Cache 锁定了游戏区域(欧版、美版、日版的 pipeline cache 不能混用)
- Pipeline Cache 还和 GPU 驱动版本有关——换显卡或大版本升级驱动后可能要重新编译
常见问题
着色器缓存能关掉吗
绝对不能。着色器编译是 Cemu 运行的基本过程——关掉等于不让游戏渲染画面。缓存只是「不重复编译」,不是「不开编译」。
着色器缓存太大能删吗
能,但删了就得重新编译。如果你确实空间紧张,可以删——不会损坏游戏存档或设置。但删了之后再进游戏会重新经历卡顿期。
换了显卡要重新编译吗
大概率需要。Vulkan Pipeline Cache 和 GPU/驱动绑定。OpenGL Shader Cache 有可能通用,但 100% 确定能在新硬件上无瑕疵运行。所以换了显卡后建议:
- 清理旧 Shader Cache(删 resources/shadercache/ 下所有文件)
- 进游戏让它重新编译(会卡顿但最终能得到适配新硬件的缓存)
- 或者直接下载社区为新硬件编译好的缓存