Metal 测试反馈

[0x1306a94]

最近观察到已经合并了Metal的API，所以我更新了下，并将我的项目迁移到Metal 运行发现了以下问题

1. 需要在 vendor.json 的 shaderc SPIRV-Cross 添加 -DDEPLOYMENT_TARGET="13.0"

• 因为 Xcode 26 编译报错，从编译日志可以看到采用的 iOS9.0 版本编译，但是 std::filesystem 9.0 是不支持的。最低应该需要设置为 13
• 这里是不是可以优化为在CMakeList 中将 DEPLOYMENT_TARGET 传递给vender

2. 发现首帧耗时长 https://github.com/0x1306a94/SeatCanvas/tree/feature/0x1306a94_ios_metal

[TimeProfiler] Draw Frame: 910.103 ms
[TimeProfiler]   ├─ Create Window: 0.377 ms
[TimeProfiler]   ├─ Create Surface: 0.027 ms
[TimeProfiler]   ├─ Prepare Zone Name: 0.012 ms
[TimeProfiler]   ├─ Prepare Overlay: 0.429 ms
[TimeProfiler]   ├─ Prepare Seat: 615.086 ms
[TimeProfiler]   ├─ Custom Pass: 72.321 ms
[TimeProfiler]   ├─ Canvas Zone Name: 0.676 ms
[TimeProfiler]   ├─ Canvas Overlay: 0.092 ms
[TimeProfiler]   ├─ Canvas Flush: 0.041 ms
[TimeProfiler]   └─ Canvas Submit: 220.967 ms

[Hparty]

metal现在还在完善中，首帧卡顿是因为shader转换耗时很高，目前还是建议先使用opengl。后续会解决这个问题的。

[0x1306a94]

我知道还没有完善好，我也是想着测试看看。也可以发现一些问题

[0x1306a94]

我仔细排查了下，做了一个小优化提升非常明显 #1348 您可以看看是否合理

[Hparty]

感谢修复，已经合入了。

[0x1306a94]

👌 我再看看关于第一个问题，有没有好的处理方式

[0x1306a94]

@Hparty 关于第一个编译问题我看了下仓库中编译参数相关的。

1. 首先tgfx 自身有处理 DEPLOYMENT_TARGET CMAKE_OSX_DEPLOYMENT_TARGET
2. 但是vendor 的编译是通过外部命令进行编译的而非 cmake 集成，所以 shaderc 不会继承。

• vendor_tools 中的 ios.toolchain.cmake:279 iOS tvOS 默认设置的 9.0 而shaderc 中的 glslang 用到了 filesystem ，所以对于 iOS 需要将 DEPLOYMENT_TARGET 至少提升到 13
• autotest 以及 ci 检查其实是没有开启Metal 选项，所以没有暴露出这个问题

最简单的解决方案就是直接修改 ios.toolchain.cmake:279 的默认值。
但正常应该是相关依赖都应该和tgfx 主工程使用同样的配置，这就需要修改vendor_tools 通过参数或者环境变量进行传递
tgfx_vendor_tools.patch

if(IOS)
    list(APPEND TGFX_VENDOR_CMAKE_ARGS "-DDEPLOYMENT_TARGET=${CMAKE_OSX_DEPLOYMENT_TARGET}")
endif()
message("TGFX_VENDOR_CMAKE_ARGS: ${TGFX_VENDOR_CMAKE_ARGS}")
add_vendor_target(tgfx-vendor STATIC_VENDORS ${TGFX_STATIC_VENDORS} SHARED_VENDORS ${TGFX_SHARED_VENDORS} CMAKE_ARGS ${TGFX_VENDOR_CMAKE_ARGS})

不知道这种方式你觉得如何

[Hparty]

我理解了下，应该是指的metal后端shaderc SPIRV-Cross版本用了系统filesystem，所以最低应该是13.0吧，后续我们统一升上去就行

[0x1306a94]

对的，是 glslang 的代码里面用到了 filesystem
iOS 需要最低调整为 13 就行了

[Hparty]

#1354 已经修复了，可以试试main分支最新版本

[0x1306a94]

测试了，编译的问题解决了

[Hparty]

目前 Metal 还在试验当中，由于 Metal shader 采用的是 GLSL -> SPIR-V -> MSL 这个转译的方案，实时 shader 编译耗时相对会高一些。

通过 benchmark 测试，Metal 在缓存 shader 后，整体性能相对 OpenGL 高 10% 左右。后续等待更多后端完成后，会开始解决 shader 实时编译的问题。预计方案是拆分 shader，只有在兜底情况下会启用实时编译。

[0x1306a94]

@Hparty 之前我们分析发现，主要耗时是在那个那个符号表建立。我有个思路，不知道是否有价值采纳

方案一

• 就是提供一个预热的 shaderc::Compiler 然后编译一段极简的 glsl 触发首编，然后保持这个常驻。
• 但需要按照 SetupBuiltinSymbolTable(int version, EProfile profile, const SpvVersion& spvVersion, EShSource source) 构建这个预热的
• 我看源码，符号表内部操作本身也有 锁保护。

方案二

• 虽然目前的glsl 都是动态生成的。但应该都有共同点。
• 那么这些是不是就可以采用离线画，编译时就直接转换好
• 实时编译只有在用户需要完全自己写glsl 才用到

[Hparty]

是的，目前方案一业务上可以自己处理了。方案二后续会满满实现的。

[0x1306a94]

预热这个好像没法业务自己处理。因为业务代码是无法访问到 shaderc::Compiler 吧？
而在之前的 PR 实现中是将 shaderc::Compiler 放到了 MetalGPU 中。
如果实现预热的话应该是 tgfx 提供一个公开的预热函数吧。由业务自行选择是否启用。同时整个进程中都不释放这个预热的shaderc::Compiler
这样后面才能复用到。大多数的应用场景不会是启动app就进入tgfx 的渲染流程了吧。

然后我在Hello2D 中跑了下，添加了之前的 ShadercPerf 日志。除去首次编译需要 60ms 左右
后面基本上每编译一个都在 1-3ms 应该和shader 复杂性有关，如果一帧里面。shader 较多 并且又很复杂，确实还是会影响这一帧的耗时。
也确实符合你的结论提升不是特别高。

[0x1306a94]

仔细看了下 processors下面，离线化。拆分的工作量应该是很大的

[Hparty]

目前组合shader的主要目的是减少op次数，是为了适配opengl。在现代的渲染后端里，在非组合的情况下，也有其他方式可以优化性能。后续一个方向是不继续组合shader，把shader按照功能提前准备好，这样就不需要处理这么巨量的情况了

[Hparty]

目前预热可以通过业务侧在空闲时机主动 draw 一个简单的 rect 来实现，这样会触发首次 shader 编译，把符号表建立的开销（约 60ms）提前消化掉，后续每个 shader 编译就只需要 1-3ms 了。

暂时不打算提供专门的预热 API，因为 Metal 后端目前还在试验阶段，后续 shader 拆分方案落地后，shader 会按功能预先准备好，不再依赖实时编译，预热也就不再需要了。如果现在加一个 warm up 接口，等方案调整后这个接口就变成多余的了。

[0x1306a94]

👌