众所周知，当存在条件分支时，在 GPU 上运行的工作项可能会出现分歧。Apple 的OpenCL Programming Guide for Mac中提到了其中之一。
因此，算法的某些部分可能运行“单线程”，只有一个工作项在运行。当它特别是串行和长时间运行时，一些应用程序会将这些工作带回 CPU。
但是，这个问题仅涉及 GPU，并假设这些部分是短暂的。当这些“单线程”部分具有条件分支时，它们是否也会发散（如在执行真假代码路径时）？或者计算单元（或处理元素，无论你喜欢哪个术语）会跳过那些错误的分支？
更新
在回复评论时，我会删除 OpenCL 标记并将 Vulkan 标记留在那里。
我包括了 OpenCL，因为我想知道clEnqueueTask和clEnqueueNDRangeKernelwith之间是否有任何区别dim=1:x=1。该文件说它们是等效的，但我对此表示怀疑。
我相信 Vulkan 删除了将单线程任务入队的特殊功能是有充分理由的，如果我错了，请纠正我。
当这些“单线程”部分具有条件分支时，它们是否也会发散（如执行真假代码路径）？
从 API 的角度来看，它必须让程序看起来只采用了活动的分支路径。至于实际发生的事情，我怀疑你永远不会确定。GPU 硬件架构几乎都是保密的，因此无法确定。
这里真的有两种情况：
在一个真正的分支的情况下，我希望大多数情况下只执行活动路径，因为两者都做是一种可怕的能源浪费，而 GPU 都是关于能源效率的。也就是说，YMMV，这根本不能保证。
对于简单的分支，编译器可能会选择使用条件选择（计算两个结果，然后选择正确的答案）。在这种情况下，您将计算两个结果。编译器启发式通常旨在选择计算两个结果的成本低于实际拥有完整分支的成本。
我包括了 OpenCL，因为我想知道 clEnqueueTask 和 clEnqueueNDRangeKernel 之间是否有任何区别，dim=1:x=1。该文件说它们是等效的，但我对此表示怀疑。
为什么他们会有所不同？他们在概念上做同样的事情......
我相信 Vulkan 删除了将单线程任务入队的特殊功能是有充分理由的，如果我错了，请纠正我。
Vulkan 计算调度通常比 OpenCL 更简单（并且也完全适用于大多数用例），因此 OpenCL 的许多主机端功能在 Vulkan 中没有等效功能。GPU 端的行为几乎相同。还值得注意的是，与 OpenCL 相比，Vulkan 着色器缺少功能的大多数漏洞正在通过扩展进行修补 - 例如VK_KHR_shader_float16_int8和VK_KHR_variable_pointers.
问：或者计算单元会跳过那些错误的分支吗？
CPU / GPU 代码执行的生态系统相当复杂。
硬件层是代码路径（翻译成“机器”代码）运行的地方。在这一层上，SIMD 计算单元不能也不会跳过硬件调度程序（下一层）向 SIMD 进程订购的任何内容。
特定于硬件的调度器层（GPU 通常具有正确的两种模式：用于在 SIMD 块中有效调度的一致、非发散代码路径的 WARP 模式调度和贪婪模式调度）。从这一层开始，加载 SIMD 计算单元以处理 SIMD 操作的工作块，因此在较低层（上层）检测到的任何第一个分歧都会中断执行，将 SIMD 硬件调度程序标记为块，延迟由于每个这样的运行时差异，所有已知的特定于 SIMD 的块设备优化调度都开始变得越来越低效和低效。
{ OpenCL | 层 Vulkan API }-介导的特定于设备的编程在很大程度上决定了广泛的目标设备的人机编程的易用性或舒适性，所有这些都不知道其各自的内部约束，关于（编译器决定的）首选“机器” -代码计算问题的重新制定和设备特定的技巧和调度。多年来，有点过于简单的战场图景使得人类用户只是停留在中介异步工作单元（内核的）主机到设备调度队列的“前面”，并等到我们收到返回的设备到主机传递的结果，如果允许和需要，做一些先验-H2D/后验-D2H 内存传输。
主机端设备内核代码“调度”指令是相当必要的，有助于中介设备特定的编程反映用户端的偏好，但让用户看不到所有内部决策（组装级审查确实只适用于硬-core，DEVICE-specific，GPU-engineering Aces，如果愿意的话，很难修改）
综上所述，基于“自适应”运行时值的决定将特定“工作单元”移回主机 CPU，而不是在 DEVICE-GPU 中最终确定，并不是最好的我的知识，发生在这个复杂的计算生态系统层次结构的底部（afaik，尝试这样做会非常昂贵）。