OpenGL与OpenCL，哪个select，为什么？
什么特性使OpenCL独一无二地selectOpenGL和GLSL进行计算？ 尽pipegraphics相关的术语和不切实际的数据types，是否有任何实际的OpenGL警告？
例如，并行函数评估可以通过使用其他纹理渲染纹理来完成。 减less操作可以通过迭代渲染到更小和更小的纹理来完成。 另一方面，随机写访问不可能以任何有效的方式进行（唯一的方法是通过纹理驱动的顶点数据来渲染三angular形）。 OpenCL有可能吗？ 还有什么可能不可能与OpenGL？
OpenCL是专门为计算而创build的。 当您使用OpenGL进行科学计算时，您总是要考虑如何将您的计算问题映射到graphics上下文（即，根据纹理和三angular形等几何图元进行交谈），以便使计算进行。
在OpenCL中，您只需在内存缓冲区中使用计算内核来计算您的计算结果，然后就可以开始了。 这实际上是一个巨大的胜利（从思考和实施两种变体的angular度来说）。
内存访问模式虽然相同（您的计算仍然在GPU上发生 – 但现在GPU变得越来越灵活）。
但是，除了使用十几个并行的“CPU”，还有什么可以期待的，而不会突破你的头脑，例如（愚蠢的例子）Fourier到三angular形和四边形。
迄今为止，没有任何答案提到的是执行速度。 如果你的algorithm可以在OpenGLgraphics中expression（例如没有分散写入，没有本地存储器，没有工作组等），它往往比OpenCL对应的运行速度快。 我的具体经验是在AMD，nVidia，IMG和Qualcomm GPU上进行图像过滤（收集）内核。 即使在OpenCL内核优化之后，OpenGL实现总是运行得更快。 （撇开：我怀疑这是由于多年的硬件和驱动程序专门针对面向graphics的工作负载）。
我的build议是，如果你的计算机程序感觉像很好地映射到graphics领域，那么使用OpenGL。 如果不是这样的话，OpenCL更为一般和简单地expression计算问题。
还有一点要提到（或者问）是你是作为一个业余爱好者（也就是你自己）写的还是商业的（即分发给他人）。 虽然OpenGL几乎在任何地方都受到支持，但是OpenCL完全缺乏对移动设备的支持，而且在未来几年内，不太可能出现在Android或iOS上。 如果单一代码库的广泛的跨平台兼容性是一个目标，那么OpenGL可能会被强加给你。
什么特性使OpenCL独一无二地selectOpenGL和GLSL进行计算？ 尽pipegraphics相关的术语和不切实际的数据types，是否有任何实际的OpenGL警告？
是的：这是一个graphicsAPI。 因此，你所做的一切都必须按照这些条款来制定。 你必须把你的数据打包成某种forms的“渲染”。 你必须弄清楚如何在属性，统一缓冲区和纹理方面处理你的数据。
随着OpenGL 4.3和OpenGL ES 3.1 计算着色器 ，事情变得更加混乱。 计算着色器可以通过SSBO / Image Load / Store以类似于OpenCL计算操作的方式访问内存（尽pipeOpenCL提供了实际的指针，而GLSL则不提供）。 与OpenGL的互操作性也比OpenCL / GL互操作性快得多。
即使如此，计算着色器也不会改变一个事实：OpenCL计算操作的运行精度与OpenGL的计算着色器完全不同。 GLSL的浮点精度要求不是很严格，而OpenGL ES则更不严格。 所以如果浮点精度对你的计算很重要，OpenGL将不是计算你需要计算的最有效的方法。
另外，OpenGL计算着色器需要支持4.x的硬件，而OpenCL可以在更差的硬件上运行。
而且，如果您通过增加渲染pipe线进行计算，则OpenGL驱动程序仍将假定您正在执行渲染。 所以它会根据这个假设做出优化决定。 假设您正在绘制图片，它将优化着色器资源的分配。
例如，如果你正在渲染一个浮点帧缓冲区，驱动程序可能会决定给你一个R11_G11_B10帧缓冲区，因为它检测到你没有对alpha进行任何操作，并且你的algorithm可以容忍较低的精度。 但是，如果使用图像加载/存储而不是帧缓冲，则不太可能获得这种效果。
OpenCL不是一个graphicsAPI; 这是一个计算API。
而且，OpenCL只是让你访问更多的东西。 它使您可以访问对GL隐含的内存级别。 某些内存可以在线程之间共享，但GL中独立的着色器实例无法直接影响到另一个（图像加载/存储之外，但OpenCL在无法访问的硬件上运行）。
OpenGL隐藏了抽象背后的硬件。 OpenCL公开了你几乎到底发生了什么事情。
你可以使用OpenGL来进行任意的计算。 但是你不想 ; 而不是当一个完全可行的select。 在OpenGL中进行计算来维护graphicspipe道。
为任何非呈现计算操作selectOpenGL的唯一原因是支持无法运行OpenCL的硬件。 目前，这包括了很多移动硬件。
一个值得注意的特征是分散写入，另一个是缺less“Windows 7智能”。 如你所知，Windows 7会杀死显示驱动程序，如果OpenGL不能刷新2秒钟左右（不要在确切的时间让我失望，但我认为它是2秒）。 如果你有一个漫长的操作，这可能是烦人的。
而且，OpenCL显然可以使用比graphics卡更多种类的硬件，而且它没有一个具有“人为约束”的严格的面向graphics的pipe道。 运行几个并发的命令stream也更容易（微不足道）。
尽pipe目前OpenGL对graphics来说是更好的select，但这并不是永久性的。
OpenGL最终可以合并为OpenCL的扩展。 这两个平台大约有80％是相同的，但是具有不同的语法怪癖，对于大致相同的硬件组件，命名不同。 这意味着两种语言学习，两个API来弄清楚。 graphics驱动程序开发人员更喜欢合并，因为他们不再需要开发两个独立的平台。 这为驱动程序debugging留下了更多的时间和资源。 ;）
另一件需要考虑的事情是，OpenGL和OpenCL的起源是不同的：在早期的固定pipe道networking时代，OpenGL开始并获得了发展势头，随着技术的发展，OpenGL逐渐被追加并被弃用。 在某些方面，OpenCL是OpenGL的演进，OpenGL开始被用于数字处理，因为GPU允许的（无计划的）灵活性如此。 “graphics与计算”实际上更像是一个语义论证。 在这两种情况下，您总是试图将您的math运算映射到具有最高性能的硬件。 有部分GPU硬件，香草CL不会使用，但不会有一个单独的延伸这样做。
那么OpenGL如何在CL下工作呢？ 据推测，三angular形栅格化器可以作为一个特殊的CL任务进入队列。 特殊的GLSL函数可以在vanilla OpenCL中实现，然后在内核编译期间由驱动程序覆盖到硬件加速指令。 在OpenCL中编写着色器，在提供库扩展之前，听起来并不像一个痛苦的经历。
打电话给一个人比另一个人有更多的function没有多大意义，因为他们同样的function获得了80％，就在不同的术语下。 声称OpenCL对graphics不好，因为它是为计算而devise的，因为graphics处理就是计算。
另一个主要原因是OpenGL \ GLSL仅在graphics卡上受支持。 尽pipe多核使用从使用graphics硬件开始，但是还有许多硬件供应商在以计算为目标的多核硬件平台上工作。 例如见英特尔骑士angular。
使用OpenGL \ GLSL开发计算代码将阻止您使用任何不是graphics卡的硬件。
OpenCL（2.0版本）描述了异构计算环境，系统中的每个组件都可以产生和消费任务，由其他系统组件生成。 没有更多的CPU，GPU（等）的概念是更长的需要 – 你只是主机和设备（S）。
相反，OpenGL与CPU，即作为任务生产者和GPU的任务使用者有严格的分工。 这并不坏，因为较less的灵活性确保了更高的性能。 OpenGL只是更窄范围的工具。
就OpenGL 4.5而言，这些是OpenCL 2.0具有OpenGL 4.5所不具备的function（据我所知）（这不包括OpenGL OpenCL所没有的function）：
活动
更好的primefaces能
块
工作组函数：work_group_all和work_group_any work_group_broadcast：work_group_reduce work_group_inclusive / exclusive_scan
从内核入队的内核
指针（尽pipe如果你在GPU上执行这可能没有关系）
OpenGL没有的一些math函数（尽pipe你可以在OpenGL中自己构造它们）
共享虚拟内存
（更多）内核编译器选项
易于select特定的GPU（或其他）
没有GPU时可以运行在CPU上
更多的支持这些利基硬件平台（如FGPA）
在一些（所有？）平台上，您不需要窗口（及其上下文绑定）来进行计算。
OpenCL只允许对计算的精度进行更多的控制（包括通过这些编译器选项）。
上面的很多主要是为了更好的CPU – GPU交互：事件，共享虚拟内存，指针（尽pipe这些也可能有益于其他的东西）。
OpenGL已经获得了对客户端和服务器内存的不同区域进行分类的能力，因为这里已经有很多其他的post。 OpenGL现在有更好的内存屏障和primefaces支持，并允许你分配给GPU内的不同寄存器（OpenCL可以达到大致相同的程度）。 例如，您可以在OpenGL中使用本地计算组共享registry（使用类似于AMD GPU LDS（本地数据共享）（尽pipe此特定function仅适用于OpenGL计算着色器）。一些平台（比如开放源码的Linux驱动程序），OpenGL可以访问更多的固定function硬件（就像其他的答案一样）虽然有时固定function的硬件是可以避免的（例如Crytek使用“软件”深度缓冲区）固定function的硬件可以很好的pipe理内存（通常比不工作的GPU硬件公司可以做得更好），而且在大多数情况下，性能都非常优越，我必须承认OpenCL具有非常好的固定function纹理支持这是主要的OpenGL固定function区之一。
我认为最近OpenGL已经变得不那么抽象了，并且有人对OpenGL（由媒体OpenGL NG命名）进行了彻底的重新devise，从而消除了许多抽象和更多（例如更多的Mantletypes特征）。 你可能听说过。
我会争辩说，英特尔骑士angular是一个控制自己的x86 GPU。 我也认为OpenCL 2.0及其纹理函数（实际上是OpenCL的较小版本）可以用来达到与user2746401build议的性能相同的性能。
除了已经存在的答案，OpenCL / CUDA不仅更适合计算领域，而且也不会抽象掉底层硬件。 通过这种方式，您可以更直接地从共享内存或合并内存访问中获益，否则在着色器的实际执行过程中（如果需要，本身只不过是一个特殊的OpenCL / CUDA内核）。
尽pipe从这些事情中获利，您还需要更多地了解您的内核将运行的特定硬件，但不要尝试使用着色器（如果甚至完全可能）将这些事项考虑在内。
一旦你做了比简单的1级BLAS例程更复杂的事情，你一定会明白OpenCL / CUDA的灵活性和通用性。
OpenCL是为通用计算而devise的，而OpenGL是用于graphics的。 你可以做任何事情在GL（这是图灵完成），但然后你用钉子把手的螺丝刀驾驶作为一个锤子。
另外，OpenCL不仅可以运行在GPU上，还可以运行在CPU和各种专用加速器上。
