Cemu 异步着色器编译 — 减少首次卡顿的核心开关
问题：为什么 OpenGL 会卡得很明显
OpenGL 后端在遇到新着色器时的行为：
游戏主线程
├─ 收到新着色器
├─ 停住 → 编译着色器（耗时 50ms ~ 500ms）
├─ 编译完 → 继续渲染下一帧主线程被阻塞 = 游戏完全卡住。如果一帧里有多个新着色器要编译，可能卡一秒以上。
异步编译怎么做
Vulkan 后端的异步编译（Async shader compilation）把流程改成：
游戏主线程 后台编译线程
├─ 收到新着色器
├─ 标记要编译 → 丢给后台 后台线程：开始编译
├─ 主线程不等 → 用当前已知着色器继续渲染
│ ├─ 编译中...
│ └─ 编译完 → 通知主线程
├─ 下次需要这个着色器
│ → 直接用（已经编译好了）
└─ 游戏继续跑，中间几乎不停关键区别：主线程不等待编译完成——编译期间游戏继续用旧的/简化的渲染方案跑，可能有短暂的小 glitch（画面闪烁几帧），但不会像 OpenGL 那样卡死。
效果差异
没有异步编译（OpenGL）：
- 第一次进新区域 → 卡 2~10 秒不动
- 切换到新场景 → 又卡一下
- 玩 20 分钟后基本编译完了，但之前的体验很差
有异步编译（Vulkan + 开启）：
- 第一次进新区域 → 画面可能闪烁一下，但游戏继续跑
- 切换到新场景 → 几乎感觉不到（除非同时来一批新着色器）
- 首次体验就能达到可玩的流畅度
怎么开启
Cemu 里：
- 顶部 → Options → General settings
- 左边选 Graphics
- 确认 Graphics API 是 Vulkan（只有 Vulkan 有这个选项）
- 勾上 Async shader compiler
就这一个开关，默认应该是开启的（2.0+ 版本）。如果关掉了手动勾上。
什么机器能用
异步编译要求：
| 项目 | 要求 |
|---|---|
| 图形 API | 必须 Vulkan |
| 显卡驱动 | 最新稳定版（老驱动可能有 bug 或不支持） |
| CPU | 多线程有帮助（编译线程会占用 CPU） |
macOS 上完全不支持——macOS 只能用 OpenGL，OpenGL 没有异步编译能力。
异步编译也需要 Shader Cache
异步编译只是把编译过程"藏起来"让游戏不卡，但它仍然会在后台生成 Shader Cache 文件。而且：
- Vulkan 需要 Shader Cache + Pipeline Cache 两个缓存文件
- 缓存生成完后，下次启动就直接从缓存加载，连后台编译都省了
所以异步编译是「让首次体验不那么糟」，Shader Cache 导入是「跳过整个首次编译」——两者都做效果最好。
有没有副作用
极小。理论上可能出现：
- 编译期间个别画面渲染不完整（缺着色器导致的小 glitch），等编译完就正常了
- CPU 占用会略高一点（后台线程在干活）
但实际体验中这些都不明显。官方默认开启也是有道理的。
快速检查清单
- [ ] Graphics API = Vulkan（不是 OpenGL）
- [ ] Async shader compiler 勾上了
- [ ] 显卡驱动是最新稳定版
- [ ] macOS 用户：无此选项，只能让 OpenGL 卡
- [ ] 卡得厉害 → 导入社区 Shader Cache（见下一节）
进阶：Accurate barriers
Debug 菜单里有个 "Accurate barriers (Vulkan)" 选项。它：
- 开启：更精确的内存屏障，可能修复极少数游戏的图形 bug
- 关闭：性能更好，绝大多数游戏不需要
官方推荐：关闭。除非你遇到特定游戏的图形问题，否则别开。