AMD连发四款OpenCL加速计算开发工具

gtx5

AMD今天宣布推出四款全新的软件开发工具和方案，可进一步优化应用程序对OpenCL标准规范的支持，并且全部支持Fusion APU融合处理器。
gDEBugger：一款先进的OpenCL/OpenGL调试器、 程序分析器和内存分析器，可以在AMD GPU上实时调试OpenCL内核，并在分析内核变量和数据的同时单步调试源代码。该工具来自新成立的AMD研发中心，由AMD 2010年十月收购的新兴公司Graphic Remedy组建而来。
gDEBugger可作为微软Visual Studio的插件使用，支持Windows Vista/7 32/64位操作系统，将于近期提供下载。
官方页面：
http://developer.amd.com/gDEBugger

Parallel Path Analyzer(简称PPA)：一款先进的分析工具，用于开发能够同时针对GPU 和CPU负载进行优化的应用程序，能使数据传输和核心执行可视化，识别整个系统范围的关键路径，定位数据依赖性。
Global Memory for Accelerators(简称GMAC)：一套应用程序接口(API)，提供了一个框架，让开发人员能够借助OpenCL的强大计算能力来创建应用程序，同时无需专门在GPU和CPU的不同地址空间去管理多个数据缓冲区。
Task Manager：也是一套API，提供了一个在某一异构多核环境中管理计算任务的框架。OpenCL核心可以被自动安排来在一个可用的、适合相关任务的设备上执行指令，从而提供动态负载平衡、优化可用计算资源的使用，免除专门处理时间表的负担。
以上三款工具都将在第三季度放出Beta测试版。
gDEBugger截图：

OpenCL/OpenGL API级别实时调试

在线OpenCL内核调试

全面与Visual Studio集成

API状态查看

对象分析

OpenCL程序和OpenGL着色器资源导出

OpenCL/OpenGL支持与160多个扩展

heavenboy

好像与家用无关..

voidshatter

不知道现在OpenCL程序是不是人写的，记得以前看到有人说过ATI Stream的程序不是给人写的，每次换个驱动版本就得大改特改。反正这个月底我就试试CUDA好写不。。

hjdl60

从实际出发，这里有几个有能力有时间开发OPENCL的？现实点吧!看下图，通过*.obj格式支持MAYA，3DSMAX，注意最下面所显示的渲染时间，用的是GTX470，比起以前来说速度快多了，对于出图的人来说，时间就是金钱!
用的是CUDA！

asdfjkl

voidshatter 发表于 2011-6-13 21:41
不知道现在OpenCL程序是不是人写的，记得以前看到有人说过ATI Stream的程序不是给人写的，每次换个驱动版本 ...

瞎扯的吧；
源代码应该只要写一遍，遇上新的驱动需要重新编译一次可执行文件；你该不会连这个都搞不懂吧？ {lol:]{lol:]{lol:]

开普勒

voidshatter 发表于 2011-6-13 21:41
不知道现在OpenCL程序是不是人写的，记得以前看到有人说过ATI Stream的程序不是给人写的，每次换个驱动版本 ...

OpenCL我写过，不难写。设备端程序和CUDA很像，一些简单的程序甚至直接替换关键字就可以在OpenCL和CUDA之间互转。我认为懂CUDA的一星期内能学会OpenCL，反之亦然。代码是像GLSL那样以文本形式存放，使用前BuildProgram再执行的。

主机端程序比较繁琐，跟CUDA的Driver API方式很像，基本上能找到一一对应的函数。不过我用的时候还不支持CUDA的Runtime API那样的偷懒调用方式。

OpenCL的库比较少，CUDA的库比较丰富。CUDA 3.0之后出现的一些高级特性，目前OpenCL还实现不了。

voidshatter

asdfjkl 发表于 2011-6-13 23:44
瞎扯的吧；
源代码应该只要写一遍，遇上新的驱动需要重新编译一次可执行文件；你该不会连这个都搞不懂吧 ...

不是你说的这个问题，而是说A卡以前每次换了驱动之后，就会引入一大堆的bug，导致很多原本正常工作的代码，必须得改写。你从来不逛A卡的开发者论坛的吧？

voidshatter

开普勒 发表于 2011-6-14 00:26
OpenCL我写过，不难写。设备端程序和CUDA很像，一些简单的程序甚至直接替换关键字就可以在OpenCL和CUDA ...

瞻仰一下大牛～

请教一下，如果是一个最基本的简单问题，纯算对数函数的话，比如说是一个巨大的双精度浮点矩阵，需要计算其中每个元素的自然对数，N卡运行CUDA代码，相比A卡运行OpenCL，哪个快呢？

如果不只是考虑上面那个简单例子，而是综合考虑各种常见的数学运算的话（当然也要同时考虑各种branching），如果是把N卡的CUDA代码移植为OpenCL代码但依然在N卡上运行的话，N卡跑OpenCL会比N卡跑CUDA慢么？慢多少呢？

还有个问题我一直想不明白，为什么A卡和OpenCL就是打死不支持返回显存占用值的函数？为什么要封装起来不让开发者看到呢？

nom8393

darkstorm 发表于 2011-6-14 06:15
双精度的话A卡比Geforce快几倍，只要能跑起来。N卡如果用Tesla的话双精度速度不会低于A卡，但用Tesla的人不 ...

你这话的依据从何而来？

nom8393

voidshatter 发表于 2011-6-14 00:49
瞻仰一下大牛～

请教一下，如果是一个最基本的简单问题，纯算对数函数的话，比如说是一个巨大的双精度 ...

理论上说，由于现在A卡都是走暴力运算的路子，只要能够100%利用运算资源，那是肯定比同级N卡的运算性能要快的。但是，又是由于A卡的暴力运算架构（4D或者4D+1D），导致在计算过程中的优化是必须的。
我怀着恶意推测AMD的OpenCL工具是无法进行SP级别优化的，那也就是说必须由开发人员来完成底层的资源利用优化；而NV的CUDA则基本不需要开发者来做SP级别的优化。这就导致同级N卡的通用计算性能基本上都会高过A卡。

尤其是你说得巨大矩阵的运算，CUDA占得优势那是太大了，不论是从并行线程能力上还是资源调配上。具体信息你可以参考David Kirk写的这本书：
Programming Massively Parallel Processors: A Hands-on Approach

nom8393

voidshatter 发表于 2011-6-14 00:38
不是你说的这个问题，而是说A卡以前每次换了驱动之后，就会引入一大堆的bug，导致很多原本正常工作的代码 ...

我也对AMD的开发驱动的前后一致性问题比较感兴趣，毕竟CUDA的基本架构从GF 8800开始就基本固定下来了，移植问题早就不是问题了。而A卡的架构变动这么频繁对通用计算开发者来说肯定不是好事。

nom8393

hjdl60 发表于 2011-6-13 22:05
从实际出发，这里有几个有能力有时间开发OPENCL的？现实点吧!看下图，通过*.obj格式支持MAYA，3DSMAX，注意 ...

{:5_194:} CUDA的开发亲和性和效能那是肯定高一些的，毕竟是NV的亲生儿；至于OpenCL的效能为什么不高，我怀疑是不是NV故意不给优化——要知道CUDA工具也是能够直接开发OpenCL代码的，不应该产生这么大的性能差别。

nom8393

回复 gtx5 的帖子

{:5_201:}看来AMD并没有像某些粉丝那样目光短浅：只把游戏性能搞好就能统一GPU市场那是胡说。通用计算领域的拓展必不可少！
PS：不过这个工具怎么有点像山寨版的Nsight？通用寻址范围也和CUDA4.0不谋而合？AMD工具还是和NV最新的CUDA4.0Tool kit和Nsight2.0差不少啊。

gzpony

nom8393 发表于 2011-6-14 09:02
回复 gtx5 的帖子

看来AMD并没有像某些粉丝那样目光短浅：只把游戏性能搞好就能统一GPU市场那是胡 ...

游戏的GPU正变得前途不足。尤其现在云计算逐渐推广和被接受，到时候多数游戏用cpu或者主板集成的GPU+云计算服务器就可以玩。独立游戏GPU逐渐也变成现在独立声卡一样，由少数hi-end玩家来买，性能很好；但多数人用集成GPU。
所以拓展GPU的使用领域，是各GPU厂商生死攸关的事情。真听某些粉丝的意见做的话，各大厂商早在很多年前就完蛋了。

voidshatter

nom8393 发表于 2011-6-14 08:54
理论上说，由于现在A卡都是走暴力运算的路子，只要能够100%利用运算资源，那是肯定比同级N卡的运算性能要 ...

又见高人～那么请问如果我有大量的字符串比较运算（string matching），举个例子，我有非常多对字符串，每个字符串是50个字符，我需要知道每一对字符串之间的距离（editing distance）是多少，这样的运算是什么样的呢？整数运算？这种运算是不是不适合显卡来算呢？

nom8393

voidshatter 发表于 2011-6-14 20:24
又见高人～那么请问如果我有大量的字符串比较运算（string matching），举个例子，我有非常多对字符串，每 ...

我大概知道你想做什么了。如果是变长字符串搜索的话，不是很适合用GPU来做。原因是GPU的运算优势在于使用海量运算资源来并行计算得出结果；而变长字符串搜索是无法确定运算字符串的实际长度，从而会导致将你提出的运算拆分开来进行并行处理十分困难。而如果是定长字符串内部的对比，则应该可以较好进行处理：将两个需要比较字符串中的一个字符串看作是一个51×51矩阵的每行第一个元素，而将另一个字符串看作是每列的第一个元素，然后将字符串之间字符值的差异计算转化为矩阵对应元素的差值求和运算。
不过有一点我需要提醒你，字符数值转化为浮点数值的过程可能对你的运算有副作用，据我所知CUDA是不能直接使用整形或者字符类型进行运算的。

开普勒

voidshatter 发表于 2011-6-14 00:49
瞻仰一下大牛～

请教一下，如果是一个最基本的简单问题，纯算对数函数的话，比如说是一个巨大的双精度 ...

双精度的话Geforce阉割得比较厉害，普通运算（乘、加）5870大概是470的3倍多速度。至于超越函数，我没专门比较过纯对数，总体来说，超越函数计算吞吐量470反倒是5870的3倍多速度。当时用的是Stream 2.2。不知道现在有没有改进。

一般的CUDA程序移植到OpenCL后在相同的N卡平台上运行，速度不会有太大区别。

nom8393

darkstorm 发表于 2011-6-14 20:49
回复 nom8393 的帖子

当然可以用char和整型！已经有很多很多...基于GPU的字符串比较和hash程序了

哦，我记错了。int和char应该是直接支持，String是无法支持的，只能用char[]。

开普勒

nom8393 发表于 2011-6-14 08:54
理论上说，由于现在A卡都是走暴力运算的路子，只要能够100%利用运算资源，那是肯定比同级N卡的运算性能要 ...

AMD的文档里鼓励开发人员尽量使用float4之类的矢量，因为可以优化在AMD GPU上的访存和充分利用ALU，而且对OpenCL for CPU来说也可以生成SSE指令。我认为这样是在开历史倒车。

不过实际使用时，简单的OpenCL程序直接写成标量形式的话，在A卡上跑还是能达到写成矢量形式程序的速度，应该是编译器自动把相邻线程打包了。复杂的程序最好还是靠人工打包。