OpenCL中工作项分支发散（Divergent Control Flow）的执行原理是什么？

核心结论：当同一调度组（NVIDIA架构称warp/线程束，通常32个工作项为一组；AMD架构称wavefront/波前，通常64个工作项为一组）内的工作项出现if-else判断结果不一致时，硬件会通过指令掩码机制串行执行所有组内工作项命中的分支路径，未进入当前执行路径的工作项会被临时屏蔽、不执行对应指令，所有分支执行完成后整组才会汇合回到统一执行流，不会像CPU单线程程序那样直接跳过未命中的分支。

具体执行规则如下：

• 无发散场景：如果整组所有工作项的分支判断结果完全一致（全部满足if条件，或全部满足else条件），硬件会直接跳过未命中的分支，无额外执行开销，行为和普通串行程序完全一致。
• 存在发散场景：如果组内工作项的判断结果不统一，硬件会按以下流程执行：
  1. 整组同步完成分支条件计算，统计所有被命中的分支路径
  2. 按分支顺序依次执行每个命中的代码块：执行某一分支代码时，仅对属于该分支的工作项解除掩码、正常执行指令，其余工作项保持屏蔽状态空等
  3. 所有命中的分支代码块全部执行完成后，硬件清除分支掩码，整组工作项恢复统一执行后续公共代码

额外说明：

• 分支发散带来的性能损耗和组内命中的分支数量直接相关：如果一个调度组内的工作项分散走到N个不同分支，对应分支代码的执行耗时会是无分支场景的N倍左右
• 嵌套分支、switch多分支会进一步放大发散开销，每一层分支都可能触发多轮掩码切换和串行执行
• OpenCL规范本身没有对底层硬件的warp/wavefront调度逻辑做强制要求，上述掩码串行执行是当前所有主流消费级、数据中心级GPU通用的实现逻辑
• 内核优化时，尽量保证相邻工作项的分支判断结果保持一致，避免同调度组内出现多分支，是减少分支发散损耗的核心手段

内容的提问来源于stack exchange，提问作者user17271389