GPGPU

GPGPU（General-purpose computing on graphics processing units; GPUによる汎用計算）とは、GPUの演算資源を画像処理以外に応用する技術である。ビッグデータなどに対し大量の科学技術計算などを実行できるため、広く使われるようになったp=19。2022年、単一マシンとしては世界初のエクサスケールコンピュータとなった米HPEの「フロンティア」にもベクトル計算用にAMDのGPUが搭載されるなど、世界最速を競うスーパーコンピュータでの利用も一般的である。
GPGPUは、GPUが持つベクトル計算機としての特性を活かした汎用的なストリーム・プロセッシングの一形態である。GPUはコンピュータゲームで多用されるリアルタイム画像処理向けのデータ並列計算とパイプライン処理に特化した命令発行形態を持ち、またGPUとメインメモリ間の帯域幅は通例狭くEfn|処理を行うCPUと、データを置くメインメモリの間のバスの速度がコンピュータ全体の計算性能の上限を規定することをフォン・ノイマン・ボトルネックと言う。GPUとメインメモリについても同様のボトルネックが発生するため欠点として挙げている。、固定長レジスタしか扱えないつまり、固定長ベクトル命令しか扱えず、固定長レジスタの長さに一致しない端数のデータについて別途考慮が必要になるという問題が発生する。伝統的にスーパーコンピュータで多用されてきた専用設計のベクトルプロセッサであれば可変長ベクトル命令が扱え、端数のデータに対して別途考慮する必要がない上に効率よく計算が行えるため、GPUが採用する固定長レジスタは欠点となる。（後述）ものの、GPUと直結されるVRAM間には十分広い帯域幅を備えておりSIMDやSIMTによる並列計算も行える。
GPGPUは制約はあるもののHPCの分野で注目される応用技術である。伝統的に構築されてきた、カスタムCPUとして開発されるベクトルプロセッサを主体としたスーパーコンピュータと比較して、疎行列で計算効率が低下する疎行列にアクセスする際に行われる、巨大な配列データを大域的にインデックス参照で引いてくるランダムメモリアクセスを多用する操作は、一般的なスカラ型のCPUやGPGPUにとってはフォン・ノイマン・ボトルネックにより苦手な処理となる。、可変長ベクトル命令が扱えずレジスタ長で割り切れない要素を別途考慮する必要があるという欠点はあるものの、GPUを主体として計算機システムを構成する方がコストパフォーマンスが高くなることからHPC分野での導入が進んでいる。
しかし、GPU特有の制約は無くなりつつある。2023年現在ではプログラマブルシェーダーの発展によりCPUと同程度のプログラマビリティが実現されておりp=76、OpenCLなどを用いることでCPUとGPUでの相互で互換性を持ったプログラムを作成することも可能であることからp=213、前述のランダムメモリアクセスに弱い、可変長ベクトル命令が利用できないという、伝統的なベクトルプロセッサと比較した場合の原理的な欠点以外については改善されてきている。

**GPGPUブームまでの略史**
最初の試みから一般的に使えるAPIが完成するまでに10年の歳月を要した。

**1998年: SGIのグラフィックスワークステーションを用いた実験**
GPUという製品カテゴリが登場する前年でプログラマブルシェーダーも存在しない1998年に、Ian BuckEfn|2005年からNVIDIAに所属しており、CUDAを考案するなどGPGPUの第1人者として業界を牽引している。によりSGI O2 R5000とSGI Indigo2 R4400 Maximum IMPACTのグラフィックスアクセラレータで、OpenGLのフレームバッファを漸化式の各計算ステップ用に2枚用いた単純な流体計算の高速化が試みられ、実際に数倍程度は高速化された。この当時のSGIのグラフィックスワークステーションにはジオメトリエンジンが独立したLSIチップとして搭載されており、後のGPUの原型とも言える構成となっていた。しかし固定機能シェーダーしか存在しなかったため非常に簡単なモデルしか計算できず、実用には程遠かった。
固定機能シェーダーを用いて流体計算を高速化する方法はGPGPUの着想時に試みられたのみであり、今日的なGPGPUの観点からすると極めて特殊でイメージが付きづらいため、下記にその研究で実行されたコードの引用と各行の説明を示す。概要としてはOpenGLの標準機能の1つである2次元畳み込みフィルタを漸化式の各計算ステップにおける拡散の操作として転用することで、各領域の拡散の計算がハードウェアで並列化されるというアイデアとなっていた。下記のコードを見れば分かる通り、物理モデルを2次元畳み込みフィルタとして表現して標準機能に渡すことしかできず、今日的なGPGPUと比較すればブラックボックスな固定機能シェーダーに並列計算を任せるしかないため、全く自由が利かないことが分かる。またRGBの各色8bitを数値に割り当てるため、計算精度が重要な科学技術計算として8bitを超える精度で計算するためにはRGBの各色間での桁の繰り上がりなども実装する必要があったが、その際に大きなオーバーヘッドが生じて計算が非常に遅くなってしまうという問題があった。当時はIan Buck自身も、これらの実用に当たって許容できない制約を緩和するためには今後のグラフィックスハードウェアの進歩が必要であると述べている。
#define k .2 // 拡散係数の定義
/* 畳み込みフィルタの定義 */
float filter = {
0.0, k, 0.0,
k, 1-4*k, k,
0.0, k, 0.0
};
glConvolutionFilter2D(filter)  // 畳み込みフィルタを設定
glEnable(GL_CONVOLUTION)       // 畳み込みフィルタを有効化
glReadBuffer(GL_FRONT)         // 読み込み側のフレームバッファ（1ステップの畳み込み計算における現ステップ(例えばtと置く)の値を保存するバッファ）
glDrawBuffer(GL_BACK)          // 書き込み側のフレームバッファ（1ステップの畳み込み計算における次ステップ(例えばt+1と置く)の値を保存するバッファ）
... Draw any initial conditions ... // 任意の初期条件の描画
glRasterPos(1,1);  // ピクセル操作のラスター位置を(x,y)=(1,1)に設定
/* 畳み込み計算の繰り返し実行 */
while(1) {
glCopyPixels(0, 0, Width, Height, GL_COLOR);
glxSwapbuffers(dspy, wnd);
}

**1999年-2000年: GPUとプログラマブルシェーダーの登場**
続いて1999年のGeForce 256の発売によってジオメトリエンジンをグラフィックスアクセラレータに統合した「GPU」という製品カテゴリが登場し、2000年11月9日にはアセンブリ言語で128個の命令のみ記述可能な原始的なプログラマブルシェーダー（シェーダーモデル1.x）が登場した。2002年、GPUの固定機能シェーダーがプログラマブルシェーダーに置き換わったことでブレイクスルーが起きたと主張し、ムーアの法則を超える速度で進化するGPUのストリーム・プロセッサとしての未来を予感したIan Buckにより、再度GPUによるレイトレーシング計算の高速化についての論文が発表された。

**2002年: シェーダーモデル2.0への進化**
2002年12月20日のシェーダーモデル2.0の登場により、GPUのプログラマブルシェーダーで従来より遥かに長い命令長と浮動小数点演算が扱えるようになった直後の2003年頃からGPGPUが大々的に試みられ始め、2004年8月には世界初のGPGPU学会「GP2」（Workshop on General Purpose Computing on Graphics Processors）が開催された。しかし当時は画像処理専用に作られていたGPU特有の制約（演算精度の不足や仮想メモリが扱えないなど）についての酷評が相次いでいたdate=2023年6月21日 (水) 10:47 (UTC)。またGPUメーカーは画像を表示するためだけであれば実際にはときどき計算エラーが生じているような製品でも歩留まり向上のために出荷できたが、汎用の計算の用途にはエラーの起きないものを出荷前に検査して選別する必要が生じたdate=2023年6月21日 (水) 10:47 (UTC)。

**2007年: CUDAの提供開始**
その後、2005年にIan BuckらのチームがグラフィックスAPIを経由せずC言語ライクにGPGPUの処理を記述できるCUDAの開発に着手し、2006年11月8日にCUDAとSIMTを採用した初対応のGeForce 8 シリーズ（G8x）を発表し、2007年2月16日に最初のCUDA SDKのβ版をリリースし、2007年7月17日にCUDA 1.0を提供開始したことで、以降2008年頃からGPGPUが普及して行った。CUDAが有名になったことで、NVIDIAはGPGPUでトップランナーの地位を占めることになった。GPGPUは2012年からのディープラーニングブーム、2010年代からの仮想通貨ブームを下支えする存在となり、2020年代には新型コロナウイルスの蔓延などによる半導体供給不足もありブームのあまりの過熱ぶりにGPU製品の供給が不足する事態まで発生した。

**概要**
GPUは一般的に画像処理を専門とする演算装置であり、多くの場合、CPUと呼ばれる主演算装置の制御の下で用いられる動画信号生成専用の補助演算用ICである。動画像の実時間内での生成は高速な演算が要求されるが、その多くが定式化された単純な演算の繰り返しであるためハードウェア化に向いており、GPUを設計している数社からは、高速なメモリ・インタフェース機能と高い画像演算能力を備えたIC製品のシリーズがいくつもリリースされている。GPUは民生用に大量生産されているため、スーパーコンピュータに用いられるベクトル型のカスタムCPUからすれば非常に安価である。但し、GPGPUは完全なベクトル型として設計されていないx86等の一般的なCPUのSIMD命令と比較して高い並列度を誇りスループットが高いが、バスアクセスのためにレイテンシも大きくなることが欠点となる。従って、一定量のデータを常に流し込みながら計算させ続ける事が最も理想的な利用形態（ストリーム・プロセッシング）であり、逆にネットワークのパケット処理といった多数の小さいデータの各々に対して個別に処理を行う場合では効率は劇的に悪化する。
特に1990年代中盤以降は3D描画性能が劇的に向上し、それに伴いベクトル・行列演算を中心としたSIMD演算機の色彩が強くなってきた。2000年代に入ると、表現力の向上を求めて固定機能シェーダーからプログラマブルシェーダーへの移行が進み、演算の自由度・柔軟性（プログラマビリティ）が飛躍的に増した。そこでこれをグラフィックス・レンダリングのみならず、他の数値演算にも利用しようというのがGPGPUのコンセプトである。GPGPUのコンセプトは2000年代の実験期を経て、入力データをテクスチャデータに変換して画像用のシェーダーに処理させるという回りくどい工夫が必要ない汎用計算用の言語やコンピュートシェーダーが開発された後、2010年頃のビッグデータブームの波に乗り産業応用が開始され、2010年代半ばには一般化した。
上記の表は 1CPU, 1MIC, 1GPU に限定した表である。なおAMD Radeon R9 295X2やAMD FirePro S10000、NVIDIA GeForce GTX TITAN ZやNVIDIA Tesla K80のようなデュアルGPUソリューションは除外されている。
2015年現在、GPUの浮動小数点演算能力は単精度で8TFLOPSをオーバーした一方で、CPUはサーバー向けでも単精度は1TFLOPS台に留まっている。GPUは構成が単純であるためにCPUよりも集積化の点で有利であることから浮動小数点演算での効率がよく、またGPU専用にローカル接続されたメモリIC (VRAM) とのバンド幅を広く備えるために、CPUと比べて性能比で安価かつ成長の伸び率が高い。さらにCPUよりも電力あたりの理論演算性能（ワットパフォーマンス、Performance per Watt）が高いのもGPUの特徴である。またGPUの主な使途がゲーム（PCゲーム）と動画再生で、ゲームをしないユーザーにとって余り気味の資源ということもあって注目されている。
2015年現在におけるGPGPU対応のグラフィックスカード（グラフィックスチップ）単体製品すなわちディスクリートGPU (discrete GPU, dGPU) としては、NVIDIAのGeForceおよびQuadroシリーズや、AMDのRadeonおよびFireProシリーズなどが代表として挙げられる（ただし後述するGPGPU対応APIをサポートするのはDirectX 10世代以降の製品となる）。CPU統合型GPU (integrated GPU, iGPU) に関しては、NVIDIAのTegraシリーズ、AMDのAPUシリーズ、そしてインテルのHD GraphicsシリーズなどがGPGPUに対応している。一方、GPGPU専用製品としては、NVIDIAのTeslaシリーズ、そしてAMDのFirePro Sシリーズ（旧FireStreamシリーズ）が挙げられ、こちらは科学技術分野のHPC市場向けにも投入されるなど、従来のベクトル計算機からの置き換えを視野に置いた製品展開が行なわれている。
GPGPUアプリケーション開発の環境およびAPIとしては、ハードウェア内部構造自体が汎用性を増したDirectX 10世代の統合型シェーダーアーキテクチャGPUの登場以降、NVIDIAによるGPGPU専用の統合開発環境「CUDA」や、AMDによるGPGPU基盤「AMD Stream」（旧称ATI Stream）、そしてクロノス・グループによる標準規格「OpenCL」が現われ、GPGPU活用の幅が広がりつつある。
なお、DirectX (Direct3D/HLSL) はバージョン11でGPUによる汎用演算用のステージであるコンピュートシェーダー（DirectCompute）を、またOpenGL/GLSLはバージョン4.3で同様のコンピュートシェーダーを導入するなど、グラフィックスAPIのほうにも従来のグラフィックスパイプラインに加えてGPGPU機能を活用するための変化が現れつつある。MetalやVulkanといった後発のローレベルグラフィックスAPIにも、コンピュートシェーダーが搭載されている。
その他、マイクロソフトの「C++ AMP」や、PGIの「OpenACC」など、DirectCompute/OpenCL/CUDAといったローレベルAPIをバックエンドとしながら、従来のC/C++やFortranにおけるOpenMPに近い高レベル並列プログラミング環境を提供するアクセラレータ系ライブラリ・言語拡張も出現している。

**特徴と課題**
GPUはメモリにシーケンシャルにアクセスし、かつ条件分岐の無い計算（演算密度の高い処理）に強い。そのような例に行列計算がある。苦手な物の代表として二分探索がある。二分探索は条件分岐だらけなうえ、メモリにランダムアクセスする。ポインタをたどる操作もメモリにランダムアクセスするため、連結リストや木構造なども苦手である。密行列は得意だが、疎行列は苦手で、東京大学情報基盤センターによると100倍遅い。グラフ計算においては、例えば最短経路問題では、完全グラフのような密グラフに対しては高速に計算できるが、頂点から数本しか辺が出ていないような疎グラフに対しては遅い。

**条件分岐**
GPUはシェーダープロセッサ（ストリームプロセッサ、ストリーミングプロセッサとも）と呼ばれる演算ユニットを多数持ち、複数のシェーダープロセッサをまとめてクラスタとしている。これらの演算器に命令を与えるインストラクション・ユニットはクラスタごとに1台しか無く、クラスタを構成するシェーダープロセッサはそれぞれ異なるデータを与えられ、そのデータに対して同じ命令内容を一度に実行する。このようなSIMD型データ処理は3次元演算やマルチメディア処理に効果を発揮する一方で、命令中に条件分岐による分岐が入るとオーバーヘッドがかさみ、途端に効率を落としてしまう。今日のCPUでは、このようなペナルティを最小限にするためにプリフェッチ／プリデコードや投機実行／レジスタ・リネーミングといった機能を備えているが、GPUでは備えていない（限定的な条件付きで投機的実行を行なえるものもある。GPUでの動的分岐はDirectX 9.0c世代以降でようやく現実的になった）。またPC向けのGPUではシェーダープロセッサごとに分岐するためのプログラムカウンターを持たないため、条件分岐の際は個別に異なる命令を発行するのではなく、実際に命令を実行するか否かを分けるためのマスクレジスタを使って分岐する手法が採用されている 。
また、シェーダープロセッサ間でデータをやりとりする場合、遠くのデータバスを経由することになり、それがボトルネックとなってしまう。この点に関しては、DirectX 10世代の統合型シェーダーアーキテクチャ以降のハードウェアに搭載されている、小容量だがプロセッサグループ内で共有することのできる高速なキャッシュメモリ（共有メモリ）を介することで、プロセッサグループ内でのデータ交換やメモリI/Oの効率を高めることができる 。
一般のアプリケーションで条件分岐が存在しないものは珍しく、こういった制約によってGPUはオフィススイートのようなアプリケーションの実行には不向きである。GPGPUの発展にはいかに効率を落とさず条件分岐を行なうかというのが1つの課題となっている。原理的にはシンプルなアルゴリズム構造を持ったプログラムによって、並列データ処理に最適化することがGPGPUの特長を最大限引き出すことにつながるといえる。

**浮動小数点演算**

**単精度と倍精度**
単精度浮動小数点演算に関してはCPUをはるかに上回る理論演算性能とスケーラビリティを持つGPUだが、倍精度浮動小数点演算に関しては様相が異なる。もともとGPUが扱う多くの画像演算（特にリアルタイム3Dグラフィックス）では、整数演算や単精度の浮動小数点演算で足りてしまうために浮動小数点演算器は仮数部が24ビット程度とそれほど広くなく、単精度の演算器で倍精度の浮動小数点演算を行なうには、分割して幾度も演算器を使う必要があり、性能を大きく落とす要因となる。なお倍精度対応が必須とされる科学技術計算分野を含めたHPC向けに設計された製品では、倍精度専用の演算器を搭載・有効化しているものもある。
AMDは2006年に自社のGPU「R580」をベースとした、単精度浮動小数点演算対応のストリームプロセッシング向け製品「AMD Stream Processor」（第1世代FireStream）を発表、続いて2007年にR6xxコアを使用した業界初の倍精度浮動小数点演算対応HPC向けGPUである「FireStream 9170」（第2世代FireStream）を発売した（ただし倍精度の理論演算性能は単精度の場合の1/5となる）。また2008年に発売されたRADEON HD 4850は1チップでは世界初の1TFLOPS（単精度）を達成し、このRADEON HD 4850にも使用されたR7xxコアを使用して低価格かつ高性能を売りに、HPC分野向けに第3世代FireStreamを発売することになった。2010年には、さらに高性能化した第4世代FireStreamを発売している。2014年に発売されたAMD FirePro S9100/S9150では倍精度演算性能が強化され、倍精度の理論演算性能は単精度の場合の1/2になっている 。
NVIDIAも、自社のGPU「Tesla (microarchitecture)」をベースとした、単精度浮動小数点演算対応のHPC向け製品「Tesla C870」を2007年に投入、さらに2008年に発売されたNVIDIA Tesla C1060で倍精度に対応したが、単精度933GFLOPSに比べて倍精度は1/12の78GFLOPSとなっており、倍精度演算性能が極端に低かった。2010年に発売されたFermi (microarchitecture)世代のTesla 20シリーズ では倍精度演算性能が強化され、倍精度の理論演算性能は単精度の場合の1/2になったが、2012年に発売されたKepler (microarchitecture)世代のTesla K20シリーズ 、2013年に発表されたK40、2014年に発表されたK80 では倍精度の理論演算性能は単精度の場合の1/3となっている。
2020年現在でも、GPUにおける倍精度演算に関してはHPC向けを除き、省電力性能やゲーミング性能を重視・維持するために必要最低限の性能しか用意されないことが多い。また倍精度専用の演算ユニットでは単精度の演算を行なうことはできないため、単精度を優先するか、それとも倍精度を優先するかはチップ設計段階におけるトレードオフとなる。実際、NVIDIAのMaxwell (microarchitecture)アーキテクチャのGPUでは前世代に存在した倍精度演算器が省略され、単精度演算器を使って倍精度演算を行なうため、倍精度演算のピーク性能は単精度演算の1/32となる。このため、HPC向け以外のGPUは倍精度の浮動小数点演算が不得意であると言える。

**半精度**
深層学習の計算においては計算精度が求められないことから、半精度（16ビット）の演算を高速で行えるようにハードウェア側の対応も進みつつあるp=148,150。深層学習においては仮数部の細かさよりも値がオーバーフローしないほうが使いやすいというメリットのため、指数部を増やしたBF16(bfloat16 floating-point format)と呼ばれるフォーマットが考案され、一部のGPUEfn|NVIDIA Ampere A100などでサポートされているp=304。
GPUから派生した分野特化型のプロセッサとして、ディープラーニングなどのAI計算能力に対して既存のGPUでは消費電力の大きさが問題になることから、計算精度を8ビットに抑えて、積和演算に特化したTPU（テンソル・プロセッシング・ユニット）というプロセッサが実現されており、人工知能のアクセラレーターとして活用されているp=306。バッテリー駆動が基本となるスマートフォンのSoCにも電力効率向上の必要性からAIアクセラレータが搭載されている。

**IEEE 754サポートおよびFMA命令**
DirectX 11対応となるEvergreen世代以降のAMD GPU、およびFermi世代以降のNVIDIA GPUでは、浮動小数点の演算精度はIEEE 754規格に準拠したものとなっている。なおNVIDIA GPUおよびAMD GPUでは融合積和演算命令 (FMA) をサポートしているが、CPUで同じ内容の処理をFMAを使わず実行した場合と比べて、GPUによる演算結果が異なることもある    。

**メモリ**
メモリ環境についても、演算入力はdate=2015年3月、演算出力は画像1枚程度の大きさのピクセルごとにdate=2015年2月のデータを保持しながら順次それらを送り出すだけで済むため、date=2015年3月外部の半導体メモリ（グラフィックスメモリ／ビデオメモリ／デバイスメモリ／VRAM）とdate=2015年3月メモリバンド幅による接続で十分に対応しており、演算対象データの局所性が高いのでグラフィックスメモリと内部キャッシュによってデータの読み書き性能が向上すると同時に演算も途切れずに順次行える傾向が強い。
基本的にGPUは、配列構造の単純なデータを半精度／単精度程度の浮動小数点演算によって順番に処理することで2次元の動画像データを実時間内に生成することに特化しているため、それ以外の用途ではあまり高い性能は期待できない。リアルタイム画像処理専用ICの流用では、科学技術計算でも倍精度以上の浮動小数点演算（拡張倍精度・四倍精度など）を必要とするものや、演算の局所性が低いものではそれほど高い性能は得られない。リアルタイム画像処理専用ではなく、GPUから派生して新たに開発されたGPGPU用のICでは、倍精度浮動小数点演算やより広いメモリ空間に対応したものがあり、これらは広範な科学技術計算への利用が期待される。なお、コンシューマー向けの画像処理分野ではほとんど必要とされないメモリの冗長機構であるECCがHPC分野では必須とされるため、ICを共用する場合に制約となる。

**共有メモリ**
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に対して同一の命令を発行していき、各々のハードウェアスレッドに割り当てられたデータに対して並列的に演算を行なうスタイルとなる。またWarp単位内における各スレッドはすべて同一の命令を実行する（SIMT）。基本概念としてはAMDのVLIWやGraphics Core NextといったGPUアーキテクチャにおいても同様である。
しかし、このGPGPUプログラミングが特に従来型のCPUプログラミングと異なる点は、共有メモリ（shared memory、シェアードメモリ）の存在である。共有メモリは小容量だが高速で、ユーザープログラマーが明示的に管理できるキャッシュメモリ（≒L1キャッシュ）の仕組みを果たし、複数のコアでデータを共有・交換する目的に使用できる。なお各APIにおいては、CUDAは共有メモリ、OpenCLはローカルメモリ、DirectComputeはグループ共有メモリ、そしてC++ AMPはタイル静的メモリという名称で、それぞれ同等機能を備えている。
例えばFermi/Keplerマイクロアーキテクチャでは、1SMXあたり最大Nowrap|48 KBの共有メモリを使用できるが、外部にあるDRAMにキャッシュなしでアクセスする場合と比べて、共有メモリのレイテンシは（スレッド間のバンクコンフリクトがないかぎり）100倍小さくなる。そのため、複数のスレッドから参照されるデータの一時書き込み場所として共有メモリを活用することにより、高速な並列アルゴリズム（たとえば高速に総和を求める並列リダクションなど）や、GPUプログラミングにおける高速化に必要なコアレスアクセス（≒シーケンシャルアクセス）を実現することができるとNVIDIAは説明している。しかしながら、最大でも48 KBしかない共有メモリというハードウェア制約がアルゴリズムの幅に制限をかけるため、共有メモリの存在はGPUプログラミングの難しさにもつながってしまう。また、共有メモリに読み書きする際、スレッド間の同期をとるための処理もプログラマーが明示的に記述する必要がある。
なお、インテルCPUのL2キャッシュメモリはL1キャッシュメモリに比べて容量が大きく、またプロセッサコア側に直結されているが、NVIDIA GPUのL2キャッシュメモリはL1キャッシュメモリに比べて容量がほとんど変わらず、またメモリ側に直結されているなど、データアクセス傾向の違いがハードウェア設計思想の違いにも反映されており、単純にキャッシュメモリの容量だけを比較して性能の優劣を決めることはできない  。

**接続バスの速度**
コンピュータのマザーボードとdGPUを接続するPCI Express規格は、CPU-システムメモリ間やGPU-ビデオメモリ間と比べてはるかに帯域幅が狭く、安易にGPGPUを導入しようとするとデータ転送がボトルネックとなって逆に性能の低下を招いてしまう可能性もありうる。この点に関しては、NVIDIAが開発した独自のインターコネクト技術であるNVLink などの解決策が模索されている。

**開発およびチューニングの難しさと移植性**
2015年現在、GPGPU対応プログラムの開発環境・APIとして代表的なものはCUDA、OpenCL、およびDirectComputeであり、GPGPU黎明期の開発環境に比べればはるかに開発しやすくなっているものの、依然としてアクセラレーターとなるハードウェアを意識したGPGPU特有のプログラミング知識が不可欠である。また、規格によってある程度標準化・抽象化されているとはいえ、いずれもデバイスとの通信を行なうローレベルのAPIを使いこなさなければならないなど、通常のC/C++やFortranを用いたソフトウェア開発とは次元の異なる難しさがあり、導入のハードルが高い。特にOpenCLとDirectComputeはハードウェアに共通にアクセスできるAPIを規定しているだけであり、CUDAよりもさらにローレベルの抽象度である。この点に関しては、アクセラレーターの存在を抽象化し、従来のCPUベース並列プログラミング用の共通規格OpenMPに近い高レベルプログラミング環境を提供するOpenACCやC++ AMPといった規格も徐々に整備されつつある。
CPU上で動作するプログラムは組み込み環境を除き、ライブラリも含めて高レベルに洗練された開発環境が整っていることが多い。例えばC++、Java、C#言語などの代表的な高級言語では、単純な連続メモリの配列構造だけでなく、リンクリスト・二分探索木・ハッシュテーブルといった基本的なデータ構造はプログラミング言語標準ライブラリで提供されていることがほとんどだが、GPUプログラミングの場合はdate=2015年3月基本的には配列構造しか用意されていない。フォトンマッピング手法の開発者であるWann Jensen博士によると、複雑なデータ構造をGPU上で扱おうとするとCPUよりもはるかに困難となる場合が多いと評されている。他にも、GPUプログラミング言語であるHLSL、GLSL、およびOpenCL CではC++テンプレートのようなジェネリックプログラミング機能がサポートされないため、生産性が低い。なおBLASやFFTに関しては、NVIDIAによるCUDA実装のcuBLASやcuFFT、およびAMDによるOpenCL実装のclMath (clBLAS, clFFT) が存在する。そのほか、二分探索、ソート、リダクション、スキャンといったよく使われるアルゴリズムに関しては、NVIDIAによるCUDA実装のC++テンプレートベース並列アルゴリズムライブラリThrustや、AMDによるOpenCL/C++ AMP実装の同等ライブラリBoltが存在するが、両者に互換性はない。
また、GPUで演算した結果をCPUで読み出して利用する場合、従来アーキテクチャではGPUメモリからCPUメモリへのデータ転送が必要となる。その逆もまた然りである。こうしたCPU-GPU間のメモリ転送にかかる処理時間およびプログラミング上の手間が、性能のボトルネックやソフトウェア開発の難しさにつながるという問題も抱えている。これは物理的にメモリが分離されている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だけでなく対応するあらゆるハードウェア・あらゆるプラットフォームへ展開できる高い移植性を持っているが、性能に関するポータビリティは必ずしも確保・保証されず、場合によってはデバイスやチップごとにコードをチューニングする必要がある。

**適合分野**
GPGPUで性能が向上するアプリケーションの例として、下記が挙げられる。- 数値計算
** シミュレーション
*** 分子動力学法、格子ボルツマン法
*** 物理シミュレーション
*** 流体計算・気候シミュレーション
*** 天体シミュレーション- 暗号解読
** 暗号通貨の採掘- 音声処理- CT再構築- データベース処理- 市況分析- 機械学習（ニューラルネットワークなど行列計算によるもの）
** ディープラーニング- 最適化問題（DRAMにコアレスアクセスするもの）- グラフィックス用途での汎用計算
実際の演算内容としては、行列演算、配列のリダクション、およびフーリエ変換などが挙げられる。
変わった例ではカスペルスキー・ラボがdate=2015年3月Radeon HD 2900で行っている実証試験として、GPUのパワーを使ってセキュリティソフトによる大まかなセキュリティチェックを行う機能を開発している。これによりCPUへの負担を減らすことができるとしている。
一方で、大量の条件分岐が伴う創薬研究や遺伝子解析のような用途にはスカラー計算機が適しており、ベクトル計算機やGPGPUベースの計算機には向かないとされている。

**実用ソフトウェアの登場**
GPGPU技術の話題は、コンピュータ（特に資源やスペースの制約が強いパーソナルコンピュータ）の進化において2000年代中盤までのトレンドであり課題であった。しかし、デモンストレーションばかりが先行し、実際に活用できるソフトウェアが発売されることはなかった。そもそも、CUDAやOpenCLなどの汎用APIや、それらに対応するDirectX 10世代の統合型シェーダーアーキテクチャGPUが出現するまでは、GPGPU開発環境は制約の強いリアルタイムグラフィックス向けのAPIやシェーディング言語を直接利用したものか、もしくは研究機関が独自開発した固有のプログラミング言語基盤であり、ハードルも高く、決して開発効率や再利用性が良いとは言えなかった 。
2008年秋から、S3がGPUを利用したGPGPU用写真修正ソフトウェア「S3FotoPro」を発表、また動画編集加工ソフトでは動画エンコードソフトの代表格であるTMPGEncがCUDAに対応したことを皮切りに、サイバーリンクのPowerDirector 7がCUDAとATI Streamに対応した。さらに、2009年にはSuper LoiLoScope (Pixel Shader 2.0を活用) が発売、サイバーリンクがMediaShow Espresso (CUDAとATI Streamに対応) を発売している。GPGPUを利用した無料で利用可能な動画エンコードソフトとして、AMDのATI AVIVO (完全無料) やNvidiaのBadaboom (30日間無料体験版) 、MediacoderのCUDAエンコーダが挙げられる。
米アドビはCreative Suite 4 (CS4) の一部製品においてCUDAベースのGPUアクセラレーションをサポートしていたが、2010年5月28日に発売したCreative Suite 5 (CS5) においてdate=2015年3月。CS5はOpenCLベースで開発されており、date=2015年2月GPGPUによる演算を行うことができる。本来GPUは画像処理を得意とするため、画像処理を主体とする同社のアプリケーションへの適性は高い。また、After Effects CCでは、レイトレーシングエンジンにOptiXを採用している。その他にも、V-Rayなど、レイトレーシングのアクセラレータとしてGPUを活用しているレンダラーが存在する。AMDもOpenCLベースのレイトレーシングエンジンとして、Radeon ProRender (旧称AMD FireRender) を開発・公開している  。
オープンソースの統合型3DCG作成ソフトウェアBlenderでは、GIレンダリングエンジンであるCyclesにおいてNVIDIA CUDAによるGPUレンダリングが可能となっている。なお、バージョン2.6時点ではOpenCLによるGPUレンダリングも試験的に実装が進められている。また、Autodesk 3ds Maxサブスクリプションなどに搭載されている物理ベースのGIレンダリングエンジンであるNVIDIA Irayでは、CUDAベースのGPUアクセラレーションが行なわれる  。
その他、ビットコインをはじめとした暗号通貨の採掘処理にもGPUが使われている。
このように、学術・研究目的や産業用途以外にも、一般的なプロダクション向け・コンシューマー向けに関してもGPGPU技術を利用したソフトウェアが登場しており、GPGPUを一般の利用者が活用できる環境が整ってきたといえる。しかし、万能に処理をこなすCPUと比較して、GPUはピーキーな特性を持ち、ソフトウェア開発においてはパイプライン処理や並列計算等の知識だけでなく、ハードウェア仕様およびAPIの知識も必要になるため、未だにGPGPU活用のノウハウが一般化したとは言い難いという面もある。しかし、そうした特別な専門知識を要求される実装についてはライブラリ、フレームワーク、処理連携先となるソフトウェアの背後に隠蔽するなどして、一般的なアプリケーションを開発するソフトウェア技術者が内部の詳細を意識することなくGPGPUによる高速化を利用できるような配慮も行われている。

**脚注**

**注釈**

**出典**

**参考文献**

**関連項目**
 代表的なGPGPU対応ハードウェア
** NVIDIA GeForce
** NVIDIA Quadro
** NVIDIA Tesla
** NVIDIA Tegra
** AMD Radeon
** AMD FirePro
** AMD FireStream
** AMD APU
** Intel HD Graphics- GPGPU基盤・プログラミング言語・APIなど
** CUDA
** AMD Stream (ATI Stream)
** OpenCL
** DirectCompute
** HLSL
** GLSL
** C++ AMP
** OpenACC- 採用事例
** Folding@home - GPGPUを利用した分散コンピューティングプロジェクト
** BOINC - 地球外知的生命体探査 (SETI@home) やGPUGRIDなどのプロジェクトがGPU (CUDA) に対応- その他
** 濱田剛