一、动态分支的“隐形坑”
很多做Metal着色器开发的开发者，都遇到过同样的问题：明明写的逻辑没错，放到iOS或macOS设备上跑的时候，帧率却莫名其妙掉下来，尤其是在需要处理大量像素的场景（比如角色皮肤的次表面散射、复杂材质的混合），掉帧能达到20%以上。
这背后的元凶，就是动态分支。你可以把GPU的并行计算想象成一个“班级小组”：同一个小组的64个像素线程，本来要一起执行相同的指令，这样才能把性能拉满，相当于全班一起走一条路；但如果代码里有if (运行时才知道的条件)，小组里的线程就会分成两拨，一拨走左边，一拨走右边，GPU只能先让一部分线程跑完左边的路，再让另一部分跑右边的路，本来64线程能并行的工作，硬生生变成了两段串行，性能自然骤降。
比如你要做一个包含皮肤、金属、塑料三种材质的场景，每个像素的材质ID从缓存传进来，写了这样的代码：
// 技术栈：Metal Shading Language (MSL)
#include <metal_stdlib>
using namespace metal;
// 动态分支的光照计算：材质ID是运行时从缓存传进来的
float calculate_light(float3 normal, float3 light_dir, float3 view_dir, int material_id) {
float half_dot = dot(normalize(light_dir + view_dir), normal);
float diffuse = max(half_dot, 0.0);
float specular = pow(max(dot(normalize(light_dir), view_dir), 0.0), 32.0);
// 动态分支：条件material_id是运行时确定的，GPU无法预判
if (material_id == 0) {
// 皮肤材质：模拟次表面散射的柔和感
float sss = smoothstep(0.1, 0.5, diffuse) * 0.5;
return diffuse * 0.6 + specular * 0.4 + sss;
} else if (material_id == 1) {
// 金属材质：高光锐利，几乎没有柔和的漫反射
return specular * 0.9 + diffuse * 0.1;
} else {
// 塑料材质：介于皮肤和金属之间的质感
return diffuse * 0.7 + specular * 0.3;
}
}
这个代码的问题就是material_id是运行时才确定的，每个像素的ID可能不同，导致GPU的小组线程拆分，性能直接被浪费了一大半。
1.1 为什么动态分支的开销没法避免
除了线程拆分，动态分支还会让编译器生成更多的分支预测指令，增加指令缓存的压力，甚至会让部分线程进入等待状态，这些隐性开销加起来，在移动GPU上会被放大好几倍——毕竟移动GPU的性能本就不如桌面级，一点点浪费都会影响帧率。
二、换函数常量与静态分支怎么解决
要解决这个问题，核心是把“运行时才确定的条件”，改成编译时就能确定的固定值，也就是用函数常量（Function Constant）+ 静态分支的组合，代替动态分支。 简单说，函数常量就是给着色器定义的“编译期变量”，你在把着色器编译成可执行代码的时候，就把这个变量的值固定下来，编译器会自动删掉不需要的分支代码，只保留对应条件的逻辑，这样GPU的小组线程就不用拆分，完美规避分支开销。
2.1 具体改造示例
把刚才的动态分支代码改成静态分支+函数常量，改造后的代码是这样的：
// 技术栈：Metal Shading Language (MSL)
#include <metal_stdlib>
using namespace metal;
// 定义函数常量：[[function_constant(0)]] 代表索引为0的函数常量，编译时需指定值
constant int MATERIAL_TYPE [[function_constant(0)]];
float calculate_light(float3 normal, float3 light_dir, float3 view_dir) {
float half_dot = dot(normalize(light_dir + view_dir), normal);
float diffuse = max(half_dot, 0.0);
float specular = pow(max(dot(normalize(light_dir), view_dir), 0.0), 32.0);
// 静态分支：用编译期确定的常量判断，GPU不会拆分线程
#if MATERIAL_TYPE == 0
// 只保留皮肤材质的代码，其他分支被编译器完全删除
float sss = smoothstep(0.1, 0.5, diffuse) * 0.5;
return diffuse * 0.6 + specular * 0.4 + sss;
#elif MATERIAL_TYPE == 1
// 只保留金属材质的代码
return specular * 0.9 + diffuse * 0.1;
#else
// 只保留塑料材质的代码
return diffuse * 0.7 + specular * 0.3;
#endif
}
2.2 怎么在代码里设置函数常量的值
刚才的代码里MATERIAL_TYPE是编译时常量，所以在宿主代码（比如Obj-C或Swift）里编译着色器的时候，要指定这个常量的值，比如Obj-C里的写法：
// 技术栈：Obj-C（Metal宿主代码）
id<MTLDevice> device = MTLCreateSystemDefaultDevice();
id<MTLLibrary> library = [device newDefaultLibrary];
// 创建函数常量值的容器，用来给着色器的函数常量赋值
MTLFunctionConstantValues *constantValues = [[MTLFunctionConstantValues alloc] init];
// 给索引0的函数常量赋值为0，对应皮肤材质
[constantValues setConstantValue:@(0) type:MTLDataTypeInt atIndex:0];
// 从着色器库中获取指定函数常量的编译函数
NSError *error = nil;
id<MTLFunction> lightFunction = [library newFunctionWithName:@"calculate_light" constantValues:constantValues error:&error];
这样编译出来的着色器，就只会包含对应材质的代码，没有任何分支，性能直接拉满。
三、应用场景、优缺点与注意事项
3.1 适合的应用场景
这个优化方案的核心是“条件必须是编译时确定的”，所以适合的场景有：
- 固定材质类型的游戏：比如RPG里的怪物只有皮肤、武器只有金属、建筑只有塑料，每个模型的材质在运行时不会切换；
- 全局固定的参数：比如是否开启抗锯齿、是否启用阴影，这些参数是整个场景统一的，编译时就能确定；
- 硬件平台的固定适配：比如针对不同芯片的着色器优化，不同芯片的函数常量值不同，编译成对应版本的着色器。
3.2 技术优缺点
优点：
- 完全消除GPU的分支开销，warp线程100%并行，性能提升可达20%-50%，移动端提升更明显；
- 编译器会自动删除未用到的分支代码，让着色器更精简，减少指令缓存的占用；
- 避免了动态分支可能导致的驱动错误，稳定性更高。 缺点：
- 灵活性差：函数常量的值是编译时确定的，运行时不能修改，无法实现“随玩家操作切换材质”的需求；
- 增加着色器的数量：如果有N个固定条件，就需要编译N个版本的着色器，占用更多的内存资源；
- 调试稍复杂：不同版本的着色器需要分开测试，排查问题时要对应到具体的函数常量值。
3.3 注意事项
- 函数常量的索引要对应正确：
[[function_constant(n)]]里的n要和MTLFunctionConstantValues里设置的index完全一致，错一个就会导致编译错误； - 静态分支必须用预处理指令：只能用
#if/#elif/#else/#endif，绝对不能用普通的if，普通的if还是动态分支，无法优化； - 函数常量只能是基础类型：比如int、bool、float，不能是指针、结构体或数组；
- 避免过多函数常量：如果有超过3个函数常量，会增加编译时间和着色器的版本数量，需要权衡灵活性和性能。
四、总结
写Metal着色器的时候，很多开发者为了图方便，喜欢写动态分支，结果忽略了GPU并行计算的特性，导致性能骤降。用函数常量+静态分支的方案，本质是把“不确定的运行时条件”变成“固定的编译时选择”，完美规避了GPU的分支开销，同时又不损失太多灵活性，是非常实用的性能优化技巧。尤其是在移动端游戏、实时渲染的场景里，每一点性能的提升都能带来更好的用户体验，这个优化方案值得每个Metal开发者掌握。
评论
围绕“编写Metal着色器时频繁遇到动态分支性能骤降？尝试改用函数常量与静态分支规避调度开销”参与讨论