OpenCL与图形

OpenCL的出现是对GPCPU编程的一个响应。人们用GPU处理图形，并且开始使用GPU完成工作中的非图形部分。基于这种趋势，异构计算（已经存在很长时间）与图形发生冲突，因此迫切需要一个行业标准。

OpenCL一直与它的图形本源关系紧密。OpenCL是Khronos标准系列的一部分，其中就包含图形标准OpenGL (www. khronos. org/ opengl/) 和OpenGL ES (www. khronos. org/ opengles/)。由于Microsoft 操作系统的重要性，OpenCL还在密切跟踪DirectX的发展（www. gamesforwindows. com/en-US/ directx/)。

开始讨论OpenCL和图形之前，我们先回到之前提到的图像内存对象。图像内存对象是包含纹理、帧缓冲区或图像的1维、2维或3维对象。实现可以支持各种图像格式，不过至少必须支持标准RGBA格式。图像对象使用OpenCL中定义的一组函数来管理。OpenCL还定义了采样器对象，允许程序员采样和过滤图像。这些特性已经集成到OpenCL API的一组核心图像管理函数中。

一旦创建了图像，必须将它们传送到图形管线来渲染。因此，OpenCL 包含一个标准图形API的接口会很有用。不过，并不是致力于OpenCL的每一家开发商都对这些图形标准感兴趣。因此，我们未在核心OpenCL规范包含这个内容，而是在OpenCL标准的附录中将它们定义为一组可选的扩展。

这些扩展包括以下功能：
1）从OpenGL上下文创建一个OpenCL上下文
2）在OpenCL、OpenGL和OpenGL ES之间共享内存对象
3）从OpenGL同步对象创建OpenCL事件对象
4）与Direct3D 10共享内存对象

OpenCL的内容

OpenCL框架可以划分为以下组成部分
1）OpenCL平台API：平台API定义了宿主机程序发现OpenCL设备所用的函数以及这些函数的功能，另外还定义了为OpenCL应用创建上下文的函数。
2）OpenCL运行时API：这个API管理上下文来创建命令队列以及运行时发生的其他操作。例如，将命令提交到命令队列的函数就来自OpenCL运行时API。
3）OpenCL编程语言：这是用来编写内核代码的编程语言。它基于ISO C99标准的一个扩展子集，因此通常称为OpenCL C编程语言。

平台API

平台( platform)一词在OpenCL中有非常特定的含义。它表示宿主机、OpenCL 设备和OpenCL框架的组合。一个异构计算机上可以同时存在多个OpenCL平台。例如，CPU开发商和GPU开发商可以在一个系统上分别定义自己的OpenCL框架。程序员需要一种方法查询系统中可用的OpenCL框架。他们需要查找哪些OpenCL.设备可用，这些OpenCL设备有什么特性。另外，他们还需要控制这些框架和设备的哪个子集构成给定OpenCL应用中使用的平台。

这些功能由OpenCL平台API中的函数解决。在后面的章节中将会看到，我们重点讨论OpenCL程序员为宿主机程序编写代码时，每个OpenCL应用程序都以类似的方式打开，调用平台API的函数为OpenCL计算定义上下文。

运行时API

平台API中的函数为OpenCL应用定义上下文。运行时API则强调使用这个上下文满足应用需求的函数。这是一个庞大而且确实相当复杂的函数集。

运行时API的第一个任务是建立命令队列。可以将命令队列关联到一个设备，不过一个上下文中可以同时有多个活动的命令队列。

有了命令队列，就可以使用运行时API来定义内存对象和管理内存对象所需要的所有其他对象（如对于图像对象还需要采样器对象)。管理内存对象是一个很重要的任务。为了支持垃圾回收，OpenCL会跟踪多少个内核实例使用这些对象（也就是说，持有一个内存对象)，以及内核何时用完一个内存对象（即释放一个内存对象)。

运行时API管理的另一个任务是创建构建动态库所用的程序对象，内核就由这些动态库定义。程序对象、编译程序对象的编译器以及内核定义都在运行时层处理。

最后，与命令队列交互的命令都由运行时层的函数发出。管理数据共享和对内核执行施加约束的同步点也由运行时API处理。

可以看到，运行时API函数完成了宿主机程序的大部分具体工作。要想一次掌握运行时API，从第一个函数开始学完所有函数，这是很有压力的。我们发现，更好的做法是使用一种实用的方法。掌握真正要使用的函数。过一段时间，你就会把它们全面覆盖到，并完全掌握，不过要根据OpenCL应用的具体需要来学习这些函数。

内核编程语言

宿主机程序非常重要，不过完成OpenCL 中实际工作的是内核。有些OpenCL实现允许你与非OpenCL编写的原生内核交互，不过，大多数情况下都需要编写内核来完成应用中的特定工作。

OpenCL中的内核编程语言称为OpenCLC编程语言，因为我们希望过一段时间后可以定义符合规范的其他语言。它由ISo C99语言派生而来。

在OpenCL 中，要对支持可移植性特别当心。这要求我们标准化不同类的OpenCL 设备之间的最小公共子集。由于C99中有些特性只有CPU能够支持，所以在定义OpenCL C编程语言时，我们去掉了C99的一些语言特性。删除的主要语言特性包括：
1）递归函数
2）函数指针
3）位域

另外，我们不支持完整的标准库集合。OpenCL编程语言中不支持的标准头文件很多，不过程序员最有可能遗漏的是stdio.h和 stdlib.h。再次说明，一旦不再将通用处理器作为OpenCL设备，这些库将很难获得支持。

由于需要保持OpenCL核心抽象的真实性，所以会带来另外一些限制。例如，OpenCL定义了一组内存地址空间。联合 (union）或结构（structure）不能混合类型。另外，OpenCL还定义了一些不透明的类型，例如，支持图像的内存对象。OpenCL C编程语言除了允许将这些类型作为参数传递给函数外，不允许对它们做任何其他处理。

我们将OpenCLC编程语言限制为只满足用于OpenCL的关键OpenCL 设备的需求。出于同样的原因，促使我们扩展语言以及以下方面：
1）矢量类型和这些类型实例上的操作。
2）地址空间限定符，支持OpenCL对多个地址空间的控制。
3）一组丰富的内置函数，支持OpenCL应用中通常需要的功能。
4）全局和局部内存中处理无符号整数和单精度标量变量的原子函数。

大多数编程语言忽略浮点算术系统的特定细节。它们只是从硬件导入算术系统，从而完全避开这个问题。由于所有主流CPU都支持IEEE754和IEEE 854标准，所以这个策略是可行的。实际上，通过集中研究这些浮点标准，硬件开发商在为语言开发商解决浮点定义的有关问题。

不过，在异构世界中，如果脱离CPU，那么对浮点算术运算的支持会有更多的选择。过去通过与硬件开发商的紧密合作，我们希望大力推动他们完善对IEEE浮点标准的支持。与此同时，我们不希望对这些开发商过于苛刻，所以赋予他们一定的灵活性可以避开IEEE标准中一些不常使用但实现很困难的特性。后面会详细讨论有关细节，不过从高层可以总结为OpenCL需要以下特性：
1）对IEEE754格式的全面支持。双精度是可选的，不过如果提供双精度，也必须符合IEEE 754格式。
2）支持默认的IEEE 754舍入模式，即“舍入为最近整数”。其他舍入模式尽管值得推荐 (因为数值分析学者需要这些模式)，但它们是可选的。
3）尽管IEEE规范要求动态改变舍入模式，但OpenCL中的舍入模式是静态设置的。
必须支持特殊值INF(无穷大）和NaN(非数字)，不过不要求提示NaN (通常反映并发系统中的问题)。
4）非规格化数 (小于1的数乘以所支持的最大负指数) 可以化简为0。如果你还不了解为什么这很重要，不用担心，很多人都与你一样。这也是数值分析学者很依赖但很少有程序员了解的另一个特性。

关于浮点数异常还有很多其他规则，不过它们对大多数人来说都过于复杂、过于深奥，没有必要在这里多做说明。关键是要了解我们已努力满足IEEE754的大多数内容，同时省略了很少使用而且 (在配有矢量单元的异构平台上) 难以支持的一些特性。

OpenCL规范并不仅限于IEEE标准。在OpenCL规范中，还有一些表格详尽地定义了数学函数中允许的相对误差。要想了解所有这些错误确实难度很大，不过对于编写详细数值代码的程序员来说，定义这些错误是至关重要的。

综合以上浮点数需求、限制和扩展，就得到了一个非常适合当前异构平台的编程语言，随着这些平台中使用的处理器继续发展，并变得更为通用，OpenCL C编程语言也会随之发展。

首先是一个定义上下文的宿主机程序。图1-9中的上下文包含两个OpenCL设备、一个CPU和一个GPU。接下来定义了命令队列。这里有两个队列，一个是面向GPU的有序命令队列，另一个是面向CPU的乱序命令队列。然后宿主机程序定义一个程序对象，这个程序对象编译后将为两个OpenCL设备（CPU和GPU)生成内核。接下来宿主机程序定义程序所需的内存对象，并把它们映射到内核的参数。最后，宿主机程序将命令放入命令队列来执行这些内核。