GPGPU
これは物理的にメモリが分離されているdGPUとCPUによる構成だけでなく、従来型のオンボードグラフィックスやCPU内蔵GPUといった、物理メモリを共有する構成においても同様である。CUDAやOpenCLにはソフトウェア(ドライバー)レベルでこの転送の手間を解決する仕組みとして統合メモリ (unified memory) 機能や共有仮想メモリ (shared virtual memory) 機能が用意されてはいるが、あくまでメモリ空間のアドレッシングを仮想化して転送処理を自動化するだけの仕組みであり、アプリケーションプログラマーが明示的に転送処理を記述してチューニング・最適化する場合と比べてパフォーマンス上の問題もある。この点に関しては、AMDが推進しているHSA (Heterogeneous System Architecture) におけるhUMA (heterogeneous Uniform Memory Access) といった解決策が模索されている。
GPGPUプログラムの移植性に関しては、CUDAはNVIDIAハードウェア専用であり、また DirectCompute (DirectX) はMicrosoftプラットフォーム(Microsoft Windows、Xbox Oneなど)専用という制約がある。一方でOpenCLは、GPUだけでなく対応するあらゆるハードウェア・あらゆるプラットフォームへ展開できる高い移植性を持っているが、性能に関するポータビリティは必ずしも確保・保証されず、場合によってはデバイスやチップごとにコードをチューニングする必要がある。
GPUによるVRAMへのアクセスは、複数のプロセッサ群によって並列的に発生するため、連続したメモリ領域に対するコアレスアクセス(coalesce access、≒シーケンシャルアクセス)を行なうことで効率化・高速化できる。NVIDIA GPUでは32のハードウェアスレッドを束ねるバッチ単位をWarpと呼び、AMD GPUでは64のハードウェアスレッドを束ねるバッチ単位をWavefrontと呼んでいるが、これらのユニット内ではプロセッサが完全に同期して動作するため、バッチ単位ごとにまとめて連続領域にアクセス(コアレスアクセス)することで効率が良くなる。逆に言えば、バッチ単位内のスレッドがそれぞれ遠く離れたばらばらのアドレスにアクセスするような非コアレスアクセス(≒ランダムアクセス)は効率が悪くなる。
GPGPUの本質は、大量の演算器によって実現されるハードウェアマルチスレッド集合を用いたデータ並列演算により性能を稼ぐ点にある。例えばNVIDIA GPUのFermi/Keplerマイクロアーキテクチャでは、演算器の最小単位をCUDAコア (SP, streaming processor) と呼び、また複数のCUDAコアを束ねる単位をSMX (SM, streaming multiprocessor) と呼んでいるが、GPUでの演算は、複数のSMXに対して同一の命令を発行していき、各々のハードウェアスレッドに割り当てられたデータに対して並列的に演算を行なうスタイルとなる。
概要としてはOpenGLの標準機能の1つである2次元畳み込みフィルタを漸化式の各計算ステップにおける拡散の操作として転用することで、各領域の拡散の計算がハードウェアで並列化されるというアイデアとなっていた。下記のコードを見れば分かる通り、物理モデルを2次元畳み込みフィルタとして表現して標準機能に渡すことしかできず、今日的なGPGPUと比較すればブラックボックスな固定機能シェーダーに並列計算を任せるしかないため、全く自由が利かないことが分かる。またRGBの各色8bitを数値に割り当てるため、計算精度が重要な科学技術計算として8bitを超える精度で計算するためにはRGBの各色間での桁の繰り上がりなども実装する必要があったが、その際に大きなオーバーヘッドが生じて計算が非常に遅くなってしまうという問題があった。当時はIan Buck自身も、これらの実用に当たって許容できない制約を緩和するためには今後のグラフィックスハードウェアの進歩が必要であると述べている。