dro*_*nus 71 opengl gpgpu opencl
使用GLSL进行计算的OpenCL有哪些特性可供选择？尽管有与图形相关的术语和非实用的数据类型,但对OpenGL有什么实际的警告吗？
例如,可以通过使用其他纹理渲染纹理来完成并行函数评估.减少操作可以通过迭代渲染到越来越小的纹理来完成.另一方面,无法以任何有效的方式进行随机写访问(唯一的方法是通过纹理驱动的顶点数据渲染三角形).这可能与OpenCL有关吗？OpenGL还有什么不可能实现的？
cli*_*hlt 58
OpenCL专为计算而创建.当您使用OpenGL进行科学计算时,您始终必须考虑如何将计算问题映射到图形上下文(即根据纹理和三角形等几何图元进行交谈)以便计算.
在OpenCL中,您只需使用内存缓冲区上的计算内核来计算您的计算,您就可以了.这实际上是一场巨大的胜利(从思考并实施两种变体的角度来看).
内存访问模式虽然相同(您的计算仍然在GPU上进行 - 但这些天GPU变得越来越灵活).
但是,除了使用十几个并行的"CPU"而不打破如何翻译之外,你还有什么期望？例如(愚蠢的例子)傅立叶到三角形和四边形......？
use*_*401 43
到目前为止,在任何答案中都没有提到的是执行速度.如果您的算法可以用OpenGL图形表示(例如,没有分散的写入,没有本地存储器,没有工作组等),它通常比OpenCL对应物运行得更快.我对此的具体体验是在AMD,nVidia,IMG和Qualcomm GPU上进行图像过滤(聚集)内核.即使在硬核OpenCL内核优化之后,OpenGL实现也总是运行得更快.(除此之外:我怀疑这是因为多年的硬件和驱动程序专门针对以图形为导向的工作负载.)
我的建议是,如果您的计算程序感觉它很好地映射到图形域,那么使用OpenGL.如果没有,OpenCL更通用,更简单地表达计算问题.
另一点要提及(或要问)是你是作为业余爱好者(即为自己)或商业(即分发给他人).虽然OpenGL几乎无处不在,但OpenCL完全缺乏对移动设备的支持,并且imho在未来几年内不太可能出现在Android或iOS上.如果一个代码库的广泛跨平台兼容性是一个目标,那么OpenGL可能会被强加给你.
Nic*_*las 23
使用GLSL进行计算的OpenCL有哪些特性可供选择？尽管有与图形相关的术语和非实用的数据类型,但对OpenGL有什么实际的警告吗？
是的:这是一个图形API.因此,你在其中所做的一切都必须按照这些条款制定.您必须将数据打包为某种形式的"渲染".您必须弄清楚如何在属性,统一缓冲区和纹理方面处理数据.
使用OpenGL 4.3和OpenGL ES 3.1 计算着色器,事情变得更加混乱.计算着色器能够通过SSBO /图像加载/存储以类似于OpenCL计算操作的方式访问内存(尽管OpenCL提供实际指针,而GLSL不提供).他们与OpenGL的互操作也比OpenCL/GL互操作快得多.
即便如此,计算着色器也不会改变一个事实:OpenCL计算操作的运行精度与OpenGL的计算着色器完全不同.GLSL的浮点精度要求不是很严格,OpenGL ES的要求也不那么严格.因此,如果浮点精度对于计算很重要,那么OpenGL将不是计算计算所需内容的最有效方法.
此外,OpenGL计算着色器需要具有4.x功能的硬件,而OpenCL可以在更低劣的硬件上运行.
此外,如果您通过选择渲染管道进行计算,OpenGL驱动程序仍将假设您正在进行渲染.因此,它将根据该假设做出优化决策.假设您正在绘制图片,它将优化着色器资源的分配.
例如,如果你渲染到一个浮点帧缓冲区,驱动程序可能只是决定给你一个R11_G11_B10帧缓冲区,因为它检测到你没有对alpha做任何事情,你的算法可以容忍较低的精度.但是,如果使用图像加载/存储而不是帧缓冲,则获得此效果的可能性要小得多.
OpenCL不是图形API; 它是一个计算API.
此外,OpenCL只是让您访问更多的东西.它使您可以访问与GL有关的内存级别.某些内存可以在线程之间共享,但GL中的单独着色器实例无法直接影响彼此(在Image Load/Store之外,但OpenCL在无法访问的硬件上运行).
OpenGL隐藏了抽象背后硬件的功能.OpenCL几乎可以让您了解正在发生的事情.
您可以使用OpenGL进行任意计算.但你不想 ; 而不是有一个完全可行的选择.OpenGL中的计算用于服务图形管道.
为任何类型的非渲染计算操作选择OpenGL 的唯一原因是支持无法运行OpenCL的硬件.目前,这包括许多移动硬件.
Dam*_*mon 12
一个值得注意的特征是分散的写入,另一个是没有"Windows 7智能".正如你可能知道的那样,如果OpenGL没有冲洗2秒左右,Windows 7就会杀死显示驱动程序(不要在准确的时间内确定我,但我认为它是2秒).如果你有一个冗长的操作,这可能会很烦人.
此外,OpenCL显然可以使用比图形卡更多种硬件,并且它没有一个带有"人为约束"的严格的面向图形的管道.运行多个并发命令流也更容易(微不足道).
use*_*655 10
虽然目前OpenGL是图形的更好选择,但这不是永久性的.
OpenGL最终合并为OpenCL的扩展可能是切实可行的.这两个平台的大约80%相同,但是具有不同的语法怪癖,对于大致相同的硬件组件有不同的命名法.这意味着要学习两种语言,要弄清楚两种API.图形驱动程序开发人员更喜欢合并,因为他们不再需要为两个单独的平台开发.这为驱动程序调试留下了更多的时间和资源.;)
另一件需要考虑的事情是OpenGL和OpenCL的起源不同:OpenGL在网络早期的固定管道中开始并获得了动力,随着技术的发展,它逐渐被附加和弃用.OpenCL在某种程度上是OpenGL 的演变,因为OpenGL开始被用于数字处理,因为GPU的(计划外)灵活性允许这样做."图形与计算"实际上更像是一种语义论证.在这两种情况下,您总是尝试将数学运算映射到具有最高性能的硬件.有一些GPU硬件,vanilla CL不会使用,但这样做不会保留单独的扩展.
那么OpenGL如何在CL下工作呢？推测性地,三角形光栅化器可以作为特殊的CL任务排队.特殊的GLSL函数可以在vanilla OpenCL中实现,然后在内核编译期间被驱动程序覆盖为硬件加速指令.在OpenCL中编写着色器,等待提供库扩展,听起来并不是一个痛苦的经历.
召唤一个拥有比另一个更多的功能并没有多大意义,因为他们都获得了80%相同的功能,只是在不同的命名法下.声称OpenCL对图形不利,因为它是专为计算而设计没有意义,因为图形处理是计算.
另一个主要原因是OpenGL\GLSL仅支持显卡.尽管多核使用始于使用图形硬件,但许多硬件供应商正致力于计算多核硬件平台.例如,请参阅英特尔骑士角.
使用OpenGL\GLSL开发计算代码将阻止您使用任何非图形卡的硬件.