OpenCL体系结构分析
OpenCL是一个开放的行业标准，用于对组织到单个平台中的CPU、GPU和其他离散计算设备的异构集合进行编程。它不仅仅是一种语言。OpenCL是一个用于并行编程的框架，包括一种语言、API、库和一个支持软件开发的运行时系统。例如，使用OpenCL，程序员可以编写在GPU上执行的通用程序，而无需将其算法映射到3D图形API（如OpenGL或DirectX）上。
OpenCL的目标是希望编写可移植但高效的代码的专业程序员。这包括库编写者、中间件供应商和面向性能的应用程序程序员。因此，OpenCL提供了一个底层硬件抽象和一个支持编程的框架，并公开了底层硬件的许多细节。
为了描述OpenCL背后的核心思想，将使用模型的层次结构：
平台模型
内存模型
执行模型
编程模型
3.1. 平台模型
OpenCL的平台模型定义如下。该模型由连接到一个或多个OpenCL设备的主机组成。OpenCL设备被划分为一个或多个计算单元（CU），这些计算单元被进一步划分为一种或多种处理元件（PE）。设备上的计算发生在处理元件内。
OpenCL应用程序实现为主机代码和设备内核代码。OpenCL应用程序的主机代码部分，根据主机平台固有的模型在主机处理器上运行。OpenCL应用程序主机代码将内核代码作为命令从主机提交给OpenCL设备。OpenCL设备在设备内的处理元件上执行命令计算。
OpenCL设备在如何将计算映射到设备处理元件上具有相当大的自由度。当计算单元内的处理元件在处理元件之间执行相同的语句序列时，控制流被称为收敛的。为在多个处理元件上执行单个指令流，而优化的硬件非常适合于聚合控制流。当控制流从一个处理元件变化到另一个处理单元时，称之为分流。虽然内核总是以收敛的控制流开始执行，但由于内核内的分支语句，收敛和发散的控制流可能发生在单个内核内。这为可以使用OpenCL实现的算法，提供了很大的灵活性。
图1. 平台模型…一台主机加上一个或多个计算设备，每个计算设备都有一个或更多由一个或几个处理元件组成的计算单元。
程序员可以以OpenCL C源字符串、SPIR-V中间语言或实现定义的二进制对象的形式提供程序。OpenCL平台提供了一个编译器，用于将这些形式的程序转换为可执行程序对象。设备代码编译器可以是联机的，也可以是脱机的。在线编译器在使用标准API执行主机程序期间可用。离线编译器是在主机程序控制之外调用的，使用特定于平台的方法。OpenCL运行时允许开发人员获得先前编译的设备程序可执行文件，并能够加载和执行先前编译的可执行设备程序。
OpenCL定义了两种类型的平台配置文件：完整配置文件和减少功能的嵌入式配置文件。完整配置文件平台必须为其所有设备提供在线编译器。嵌入式平台可以提供在线编译器，但不需要这样做。
设备可能会将专用功能作为内置内核公开。该平台提供了用于枚举和调用设备提供的内置内核的API，但在其他方面没有定义它们的构造或语义。自定义设备只支持内置内核，不能通过内核语言进行编程。
图2. OpenCL执行模型中定义的状态和状态之间的转换。这些转换的一个子集通过评测接口公开。
命令通过事件对象传达其状态。通过将与命令相关联的事件状态设置为CL_COMPLETE来指示成功完成。未成功完成会导致命令异常终止，这是通过将事件状态设置为负值来指示的。在这种情况下，与异常终止的命令相关联的命令队列和同一上下文中的所有其他命令队列可能不再可用，并且它们的行为是实现定义的。
在解决了限制命令顺序的先决条件之前，提交到设备的命令不会启动。这些先决条件有三个来源：
它们可能源于提交到命令队列的命令，该命令队列限制了命令的启动顺序。例如，在命令队列屏障之前的所有命令完成之前，遵循该屏障的命令不会启动。
先决条件的第二个来源是通过事件表达的命令之间的依赖关系。命令可以包括可选的事件列表。该命令将等待，直到列表中的所有事件都处于CL_COMPLETE状态才启动。通过这种机制，事件对象定义命令之间的顺序约束，并协调主机和一个或多个设备之间的执行。
第三个先决条件来源可以是程序范围全局变量的非平凡C初始化器或C++构造函数的存在。在这种情况下，OpenCL C/C++编译器应生成执行C初始化或C++构造的程序初始化内核。这些内核必须由OpenCL运行时在设备上执行，然后才能在同一设备上执行来自同一程序的任何内核。任何程序初始化内核的ND范围都是（1,1,1）。当多个程序链接在一起时，属于不同程序的程序初始化内核的执行顺序是未定义的。
程序清理可能导致OpenCL运行时执行一个或多个程序清理内核。这是由于程序范围变量存在非平凡的C++析构函数。执行任何程序清理内核的ND范围是（1,1,1）。来自不同程序（链接在一起）的清理内核的执行顺序是未定义的。
图3. ND范围索引空间的一个示例，显示了工作项、它们的全局ID以及它们到工作组和本地ID对的映射。在这种情况下，假设在每个维度中，工作组的大小均除以全局ND范围大小（即，所有工作组都具有相同的大小），并且偏移量等于零。
在一个工作组中，工作项可以分为多个子组。工作项到子组的映射是实现定义的，并且可以在运行时查询。虽然子组可以用于多维工作组，但每个子组都是一维的，任何给定的工作项都可以查询它是哪个子组的成员。
图4. OpenCL平台中公开的命名地址空间。全局存储器和恒定存储器在上下文中的一个或多个设备之间共享，而本地存储器和专用存储器与单个设备相关联。每个设备可以包括可选的高速缓存，以支持对其全局和恒定地址空间的视图的有效访问。
程序员可以使用存储器一致性模型的特征, 来管理从可能在一个或多个设备上运行的,多个工作项对全局存储器的安全访问。此外，当使用共享虚拟存储器（SVM）时，还可以使用存储器一致性模型, 来确保主机线程安全地访问共享存储器区域中的存储器位置。
实现应确保不会计算出循环依赖于其自身计算的“凭空”值。
注意：根据上述规则，并且独立于前面脚注的C++问题，已知在以下有问题的示例中，x==y==42是有效的最终状态：
global atomic_int x = ATOMIC_VAR_INIT(0);
local atomic_int y = ATOMIC_VAR_INIT(0);
unit_of_execution_1:
... [execution not reading or writing x or y, leading up to:]
int t = atomic_load_explicit(&y, memory_order_acquire);
atomic_store_explicit(&x, t, memory_order_release);
unit_of_execution_2:
... [execution not reading or writing x or y, leading up to:]
int t = atomic_load_explicit(&x, memory_order_acquire);
atomic_store_explicit(&y, t, memory_order_release);
这不是有用的行为，实现不应该利用这种现象。应该预料到，在未来，这可能会被OpenCL委员会对内存模型描述的适当更新所禁止。
