OpenCL 2.0 异构计算 [第三版] (中文)
  • Introduction
  • 序言
  • 第1章 简介异构计算
    • 1.1 关于异构计算
    • 1.2 本书目的
    • 1.3 并行思想
    • 1.4 并发和并行编程模型
    • 1.5 线程和共享内存
    • 1.6 消息通讯机制
    • 1.7 并行性的粒度
    • 1.8 使用OpenCL进行异构计算
    • 1.9 本书结构
  • 第2章 设备架构
    • 2.1 介绍
    • 2.2 硬件的权衡
    • 2.3 架构设计空间
    • 2.4 本章总结
  • 第3章 介绍OpenCL
    • 3.1 简介OpenCL
    • 3.2 OpenCL平台模型
    • 3.3 OpenCL执行模型
    • 3.4 内核和OpenCL编程模型
    • 3.5 OpenCL内存模型
    • 3.6 OpenCL运行时(例子)
    • 3.7 OpenCL C++ Wapper向量加法
    • 3.8 CUDA编程者使用OpenCL的注意事项
  • 第4章 OpenCL案例
    • 4.1 OpenCL实例
    • 4.2 直方图
    • 4.3 图像旋转
    • 4.4 图像卷积
    • 4.5 生产者-消费者
    • 4.6 基本功能函数
    • 4.7 本章总结
  • 第5章 OpenCL运行时和并发模型
    • 5.1 命令和排队模型
    • 5.2 多命令队列
    • 5.3 内核执行域:工作项、工作组和NDRange
    • 5.4 原生和内置内核
    • 5.5 设备端排队
    • 5.6 本章总结
  • 第6章 OpenCL主机端内存模型
    • 6.1 内存对象
    • 6.2 内存管理
    • 6.3 共享虚拟内存
    • 6.4 本章总结
  • 第7章 OpenCL设备端内存模型
    • 7.1 同步和交互
    • 7.2 全局内存
    • 7.3 常量内存
    • 7.4 局部内存
    • 7.5 私有内存
    • 7.6 统一地址空间
    • 7.7 内存序
    • 7.8 本章总结
  • 第8章 异构系统下解析OpenCL
    • 8.1 AMD FX-8350 CPU
    • 8.2 AMD RADEON R9 290X CPU
    • 8.3 OpenCL内存性能的考量
    • 8.4 本章总结
  • 第9章 案例分析:图像聚类
    • 9.1 图像聚类简介
    • 9.2 直方图的特性——CPU实现
    • 9.3 OpenCL实现
    • 9.4 性能分析
    • 9.5 本章总结
  • 第10章 OpenCL的分析和调试
    • 10.1 设置本章的原因
    • 10.2 使用事件分析OpenCL代码
    • 10.3 AMD CodeXL
    • 10.4 如何使用AMD CodeXL
    • 10.5 使用CodeXL分析内核
    • 10.6 使用CodeXL调试OpenCL内核
    • 10.7 使用printf调试
    • 10.8 本章总结
  • 第11章 高级语言映射到OpenCL2.0 —— 从编译器作者的角度
    • 11.1 简要介绍现状
    • 11.2 简单介绍C++ AMP
    • 11.3 编译器的目标 —— OpenCL 2.0
    • 11.4 C++ AMP与OpenCL对比
    • 11.5 C++ AMP的编译流
    • 11.6 编译之后的C++ AMP代码
    • 11.7 OpenCL 2.0提出共享虚拟内存的原因
    • 11.8 编译器怎样支持C++ AMP的线程块划分
    • 11.9 地址空间的推断
    • 11.10 优化数据搬运
    • 11.11 完整例子:二项式
    • 11.12 初步结果
    • 11.13 本章总结
  • 第12章 WebCL:使用OpenCL加速Web应用
    • 12.1 介绍WebCL
    • 12.2 如何使用WebCL编程
    • 12.3 同步机制
    • 12.4 WebCL的交互性
    • 12.5 应用实例
    • 12.6 增强安全性
    • 12.7 服务器端使用WebCL
    • 12.8 WebCL的状态和特性
  • 第13章 其他高级语言中OpenCL的使用
    • 13.1 本章简介
    • 13.2 越过C和C++
    • 13.3 Haskell中使用OpenCL
    • 13.4 本章总结
Powered by GitBook
On this page
  • 8.1.1 运行时实现
  • 8.1.2 工作项内的向量化操作
  • 8.1.3 局部内存

Was this helpful?

  1. 第8章 异构系统下解析OpenCL

8.1 AMD FX-8350 CPU

Previous第8章 异构系统下解析OpenCLNext8.2 AMD RADEON R9 290X CPU

Last updated 6 years ago

Was this helpful?

AMD的OpenCL实现可以运行在AMD显卡上和所有x86架构的CPU上。所有主机端代码在x86架构的CPU上执行。不过,AMD的OpenCL实现也可以将x86架构的处理器作为设备,让x86设备运行OpenCL C代码。图8.1展示了FX-8350 CPU的内部架构,该图用来描述x86架构与OpenCL实现之间的映射关系。

要在OpenCL运行时将FX-8350 CPU作为设备,需要使用clGetDeviceIDs()获取该设备句柄。然后将设备句柄作为设备对象传入clCreateContext(),clCreateCommandQueue()和clBuildProgram()。当要使用CPU作为OpenCL C的执行设备时,需要向clGetDeviceIDs()传入CL_DEVICE_TYPE_CPU标识(或CL_DEVICE_TYPE_ALL)。

图8.1 基于AMD打桩机架构的高配CPU——FX-8350

CPU中OpenCL可以使用的核数有8个。如果将整个CPU作为一个独立设备,那么最好是每个核都有独立的命令队列,用来分散并行负载量,这种负载均衡的方式在系统中效率最高。当然在OpenCL中也可以使用设备划分的扩展方式,将CPU划分成多个设备。

8.1.1 运行时实现

OpenCL使用CPU时,运行时在每个核上创建了一个线程(例如,线程池),以便OpenCL内核的执行。另一个主管理线程会根据队列上的任务,将不同的任务分配给不同的线程,同时将正在执行的任务从队列上移除。任意给定的OpenCL内核可能包含成千上万个工作组(其参数以及相应内存都需要提前准备好)。

OpenCL使用栅栏的方式提供细粒度的同步。在基于CPU的传统系统中,操作系统会对线程间通讯进行管理,操作系统会进行一定粒度的同步,使得并行实现更加高效。另外,如果将一个工作组分配到多个CPU核上回造成共享缓存的问题。为了缓解这个问题,OpenCL CPU运行时实现将一个工作组部署在一个CPU核(线程)上。OpenCL工作组中的工作项会按顺序执行(串行)。当前工作组中所有工作项执行完成后,将执行下一个工作组中的工作项。这样来看的话,虽然有很多工作组可以同时执行,但是工作组中的线程并不是并行的关系。图8.2中描绘了OpenCL在FX-8350 CPU上的映射关系。

图8.2 OpenCL在FX-8350 CPU上的映射关系。该芯片将CPU和GPU集成在了一起。

OpenCL中工作项在工作组内是并发,可使用栅栏进行同步。所有线程必须到达栅栏处,才能继续下面的操作。CPU作为设备时,栅栏操作等于是一个工作项终止后,另一个工作项启动;不过,这对于操作系统不现实,因为操作系统会对不同优先级的线程进行处理(例如,中断某个线程,让另一个线程进行)。因此,当整个工作组属于一个线程时,就不会出现线程优先级的问题。AMD的OpenCL CPU运行时实现中,栅栏操作会使用到setjmp和longjmp指令。setjmp将会保存系统状态(保护现场),longjmp将会读取保存了的系统状态,继续之前的执行状态[1]。不过,运行时会为了配合硬件的分支预测器和保证程序栈对齐,针对这两个函数提供两个自定义版本。图8.3展示了CPU线程在工作组中的工作流。

图8.3 x86架构下工作组运行情况

因为工作项的执行方式是串行的,所以当在内核中使用栅栏操作时,原本可以并行的工作组也需要将执行方式转变为串行。

使用setjmp指令时,工作项的数据将从工作项的栈中弹出到寄存器中。为了减少缓存争夺和未命中的情况,并提高层级缓存的利用率,栈数据存放在缓存的何处需要仔细考虑。另外,工作项栈数据是交错存储在内存上,以减少访存冲突,并且数据保存在一个较大的内存页中,以保证物理地址映射的连续性,减少CPU使用转换内存的压力。

8.1.2 工作项内的向量化操作

AMD打桩机微架构具有128位向量寄存器,可以用来处理各种版本SSE和AVX指令。OpenCL C包括一系列向量类型:float2, float4, int4等等。对于数学操作来说,有OpenCL C提供了对应的向量版本,式例如下:

float4 a = intput_data[location];
float4 b = a + (float4)(0.f, 1.f, 2.f, 3.f);
output_data[location] = b;

AMD打桩机微架构中,这些向量都会保存在寄存器中,并且在编译过程中会将这些操作翻译成SSE和AVX指令。这里提供了很重要的性能优化。向量的加载和存储操作,会使用底层代码进行,以提高内存操作的效率。目前,单个工作项可以使用SIMD向量:8.2节将会看到在GPU端的操作与CPU端的区别。

8.1.3 局部内存

AMD打桩机设计中并未对暂存式内存提供专用的硬件。CPU通常会为了减少访存延迟,会有很多层缓存。局部数据通常为了更加高效的访问数据,会将其映射到CPU缓存上,开发者还是享受到了来自硬件的访存加速。为了提高缓存的命中率,局部内存在每个CPU线程上都会开辟一段,并且局部内存可以被工作组中的工作项重复使用。对于串行的工作组来说(因为栅栏、数据竞争或内存冲突),就不需要局部内存,从而会造成之后的缓存未命中。局部内存另外的好处是,减少了内存频繁开辟的开销。图8.4展示了局部内存与AMD CPU缓存的映射关系。

图8.4 工作组(0)的内存地址空间对应的是打桩机CPU的缓存。

虽然,在CPU上使用局部内存也会有潜在的性能收益,不过局部内存会给一些应用带来性能上的负面影响。如果内核中数据具有很好的局部性(比如,矩阵相乘的一部分),之后使用局部内存用来存放需要多次使用到的数据,从而免去对数据的多次拷贝,并且数据存储在L1缓存上,访存效率极高。在这种情况下,如果可用的缓存过小,则会导致性能退化,过小的缓存会造成数据争夺缓存位置,从而增加未命中率和数据拷贝的开销。

[1] J. Gummaraju, L.Morichetti, M. Houstion, B. Snder, B.R. Gaster, B. Zheng, Twin peaks: a software platform for heterogeneous computing on general-purpose and graphics processors. in: PACT 2010: Proceedings of the Nineteenth International Conference on Parallel Architectures and Complilation Techniques. Septerber 11-15, 2010, Vienna, Austria. Association for Computing Machinery, 2010.