OpenMP 和 OpenCL 是不同的，但可以一起工作。他们都不应该“破坏”另一个。
为了争论，我们假设在最小化现有代码库的更改与性能或计算能力之间进行权衡。OMP 是“简单”的，因为您可以通过一两个快速编译指示“神奇地”将其应用于令人尴尬的并行问题。
OpenCL 引入了超越典型操作系统线程模型的全新高级概念。Khronos 可能不想大声说出来，但它的起源是在 NVIDIA 的 CUDA 中。如果您想看看它是如何工作的，请下载 CUDA SDK 并开始玩。如果您没有任何 NVIDIA GPU，请不要担心，有一个 GPU 仿真器软件选项。OpenCL 是一种方便的 GPU 抽象，应该适用于 CPU、DSP、“加速器”（Khronos 对 IBM 的 CellBE 和可能是英特尔的 Larrabee 的昵称）。
OpenCL 不应该是“直接用 C99 编写的”。它被称为 C99 扩展，因为它的语法与 C99 相似/相同，但有一些新的关键字。您不能从内核调用 libc（或任何其他库）。
您可以同时使用两者，但从理论上讲，如果您愿意移植代码，OpenCL 应该“更好”（因为它可以移植到更多的计算设备上）。您不能在 OpenCL 内核中使用 OpenMP 编译指示。
也可以看看：
大多数情况下，OpenMP 和 OpenCL 是相互独立的。它们都是让开发人员在其平台上访问并行性的两种方式。
OpenMP 旨在与多个（相同的）处理器一起工作，其中大致相等的工作可以（几乎）在它们之间自动分流。
OpenCL 是一个有点不同的野兽，因为它在使用特殊的协处理器硬件时非常出色。它将允许您将一些繁重的数字运算卸载到 GPU 或其他一些协处理器，例如 Cell 中的协处理器。然而，它的构建也是基于它可以用于利用其他主处理器的想法，这在多核计算机中很常见。我认为这个特性是次要的，如果这就是你打算使用 OpenCL 的全部，我不建议使用 OpenCL。
话虽如此，我想这会有些挑战，但让 OpenMP 和 OpenCL 在同一个问题上协同工作绝对不是不可能的。
首先要考虑的是您为 OpenCL 所做的工作。这肯定是您只希望 OpenCL 在 GPU/协处理器上运行......而不是在其他主处理器/内核上运行的情况，因为 OpenMP 已经在使用它们。在同一主处理器上运行 OpenCL 和 OpenMP 不会（不应该）导致应用程序错误，但会导致不希望的调度，其中 OpenMP 和 OpenCL 运行速度较慢，因为它们花费大量时间切换回来和第四个彼此之间。如果您同时在同一核心上运行任何其他需要大量处理器的进程，也会发生这种情况。
要考虑的另一件大事是您将如何安排在协处理器上运行的任务。确实，您可以将大量工作投入到现代 GPU 中，但在管道和内存使用方面需要考虑很多事情。您不希望发生的是有 8 个不同的 OpenMP 线程，每个线程都试图同时将自己的工作发送到协处理器。我建议只使用一个线程来管理与协处理器的所有交互，因此它可以确保以有效的方式为其提供工作。
也就是说，我确信有些程序会同时发生多种类型的任务，其中一种类型的任务总是可以外包给协处理器，而另一种类型的任务可以由多核处理主处理器。这将是混合 OpenMP 和 OpenCL 的一个很好的例子。
祝你好运！
By the way, there is a work about openMp to gpgpu using CUDA.