[求助] 用opencl在GPU上的float运算和CPU上的float计算

moon8150 2013-12-09 06:17:14
用opencl在GPU上的float运算和CPU上的float计算,结果精度相差很大,整数就没问题,是少设置了什么还是怎么回事?
...全文
2263 4 打赏 收藏 转发到动态 举报
写回复
用AI写文章
4 条回复
切换为时间正序
请发表友善的回复…
发表回复
lcwyylcwyy 2014-02-18
  • 打赏
  • 举报
回复
另外,编程方面也应该注意一下,尽量用相近的数相加吧,大加大,小加小。
menzi11 2014-02-11
  • 打赏
  • 举报
回复
为了速度,GPU计算ieee标准浮点数会将非规格浮点数认为是0.而CPU默认不是.
outstander 2013-12-12
  • 打赏
  • 举报
回复
虽然GPU浮点运算,CPU的SSE浮点运算以及CPU普通CPU浮点运算这三类指令都以IEEE754标准存储float变量,但它们实现浮点运算的加减乘除的方式是不一样的,这就导致了前两者与CPU普通浮点运算精度不一致 将GPU的运算结果和CPU的SSE指令相对比,精度会是一样的。它们在硬件上实现是类似,GPU和SSE的设计更加低功耗和快速。 请参考:http://developer.download.nvidia.com/assets/cuda/files/NVIDIA-CUDA-Floating-Point.pdf
fronteer 2013-12-10
  • 打赏
  • 举报
回复
这个问题以前也有人提出,我们也很感兴趣,我建议将问题细化一下: 1) 不用 Runtime 函数的情况,如在kernel上做两个float类型数的除法,看 CPU 和 GPU 设备上的结果有多大差距. 这种情况,结果只和编译器有关。在GPU上应该没太多可选择的,在CPU上编译器可选择用x387或SSE指令集作浮点运算, 我记得在CPU上,如果是64位Binary, 编译器会用SSE指令集做浮点运算;如果是32位Binary,则编译器保留用x387做浮点 运算,若要用SSE做浮点运算,需手工用 enable-sse的选项. SSE和x387所能达到的精度是不一样的,因为x387有80位寄存器,SSE只是64位寄存器. SSE的优势是和通用寄存器之间传数据更方便. 2) 如果用了Runtime 函数,则问题更复杂,因为我们目前没有文档知道在 kernel 中是如何使用外部函数的。 不象在 CPU 上用一般C语言写的程序中,我们很容易将一个.dll或.so库中的代码通过反汇编,来确定其函数用的具体的指令集. 这种情况我建议先定位是那个 Runtime 函数导致的精度差别. 如是 sqrt(), sin() 或 exp(),还是所有这些函数都或多或少都会导致精度问题。以后我们获得了更多的关于GPU上ALU及指令集的资料及Runtime的实现方式,也许能作出解释 3)另外,你的 OpenCL 浮点代码在 CPU 设备上运行的结果,和用 CPU上 native-C 写的代码的结果,有差别吗?
这是一个基于Delphi XE2的OpenCL控件。其中使用到了Khronos Group Inc.的CL.pas单元。 OpenCL的设计思路和OpenGL类似,对于大部分Delphi的设计者来说,非常不习惯,而且使用起来并不十分方便 设计这个TOpenCL控件的目的不是替代OpenCL的原生使用方式,而是为了开发者能够快速对OpenCL进行应用并且可以 用来测试性能和功能。 使用TOpenCL控件,可以象使用数据库控件那样方便的去调用OpenCL程序,不需要太多代码就可以运行一个OpenCL 的Kernel。这对于学习和深入研究OpenCL的性能有一个很好的铺垫。 使用OpenCL做并行计算的一个主要因素就是提高大数据量计算的速度,这和通常的业务处理类程序大不相同,因 此提升OpenCL的运行效率是至关重要的,本控件附带的Demo程序中,是对两个长度分别为8192和32的float数组,进行 一维卷积计算的。在选择不同的数据传递方式(如使用显存还是Host内存、使用只读方式还是可读写或者只写方式), 或者不同的Device(如在多核CPU上和GPU上运行Kernel程序)上运行,其效率相差是非常大的。 Demo程序中缺省的使用不显示获取结果的方式运行,缺省的数据传输是使用显存(CPU作为Device的时候,其实还 是系统内存)并Copy数据的方式,因此显示结果始终是0。当输出的参数传递方式改为直接使用系统内存指针的方式时, 不使用显示获取计算结果则是可以得到运算结果的。这些参数之间的差异,读者自行测试并仔细体会,通过调整,相信 可以得到最佳的运行方式。 Demo中包含了四个Kernel函数,分别是Convolution_Kernel_With_Barrier。这是一个带有同步函数Barrier的卷积 过程,并在卷积完成后,等待所有单元计算完毕,然后对结果进行微分(差商)处理,实际情况表明Barrier函数对GPU 的影响甚微,但如果使用CPU作为Device计算,则效率影响非常大,其耗时几乎和单核计算不相上下,估计是同步函数 在等候的过程中,引起了CPU对Catch竞争访问的结果吧。对这种情况,反倒不如拆分成两个Kernel进行单独计算,其累 积的计算时间基本上为两个独立Kernel耗时只和。 Differ_Kernel是单独进行微分计算的,是为了验证上面计算耗时结果的。 Convolution_Kernel是只进行卷积计算的,可以认为和Differ_Kernel前后执行,其结果应该和Convolution_Kerne- l_With_Barrier单独执行是一样的。 Convolution则是一个简单的计算过程,用来测试启动Kernel、等候数据等操作会占用的时间情况的。 OpenCL其实并不是想象中那么美妙,也不是想象中的那么复杂,但要使用好OpenCL,就必须认真的对待每个细节, 甚至到每一个函数调用或者if控制等,大家可以参考“http://hi.baidu.com/fsword73”,上面涉及到的很多方面,都是 可以提升Kernel运行效率的。 目前这个TOpenCL控件只是作者为了测试OpenCL运行效率编写的一个小的工具,作为一个测试工具或者技术积累阶段 的工具足矣,但在实际工程中,希望还是能够尽可能使用原生的调用方式,控件模式势必会带来一定的性能损失的,这是 无法克服的是一个实际情况,对于某些流式数据处理的计算而言,多次重复使用同一个Kernel对流式数据进行处理的,则 使用本控件应该不会造成太大的性能影响。 目前TOpenCL不支持多个Device同时工作,可以选择CPUGPU或者APU作为首选设备, X86下运行正常,X64下运行仍有 问题,疑和cl.pas中对context等处理的方式不支持X64或者其他原因。 目前支持的OpenCL版本为1.2。控件没有考虑OpenCL和OpenGL协同工作的情况,需要做这方面应用或者测试的读者,请 自行处理。 一下是控件几个主要类的引用关系图。供参考。 由于时间的关系,不可能提供详细的使用说明,往谅解,有问题可邮件与作者联系或者QQ联系。 Mail:18909181984@189.cn QQ:57440981 TOpenCL --| | |--TclKernels --| |--- TclKernel --| | |-- TclK

602

社区成员

发帖
与我相关
我的任务
社区描述
异构开发技术
社区管理员
  • OpenCL和异构编程社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧