Loading article…
グラフィックス処理ユニットによる汎用コンピューティング（GPGPU、またはあまり一般的ではないがGPGP ）とは、通常はコンピュータグラフィックスの計算のみを処理するグラフィックス処理ユニット（GPU）を使用して、従来中央処理装置（CPU）が処理していたアプリケーションの計算を実行することである。[ 1 ] [ 2 ] [ 3 ] [ 4 ] 1台のコンピュータに複数のビデオカードを使用したり、多数のグラフィックスチップを使用したりすることで、グラフィックス処理の既に並列な性質がさらに並列化される。[ 5 ]
基本的に、GPGPUパイプラインとは、1つまたは複数のGPUとCPUの間で行われる並列処理の一種であり、画像やその他のグラフィックデータの処理に特化した高速化命令を備えています。GPUはCPUよりも低い周波数で動作しますが、処理要素の数は通常、CPUの何倍にもなります。そのため、GPUは従来のCPUよりもはるかに多くの画像やその他のグラフィックデータを1秒あたりに処理できます。データを並列形式に移行し、GPUを使用して処理することで、（理論的には）大幅な高速化を実現できます。
GPGPUパイプラインは、グラフィックス処理（例えば、より優れたシェーダーのため）のために21世紀初頭に開発されました。スーパーコンピューティングの歴史から、科学計算が史上最大の計算能力の集中を牽引してきたことはよく知られており、 TOP500にランクインしています。今日では、その大半がGPUを利用しています。
最もよく知られているGPGPUは、Nvidia DGXで使用されているNvidia Teslaであり、AMD InstinctやIntel Gaudiと並んで挙げられる。
原理的には、加算、乗算、その他の数学関数を含む任意のブール関数は、機能的に完全な論理演算子のセットから構築できます。1987年、コンウェイのライフゲームは、ビットベクトルに対して特別な論理演算シーケンスを呼び出すためにブリッターと呼ばれる初期のストリームプロセッサを使用した汎用コンピューティングの最初の例の1つになりました。[ 6 ]
GPU 上での汎用コンピューティングは、プログラマブルシェーダーとグラフィックスプロセッサでの浮動小数点サポートの両方の登場により、2001 年頃からより実用的かつ普及しました。特に、行列やベクトル、特に 2 次元、3 次元、または 4 次元ベクトルを含む問題は、これらの型に対してネイティブの速度とサポートで動作する GPU に簡単に変換できました。GPGPU の重要なマイルストーンは 2003 年に、2 つの研究グループが独立して、CPU よりも高速に実行される GPU 上での一般的な線形代数問題の解決のための GPU ベースのアプローチを発見したことです。[ 7 ] [ 8 ] GPU を汎用プロセッサとして使用するこれらの初期の取り組みでは、グラフィックスプロセッサの 2 つの主要な API、OpenGLとDirect3Dでサポートされているグラフィックスプリミティブの観点から計算問題を再定式化する必要がありました。この面倒な変換は、 Sh / RapidMind、Brook、Acceleratorなどの汎用プログラミング言語と API の登場により不要になりました。 [ 9 ] [ 10 ] [ 11 ]
これに続いて、Nvidia のCUDAが登場し、プログラマーは基盤となるグラフィックの概念を無視して、より一般的な高性能コンピューティングの概念を優先できるようになりました。[ 12 ]ハードウェアベンダーに依存しない新しい製品としては、Microsoft のDirectComputeや Apple/Khronos Group のOpenCL などがあります。[ 12 ] これは、最新の GPGPU パイプラインでは、データをグラフィック形式に完全に明示的に変換する必要なく、GPU の速度を活用できることを意味します。
GPGPU.orgの創設者であるマーク・ハリスは、GPGPUという用語を自分が考案したと主張している。[ 13 ]
CPU上で実行されるコードがGPUシェーダーから戻り値をポーリングできる言語であれば、どのような言語でもGPGPUフレームワークを作成できます。並列コンピューティングのプログラミング標準には、OpenCL（ベンダー非依存）、OpenACC、OpenMP、OpenHMPPなどがあります。
2016年現在OpenCLは、汎用GPUコンピューティング言語として最も広く普及しているオープンな言語であり、Khronos Groupによって定義されたオープンスタンダードです。OpenCLは、クロスプラットフォームのGPGPUプラットフォームを提供し、さらにCPU上でのデータ並列演算もサポートしています。OpenCLは、Intel、AMD、Nvidia、およびARMプラットフォームで積極的にサポートされています。Khronos Groupはまた、 OpenCLのより高レベルなプログラミングモデルであるSYCLを標準化し、実装しました。SYCLは、純粋なC++11に基づいた単一ソースのドメイン固有組み込み言語です。
主流の独自フレームワークはNvidia CUDAです。[ 14 ] Nvidiaは2006年にCUDAを発表しました。これは、プログラミング言語Cを使用してGeForce 8シリーズ以降のGPUで実行するアルゴリズムをコーディングできるソフトウェア開発キット（SDK）およびアプリケーションプログラミングインターフェース（API）です。
2016年に発表されたROCmは、AMDがCUDAに対抗するために開発したオープンソースの技術である。2022年現在、機能面ではCUDAと同等だが、消費者向けサポートはまだ不十分である。
OpenVIDIAは、2003年から2005年にかけてトロント大学でNvidiaとの共同開発により開発されました[ 15 ] 。
Altimesh Hybridizer はAltimeshによって作成され、共通中間言語をCUDA バイナリにコンパイルします。 [ 16 ] [ 17 ]ジェネリクスと仮想関数をサポートしています。[ 18 ]デバッグとプロファイリングはVisual Studioおよび Nsightと統合されています。[ 19 ] Visual Studio Marketplace で Visual Studio 拡張機能として入手できます。
マイクロソフトは、 Direct3D 11 APIとともにリリースされたDirectCompute GPUコンピューティングAPIを導入しました。
QuantAlea [ 21 ]によって作成されたAlea GPU [ 20 ]は、Microsoft .NET 言語のF# [ 22 ]およびC#。Alea GPU はまた、デリゲートと自動メモリ管理を使用した GPU 並列 for および並列集約に基づく簡素化された GPU プログラミング モデルを提供します。 [ 23 ]
MATLAB は、 Parallel Computing ToolboxおよびMATLAB Distributed Computing Server [ 24 ]やJacketなどのサードパーティ パッケージを使用して GPGPU アクセラレーションをサポートしています。
GPGPU処理は、物理エンジンによるニュートン力学のシミュレーションにも使用され、[ 25 ]商用実装にはHavok Physics、FX、PhysXなどがあり、これらは通常コンピュータゲームやビデオゲームで使用されています。
C++ Accelerated Massive Parallelism ( C++ AMP ) は、GPU のデータ並列ハードウェアを活用することでC++コードの実行を高速化するライブラリです。
モバイルGPUの性能向上傾向により、主要なモバイルオペレーティングシステムを搭載したモバイルデバイスでも汎用プログラミングが可能になった。
Google Android 4.2 では、モバイルデバイスの GPU 上でRenderScriptコードを実行できるようになりました。 [ 26 ] RenderScript はその後、最初の OpenGL コンピュート シェーダー[ 27 ]および後に Vulkan Compute [ 28 ] に置き換えられ、非推奨となりました。OpenCLは多くの Android デバイスで利用可能ですが、Android では公式にはサポートされていません。[ 29 ] Apple はiOSアプリケーション向けに独自のMetal APIを導入し、Apple の GPU コンピュート シェーダーを介して任意のコードを実行できるようにしました。
当初、データは中央処理装置(CPU)からグラフィックス処理装置(GPU) へ、そして表示装置へと一方的に渡されるだけだった。しかし、時が経つにつれ、GPU が、最初は単純な、次に複雑なデータ構造を保存し、それを画像を解析する CPU や、ビデオ カードが理解できる 2D または 3D 形式で表現された一連の科学データに渡すことが重要になった。GPU はすべての描画操作にアクセスできるため、これらの形式のデータを高速に解析できるが、CPU はすべてのピクセルまたはデータ要素をはるかにゆっくりとポーリングする必要がある。これは、CPU とより大きなランダム アクセス メモリ(さらに悪い場合はハード ドライブ) のプール間のアクセス速度が、通常、より高価なメモリを少量搭載し、アクセス速度がはるかに速い GPU やビデオ カードよりも遅いためである。アクティブに解析するデータセットの一部をテクスチャやその他の読みやすい GPU 形式の形式で GPU メモリに転送すると、速度が向上する。GPGPU 設計の特徴は、GPU から CPU へ双方向に情報を転送できることである。一般的に、双方向のデータスループットは理想的には高く、特定の高頻度アルゴリズムの速度に乗数効果をもたらします。
GPGPUパイプラインは、特に大規模なデータセットや2Dまたは3D画像を含むデータにおいて、効率を向上させる可能性があります。これは、複雑なグラフィックスパイプラインや科学計算で使用され、ゲノムマッピングのような大規模データセットを扱う分野や、2次元または3次元解析が有用な分野、特に生体分子解析、タンパク質研究、その他の複雑な有機化学分野でより多く利用されています。このようなアプリケーションの例としては、ゲノム解析用のNVIDIAソフトウェアスイートが挙げられます。
このようなパイプラインは、画像処理やコンピュータビジョンをはじめとする様々な分野、そして並列処理全般において、効率を大幅に向上させることができます。高度に最適化されたパイプラインの中には、高頻度タスクにおいて、元のCPUベースのパイプラインと比較して数百倍もの速度向上を実現したものもあります。
A simple example would be a GPU program that collects data about average lighting values as it renders some view from either a camera or a computer graphics program back to the main program on the CPU, so that the CPU can then make adjustments to the overall screen view. A more advanced example might use edge detection to return both numerical information and a processed image representing outlines to a computer vision program controlling, say, a mobile robot. Because the GPU has fast and local hardware access to every pixel or other picture element in an image, it can analyze and average it (for the first example) or apply a Sobel edge filter or other convolution filter (for the second) with much greater speed than a CPU, which typically must access slower random-access memory copies of the graphic in question.
GPGPU as a software concept is a type of algorithm, not a piece of equipment. Specialized equipment designs may, however, even further enhance the efficiency of GPGPU pipelines, which traditionally perform relatively few algorithms on very large amounts of data. Massively parallelized, gigantic-data-level tasks thus may be parallelized even further via specialized setups such as rack computing (many similar, highly tailored machines built into a rack), which adds a third layer – many computing units each using many CPUs to correspond to many GPUs. Some Bitcoin "miners" used such setups for high-quantity processing. Insights into the largest such systems in the world has been maintained at the TOP500 supercomputer list.
Historically, CPUs have used hardware-managed caches, but the earlier GPUs only provided software-managed local memories. However, as GPUs are being increasingly used for general-purpose applications, state-of-the-art GPUs are being designed with hardware-managed multi-level caches which have helped the GPUs to move towards mainstream computing. For example, GeForce 200 series GT200 architecture GPUs did not feature an L2 cache, the Fermi GPU has 768 KiB last-level cache, the Kepler GPU has 1.5 MiB last-level cache,[30] the Maxwell GPU has 2 MiB last-level cache, and the Pascal GPU has 4 MiB last-level cache.
GPU は非常に大きなレジスタ ファイルを持ち、これによりコンテキスト スイッチのレイテンシを削減できます。レジスタ ファイル サイズは、さまざまな GPU 世代にわたって増加しており、たとえば、Maxwell (GM200)、Pascal、Volta GPU のレジスタ ファイルの合計サイズは、それぞれ 6 MiB、14 MiB、20 MiB です。[ 31 ] [ 32 ]これに対し、 CPU のレジスタ ファイルのサイズは小さく、通常は数十キロバイトまたは数百キロバイトです。
要するに、ほとんどすべての GPU ワークロードは、タイル レンダリングのように、本質的に大規模並列 LOAD-COMPUTE-STORE の性質を持っています。メモリ ウォール問題のために、一時ベクトルを 1 つ保存して後で呼び出す (LOAD-COMPUTE-STORE-COMPUTE-LOAD-COMPUTE-STORE) ことさえも非常にコストがかかるため、あらゆる手段を講じて避ける必要があります。[ 33 ]その結果、レジスタ ファイル サイズが大きくなる必要があります。 標準的な CPU では、この問題を解決するためにキャッシュ( D キャッシュ)を導入できますが、これらは比較的大きいため、処理要素ごとに 1 つ必要となる GPU に導入するのは実用的ではありません。ILLIAC IV は、 1967 年頃に処理要素ごとにローカル メモリ (PEM) を導入することでこの問題を革新的に解決しました。この戦略はAspex ASPによって模倣されました。
GPGPUは、一連の操作を実行する「コア」の各グループに割り当てられる実行リソースの量において大きく異なり、Nvidiaでは「ストリーミングマルチプロセッサ」（SM）、AMDではマイクロアーキテクチャに応じてコンピュートユニット（CU）またはワークグループプロセッサ（WGP）、Intelでは「Xe Core」などと呼ばれ、いずれもOpenCLで「ワークグループ」と呼ばれるものを実行するように設計されています。[ 34 ] CPUが電力やチップ面積を節約するために、より広いベクトル命令をより小さな部分に実装することを選択するのと同様に（たとえば、AMD Bulldozerは256ビットAVX命令を2つの128ビット操作に分割してサポートしました）、[ 35 ] GPU設計者も想定されるワークロードに合わせて実行ユニットの数を変更します。
GPGPUでは、FP64 (FMA)、FP32 (FMA)、FP16 (FMA)、Int32 Add、Int32 Mul、RCP/RSQRTの各リソースの比率はそれぞれ自由に変化します。(Nvidiaのドキュメントには、異なる世代(計算能力)のGPUの各SMで見られる実行リソースの例があります。非行列FP16はFP32コアで処理されます。[ 36 ] ) 科学計算を目的としたGPGPUはFP64への投資が多い一方、ディープラーニング用に設計されたGPGPUはFP16、低ビット幅の「パック」整数演算、および追加の専用行列乗算ユニット(「行列ユニット」、「テンソルコア」)への投資が多い傾向があります。[ 37 ] [ 38 ]
したがって、GPUの演算能力を単にFLOPSで表すだけでは不十分です。FLOPS値は行列モードと非行列モードで別々に表示されるべきであり、整数演算についても(T)OPS値を表示する必要があります。
GPU の高性能は、高い消費電力という代償を伴い、フルロード時には実際には PC システム全体の消費電力に匹敵するほどの電力を消費します。[ 39 ] Pascal シリーズ GPU (Tesla P100) の最大消費電力は 250W と規定されていました。[ 40 ]
演算能力（FLOPS、TOPSなど）という点では、GPUは一般的なCPUよりもワットあたりの性能が高い傾向があります。しかし、この性能を最大限に引き出すには、適切に記述されたプログラムと適切なワークロードが必要です。そうでなければ、ほとんどの時間（と電力）はローカルメモリやホストメモリへのアクセスに費やされてしまうからです。
2007年にCUDAが公開される以前は、GPGPUは「従来型」であり、グラフィックスプリミティブの再利用を伴っていた。その標準的な構造は以下のとおりである。
GPU Gems 2のパート 4 にはさらに多くの例が掲載されています。[ 41 ]
数値線形代数にGPUを使用するようになったのは少なくとも2001年からである。[ 42 ]ガウス・ザイデルソルバー、共役勾配法などに使用されてきた。[ 43 ]
コンピューターのビデオカードは、 Nvidia、AMDなどの様々なベンダーによって製造されています。これらのベンダーのカードは、整数型や浮動小数点型（32ビットおよび64ビット）などのデータフォーマットのサポートの実装において異なります。Microsoftは、グラフィックカードの様々な機能をシンプルなシェーダーモデルバージョン番号（1.0、2.0、3.0など）でランク付けするために、シェーダーモデル規格を導入しました。
Direct3D 9以前のビデオカードは、パレットまたは整数型のカラータイプのみをサポートしていました。透明度を表すために、別のアルファ値が追加される場合もあります。一般的なフォーマットは次のとおりです。
初期の固定機能または限定的なプログラマビリティのグラフィックス（Direct3D 8.1準拠のGPUまで）では、ディスプレイでもこの表現が使われていたため、これで十分でした。ただし、この表現にはいくつかの制限があります。十分なグラフィックス処理能力があれば、グラフィックスプログラマーでさえ、高ダイナミックレンジイメージングなどの効果を得るために、浮動小数点データ形式などのより優れた形式を使いたがります。多くのGPGPUアプリケーションでは浮動小数点精度が必要であり、これはDirect3D 9仕様に準拠したビデオカードで実現されました。
Direct3D 9 シェーダー モデル 2.x では、完全精度と部分精度の 2 種類の精度をサポートすることが提案されました。完全精度は FP32 または FP24 (コンポーネントごとに 32 ビットまたは 24 ビットの浮動小数点) 以上で、部分精度は FP16 でした。ATIのRadeon R300シリーズ GPU は、プログラマブル フラグメント パイプラインでのみ FP24 精度をサポートしていました (頂点プロセッサでは FP32 がサポートされていました)。一方、NvidiaのNV30シリーズは FP16 と FP32 の両方をサポートしていました。S3 GraphicsやXGIなどの他のベンダーは、FP24 までのさまざまな形式をサポートしていました。
Nvidia GPU の浮動小数点の実装は、ほとんどがIEEEに準拠していますが、これはすべてのベンダーに当てはまるわけではありません。[ 44 ] これは、一部の科学アプリケーションで重要とされる正確性に影響を与えます。64 ビット浮動小数点値 (倍精度浮動小数点) は CPU では一般的に使用できますが、GPU では普遍的にサポートされているわけではありません。一部の GPU アーキテクチャは IEEE 準拠を犠牲にしており、他のアーキテクチャは倍精度をサポートしていません。GPU 上で倍精度浮動小数点値をエミュレートする試みが行われてきましたが、速度のトレードオフにより、そもそも計算を GPU にオフロードするメリットがなくなります。[ 45 ]
GPU のほとんどの演算はベクトル化されており、1 つの演算で最大 4 つの値を同時に処理できます。たとえば、ある色⟨ R1, G1, B1 ⟩を別の色⟨ R2, G2, B2 ⟩で変調する場合、GPU は 1 つの演算で結果の色⟨ R1*R2, G1*G2, B1*B2 ⟩を生成できます。この機能は、ほとんどすべての基本データ型がベクトル (2 次元、3 次元、または 4 次元) であるため、グラフィックスで役立ちます。例としては、頂点、色、法線ベクトル、テクスチャ座標などがあります。
GPUは元々グラフィックス専用に設計されているため、動作やプログラミングにおいて非常に制約が多い。その設計上、GPUはストリーム処理で解決できる問題にしか効果を発揮せず、ハードウェアも特定の用途にしか使用できない。
GPGPU黎明期において、GPUは独立した頂点とフラグメントのみを処理できますが、それらを並列処理することは可能です。これは、プログラマが多数の頂点やフラグメントを同じ方法で処理したい場合に特に効果的です。この意味で、GPUはストリームプロセッサ、つまりストリーム内の多数のレコードに対して1つのカーネルを同時に実行することで並列処理が可能なプロセッサと言えます。プログラマは、汎用的な計算を実行するためにグラフィックスAPI（ OpenGLまたはDirect3D ）を使用します。
CUDA（Nvidia、2007年）およびOpenCL （ベンダー非依存、2008年）という汎用コンピューティングAPIの導入により、新しいGPGPUコードでは、計算をグラフィックスプリミティブにマッピングする必要がなくなりました。GPUのストリーム処理特性は、使用するAPIに関係なく有効です。（例えば、[ 46 ]を参照）
ストリームとは、同様の計算を必要とするレコードの集合です。ストリームはデータ並列処理を提供します。 カーネルは、ストリーム内の各要素に適用される関数です。GPUでは、頂点とフラグメントがストリーム内の要素であり、頂点シェーダーとフラグメントシェーダーはそれらに対して実行されるカーネルです。各要素に対しては、入力から読み取り、操作を実行し、出力に書き込むことしかできません。複数の入力と複数の出力を持つことは可能ですが、読み取りと書き込みの両方が可能なメモリ領域は決して存在しません。
算術強度は、転送されたメモリワードあたりに実行される演算の数として定義されます。GPGPUアプリケーションでは、高い算術強度を持つことが重要です。そうでないと、メモリアクセス遅延が計算の高速化を制限します。[ 47 ]
理想的なGPGPUアプリケーションは、大規模なデータセット、高い並列性、およびデータ要素間の依存関係の最小化を備えている。
GPUには、さまざまな計算リソースが用意されています。
実際、プログラムはフレームバッファの代わりに書き込み専用テクスチャを出力として使用することができます。これは、レンダー・トゥ・テクスチャ（RTT）、レンダー・トゥ・バックバッファ・コピー・トゥ・テクスチャ（RTBCTT）、またはより新しいストリーム出力のいずれかによって実現されます。
GPGPUにおけるストリームの最も一般的な形式は2Dグリッドです。これは、GPUに組み込まれたレンダリングモデルに自然に適合するからです。行列演算、画像処理、物理ベースシミュレーションなど、多くの計算はグリッドに自然にマッピングされます。
テクスチャはメモリとして使用されるため、テクスチャ検索はメモリ読み出しとして機能します。 このため、GPUは一部の操作を自動的に実行できます。
計算カーネルはループの本体と考えることができます。例えば、CPU上のグリッド上で動作するプログラマーは、次のようなコードを書くかもしれません。
// 入力グリッドと出力グリッドは、10000 x 10000、つまり1億個の要素を持ちます。void transform_10k_by_10k_grid ( float in [ 10000 ][ 10000 ], float out [ 10000 ][ 10000 ]) { for ( int x = 0 ; x < 10000 ; x ++ ) { for ( int y = 0 ; y < 10000 ; y ++ ) { // 次の行は 1 億回実行されますout [ x ][ y ] = do_some_hard_work ( in [ x ][ y ]); } } }GPU上では、プログラマはループの本体をカーネルとして指定し、ジオメトリ処理を呼び出すことでループ処理するデータを指定するだけでよい。
このトピックに関する正確な技術情報については、Predication_(computer_architecture)#SIMD,_SIMT_and_vector_predicationおよび ILLIAC IV “branching”を参照してください（「述語マスク」という用語は 1967 年には存在しませんでした）。
シーケンシャルコードでは、if-then-else文やさまざまなループを使用してプログラムの流れを制御することが可能です。このようなフロー制御構造はGPUで利用できます。[ 48 ]条件付き書き込みは、適切に作成された一連の算術演算/ビット演算を使用して実行できますが、ループや条件分岐は不可能でした。
最近のGPUは分岐を可能にしますが、通常はパフォーマンスの低下を伴います。CPUコードでもGPUコードでも、内部ループでの分岐は一般的に避けるべきであり、ハードウェアサポートがない場合には、静的分岐解決、事前計算、述語化、ループ分割[ 49 ]、Z-cull [ 50 ]などのさまざまな方法を使用して分岐を実現できます。
マップ操作は、指定された関数（カーネル）をストリーム内のすべての要素に適用するだけのシンプルな操作です。簡単な例としては、ストリーム内の各値を定数倍する（画像の明るさを上げる）ことが挙げられます。マップ操作はGPU上で簡単に実装できます。プログラマは画面上の各ピクセルに対してフラグメントを生成し、それぞれのピクセルにフラグメントプログラムを適用します。同じサイズの結果ストリームが出力バッファに格納されます。
計算によっては、より大きなストリームからより小さなストリーム（場合によっては要素が1つだけのストリーム）を計算する必要がある場合があります。これはストリームの縮小と呼ばれます。一般的に、縮小は複数のステップで実行できます。前のステップの結果が現在のステップの入力として使用され、操作が適用される範囲が縮小されていき、最終的にストリーム要素が1つだけ残ります。
ストリームフィルタリングは、本質的には非均一な削減処理である。フィルタリングとは、何らかの基準に基づいてストリームから項目を削除する処理である。
スキャン操作は、並列プレフィックス和とも呼ばれ、データ要素のベクトル（ストリーム）と、単位元「i」を持つ（任意の）結合法二項関数「+」を入力として受け取ります。入力が [a0, a1, a2, a3, ...] の場合、排他的スキャンでは出力 [i, a0, a0 + a1, a0 + a1 + a2, ...] が生成され、包括的スキャンでは出力 [a0, a0 + a1, a0 + a1 + a2, a0 + a1 + a2 + a3, ...] が生成され、単位元が存在する必要はありません。一見するとこの操作は本質的に逐次的であるように見えますが、効率的な並列スキャンアルゴリズムが可能であり、グラフィックス処理ユニットに実装されています。スキャン操作は、例えばクイックソートや疎行列ベクトル乗算などに使用されます。[ 46 ] [ 51 ] [ 52 ] [ 53 ]
散布演算は、頂点プロセッサ上で最も自然に定義できます。頂点プロセッサは頂点の位置を調整できるため、プログラマはグリッド上のどこに情報が配置されるかを制御できます。また、頂点が影響を与える領域の大きさを制御するなど、他の拡張機能も可能です。
フラグメントプロセッサは、直接的なスキャッター操作を実行できません。なぜなら、グリッド上の各フラグメントの位置はフラグメント作成時に固定されており、プログラマが変更できないからです。ただし、論理的なスキャッター操作は、別のギャザーステップで再構成または実装される場合があります。スキャッターの実装では、まず出力値と出力アドレスの両方が出力されます。直後のギャザー操作では、アドレス比較を使用して、出力値が現在の出力スロットにマッピングされているかどうかを確認します。
専用の計算カーネルでは、インデックス付き書き込みによってスキャッター処理を実行できます。
ギャザーはスキャッターの逆操作です。スキャッターがマップに基づいて要素の順序を並べ替えた後、ギャザーはスキャッターで使用されたマップに基づいて要素の順序を復元します。専用の計算カーネルでは、ギャザーはインデックス付き読み取りによって実行される場合があります。その他のシェーダーでは、テクスチャルックアップによって実行されます。
ソート操作は、順序付けされていない要素の集合を順序付けされた要素の集合に変換します。GPU 上で最も一般的な実装は、整数および浮動小数点データには基数ソートを使用し、一般的な比較可能なデータには粗粒度マージソートと細粒度ソートネットワークを使用することです。[ 54 ] [ 55 ]
検索操作により、プログラマーはストリーム内の特定の要素を見つけたり、指定された要素の近傍要素を見つけたりすることができます。一般的に使用される検索方法は、ソート済みの要素に対する二分探索です。
GPU上では、さまざまなデータ構造を表現できます。
以下に、汎用コンピューティングにおいてGPUが利用されてきた分野の一部を示します。
バイオインフォマティクスにおけるGPGPUの使用：[ 71 ] [ 96 ]
ローリー氏は、同社のCUDA（Compute Unified Device Architecture）でプログラムされたNvidia Tesla GPU（グラフィックス処理ユニット）を使用してアルゴリズムを実装していると報じられている。Nvidiaは、GPUはCPUの計算よりも約2桁高速であり、処理時間を1フレームあたり1分未満に短縮できると主張している。
{{cite news}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)Nvidia Compute Unified Device Architecture（CUDA）ベースのグラフィックス処理ユニット（GPU）を搭載したワークステーション上で、信号完全性シミュレーションを高速化します。
。社内テストでは、Tesla S1070は、クロック速度2.6GHzで動作する一般的なIntel Core 2 Duo中央処理装置と比較して、類似性定義アルゴリズムの速度が360倍向上することが実証されました。