まず、OpenCL は CPU と GPU で動作するように構築されています。どちらのタイプのデバイスでも、同じソース コードをコンパイルして実行できます。ただし、CPU コードが GPU に対して最適ではない可能性が非常に高く、その逆も同様です。
AMD H/W は、x86/x64 CPU の合計の 7% - 14% です。そのため、AMD は AMD と Intel の両方のチップに対応するコンパイラを開発する必要があります。AMD には、両方のチップ セット用のコンパイラを開発してきた歴史があります。逆に、Intel は、AMD チップで動作しない、またはそれほどうまく動作しないコンパイラを開発しました。それは驚くべきことではありません。
OpenCL を使用すると、AMD APP SDK が最も柔軟になり、AMD および Intel CPU と AMD GPU でうまく動作します。Intel の OpenCL SDK は、AMD x86 H/W にもインストールできません。
OpenCL プログラムをバイナリにコンパイルすると、それを作成した OpenCL プラットフォームおよびデバイスと一致する限り、保存して再利用できます。そのため、あるデバイス用にコンパイルして別のデバイスで使用すると、エラーが発生する可能性が非常に高くなります。
要するに、AMD SDK には、OpenCL 用に x86 CPU をターゲットにするためのコンパイラが含まれているということです。つまり、Intel CPU を実行している場合でも、生成されたコードはその上で実行されます。これは、C プログラムを x86 CPU で実行するようにコンパイルするのと同じ概念です。Intel および AMD CPU (または x86 命令セットを実装するもの) で動作します。
ベンダーのコンパイラには、user827992 の言及のように特定の最適化が含まれている可能性がありますが、私の経験では、AMD の CPU コンパイラのパフォーマンスは、Intel CPU で実行するとそれほど悪くはありません。Intel の OpenCL 実装は試していません。
一部の (おそらく将来のほとんどの) ハードウェアでは、ベンダーのコンパイラのみがそれをサポートすることは事実です。AMD の SDK は、NVIDIA カードで実行されるコードをビルドしません。CPU は、基本的な命令セットが非常に広く展開されているため、接触する可能性が高いほとんどのマシンで CPU コンパイラが動作するという点で、少し特殊なケースです。
OpenCL の能力は、基盤となるハードウェアを抽象化し、大規模で並列かつ異種のコンピューティング能力を提供することです。
一部の SDK とプラットフォームは、コードを「最適化」するための特定の機能を提供します。正直なところ、そのような機能は単なるマーケティングであり、ボイラープレート コードを導入してアプリケーションの移植性を低下させると思います。
また、OpenCL の単なるラッパーであるか、 Intel クイック シンクのような概念に非常に似ている疑似新しいテクノロジもいくつかあります。
Intel については、最初はすべての iCore 世代と一部の C2D をサポートしていたと言うべきです。現在、新しい SDK は第 3 世代の iCore 世代のみをサポートしています。正直なところ、Intel の戦略はわかりません。 OpenCL を採用し、可能な限り多くのユーザーをターゲットにしたいと考えていますが、SDK はまったく優れていないようです。
標準に固執することで、法的問題とパフォーマンスの問題の両方を回避でき、コードの移植性も向上します。