如何可靠查询Metal计算着色器SIMD组大小？threadExecutionWidth不匹配问题

问题背景 #

• Mac端高复杂度Metal计算内核使用SIMD组规约、前缀和操作时，需要分配线程组（threadgroup）内存，支撑同一线程组内跨SIMD组的协同逻辑。
• 内存数组的理论容量由[[simdgroups_per_threadgroup]]决定，但该值不属于编译期常量，无法直接作为静态数组维度使用。
• 按照WWDC session官方指引，管线对象的threadExecutionWidth属性会返回SIMD组大小，开发者可基于该值通过计算编码器的setThreadgroupMemoryLength:atIndex:方法分配对应容量的线程组内存。
• 该方案在Apple Silicon设备（如M1系列）上表现稳定：threadExecutionWidth固定返回32，与实际SIMD组大小一致；但在部分Intel核显环境（如Intel UHD Graphics 630）上出现值不匹配问题，引发内存越界运行时错误：
  • 部分复杂内核的threadExecutionWidth返回16，但实际SIMD组大小为32
  • 同硬件上的其他内核，实际SIMD组大小甚至可达64
• 初步排查排除了“threadExecutionWidth是最大线程组大小与SIMD组大小最大公约数”的猜测：出问题的内核上报的最大线程组大小为896，是32的整数倍，不符合公约数计算逻辑。

核心疑问 #

1. 是否存在可靠方法，可在计算内核运行前查询对应内核的实际SIMD组大小？
2. 同一设备上所有计算内核的SIMD组大小是否为固定值？
   • 如果第二问答案为是，是否可以认为逻辑极简内核的threadExecutionWidth返回值可信？还是必须提交一个返回[[threads_per_simdgroup]]的极简探针内核来获取准确值？

解答 #

核心结论前置 #

WWDC相关session中给出的threadExecutionWidth适配方案，主要面向Apple Silicon硬件场景设计，未覆盖Intel Gen架构核显的可变SIMD宽度特性。

1. 同一设备上不同计算内核的SIMD组大小不是固定值。Intel Gen架构核显的硬件执行单元本身支持SIMD16/SIMD32/SIMD64多档调度模式，Metal编译器会根据内核的寄存器占用、资源复杂度、当前驱动调度策略自动选择对应宽度生成内核变体，这就是同硬件不同内核SIMD组大小不一致的根本原因。Apple Silicon硬件SIMD宽度固定为32，不存在模式切换逻辑，因此threadExecutionWidth始终返回准确值。
2. 不存在无需运行内核即可100%准确获取当前内核实际SIMD组大小的公开API。threadExecutionWidth仅返回管线创建时Metal预估的执行宽度，在Intel核显上该值可能和最终实际调度的宽度存在偏差，不能作为跨硬件场景下的可靠依据。

可落地的稳定方案 #

探针内核是目前覆盖所有Mac GPU（Apple Silicon、AMD独显、Intel核显）的零副作用可靠方案，实现逻辑如下：

• 编写一个逻辑极简的探针内核，唯一功能是读取内置属性[[threads_per_simdgroup]]，将值写入预分配的共享缓冲区。
• 目标管线创建完成后，首次调度业务内核前，调度该探针内核：配置1个线程组，线程数设置为max(threadExecutionWidth * 2, 64)即可保证覆盖完整SIMD组，整个调度开销在微秒级，完全可以忽略。
• 从缓冲区读回准确的SIMD组宽度后缓存，后续调度对应业务内核时，通过线程组总线程数 / 实际SIMD组宽度计算得到simdgroups_per_threadgroup，再传入setThreadgroupMemoryLength:atIndex:分配对应大小的线程组内存即可。

注意事项 #

不要依赖“极简内核的threadExecutionWidth返回值可信”的假设：即使是逻辑极简单的内核，编译器也可能根据GPU当前的功耗策略、驱动状态选择不同的SIMD宽度编译变体，不存在可以稳定匹配实际值的通用规律。

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