AMD /ATIRadeonアーキテクチャの機能

これは、生息地の発達中に生物が環境への適応性を改善するために進化するときの、新しい生物種の誕生に似ています。 そのため、GPUは、三角形のラスタライズとテクスチャリングの高速化から始めて、これらの同じ三角形に色を付けるためのシェーダープログラムを実行する追加の機能を開発しました。 そして、これらの機能は、非グラフィックコンピューティングで需要があることが判明しました。場合によっては、従来のソリューションと比較して大幅なパフォーマンスの向上が見られます。

私たちはさらに類推を描きます-陸での長い進化の後、哺乳類は海に侵入し、そこで彼らは普通の海洋生物を押し出しました。 競争の激しい戦いの中で、哺乳類は地表に現れた新しい高度な能力と、水中での生活に適応するために特別に獲得した能力の両方を使用しました。 同様に、GPUは、3Dグラフィックスのアーキテクチャの利点に基づいて、グラフィックス以外のタスクに役立つ特別な機能をますます獲得しています。

では、GPUが汎用プログラムの分野で独自のセクターを主張できるのはなぜですか？ GPUのマイクロアーキテクチャは、従来のCPUとは非常に異なる方法で構築されており、最初から特定の利点があります。 グラフィックタスクにはデータの独立した並列処理が含まれ、GPUはネイティブにマルチスレッド化されています。 しかし、この並列性は彼にとってただの喜びです。 マイクロアーキテクチャは、実行する必要のある多数のスレッドを活用するように設計されています。

GPUは、数十（Nvidia GT200の場合は30、Evergreenの場合は20、Fermiの場合は16）のプロセッサコアで構成され、Nvidiaの用語ではストリーミングマルチプロセッサ、ATIの用語ではSIMDエンジンと呼ばれます。 この記事のフレームワーク内では、ミニプロセッサと呼びます。これは、数百のプログラムスレッドを実行し、通常のCPUが実行できるほとんどすべてのことを実行できるためですが、それでもすべてではありません。

マーケティング名は紛らわしいです-それらは、より重要なことに、減算および乗算できる機能モジュールの数を示します。たとえば、320のベクトル「コア」（コア）。 これらのカーネルは、穀物のようなものです。 GPUは、多くのコアが同時に多くのスレッドを実行するマルチコアプロセッサと考える方がよいでしょう。

各ミニプロセッサにはローカルメモリがあり、GT200用に16 KB、Evergreen用に32 KB、Fermi用に64 KB（基本的にプログラム可能なL1キャッシュ）です。 従来のCPUのL1キャッシュと同様のアクセス時間があり、データを機能モジュールにできるだけ早く配信するという同様の機能を実行します。 Fermiアーキテクチャでは、ローカルメモリの一部を通常のキャッシュとして構成できます。 GPUでは、ローカルメモリを使用して、実行中のスレッド間でデータをすばやく交換します。 GPUプログラムの通常のスキームの1つは、次のとおりです。まず、GPUのグローバルメモリからのデータがローカルメモリにロードされます。 これは、「独自の」プロセッサとは別に配置された（システムメモリのような）通常のビデオメモリです。ビデオの場合、ビデオカードのテキストライト上のいくつかのマイクロ回路によってはんだ付けされています。 次に、数百のスレッドがローカルメモリ内のこのデータを処理し、結果をグローバルメモリに書き込みます。その後、CPUに転送されます。 ローカルメモリからデータをロードおよびアンロードするための命令を作成するのは、プログラマーの責任です。 本質的に、これは並列処理のための[特定のタスクの]データの分割です。 GPUは、メモリへのアトミック書き込み/読み取り命令もサポートしますが、非効率的であり、通常、すべてのミニプロセッサの計算結果を「接着」するための最終段階で必要になります。

ローカルメモリは、ミニプロセッサで実行されているすべてのスレッドに共通であるため、たとえば、Nvidiaの用語では共有と呼ばれることもあり、ローカルメモリという用語は正反対を意味します。つまり、グローバルの別のスレッドの特定のパーソナルエリアです。メモリ、表示され、それにのみアクセス可能。 ただし、ミニプロセッサには、ローカルメモリに加えて、すべてのアーキテクチャで、ボリュームが約4倍の別のメモリ領域があります。 実行中のすべてのスレッド間で均等に分割されます。これらは、変数と計算の中間結果を格納するためのレジスタです。 各スレッドには数十のレジスタがあります。 正確な数は、ミニプロセッサが実行しているスレッドの数によって異なります。 グローバルメモリのレイテンシは非常に高く、数百サイクルであり、キャッシュがない場合、計算の中間結果を保存する場所がないため、この数値は非常に重要です。

そして、GPUのもう1つの重要な機能は、「ソフト」ベクトル化です。 各ミニプロセッサには多数の計算モジュール（GT200用に8個、Radeon用に16個、Fermi用に32個）がありますが、同じプログラムアドレスで同じ命令しか実行できません。 この場合のオペランドは異なる可能性があり、異なるスレッドには独自のものがあります。 たとえば、命令 2つのレジスタの内容を追加します：すべてのコンピューティングデバイスで同時に実行されますが、異なるレジスタが使用されます。 データの並列処理を実行するGPUプログラムのすべてのスレッドは、通常、プログラムコード内を並列に移動すると想定されています。 したがって、すべてのコンピューティングモジュールが均等にロードされます。 また、プログラムの分岐が原因でスレッドがコード実行のパスで分岐した場合、いわゆるシリアル化が発生します。 次に、すべてのコンピューティングモジュールが使用されるわけではありません。スレッドは実行のために異なる命令を送信し、コンピューティングモジュールのブロックは、すでに述べたように、1つのアドレスを持つ命令のみを実行できます。 そしてもちろん、同時にパフォーマンスは最大値に比べて低下します。

利点は、ベクトル化が完全に自動化されており、SSEやMMXなどを使用してプログラミングされていないことです。 そして、GPU自体が不一致を処理します。 理論的には、実行中のモジュールのベクトルの性質を考慮せずにGPU用のプログラムを作成することは可能ですが、そのようなプログラムの速度はそれほど速くありません。 欠点は、ベクトルの幅が広いことです。 これは、機能モジュールの呼び数を超えており、Nvidia GPUの場合は32、Radeonの場合は64です。 スレッドは適切なサイズのブロックで処理されます。 Nvidiaは、このスレッドのブロックをワープ、AMD、波面と呼んでいます。これは同じことです。 したがって、16個のコンピューティングデバイスでは、64スレッド長の「波面」が4サイクルで処理されます（通常の命令長を想定）。 この場合、作者は経糸という用語を好みます。これは、航海用語の経糸と関連しているため、ねじれたロープから結ばれたロープを意味します。 したがって、スレッドは「ねじれ」、一体のバンドルを形成します。 ただし、「波面」は海と関連付けることもできます。波が次々と岸に転がるのと同じ方法で、命令がアクチュエータに到着します。

プログラムの実行ですべてのスレッドが同じように進行し（同じ場所にある）、同じ命令を実行する場合、すべてが正常ですが、そうでない場合は速度が低下します。 この場合、同じ経糸または波面の糸はプログラムの異なる場所にあり、糸のグループに分けられます。 同じ値命令番号（つまり、命令ポインタ）。 また、以前と同様に、一度に実行されるのは1つのグループのスレッドのみです。これらはすべて同じ命令を実行しますが、オペランドが異なります。 その結果、ワープは何倍も遅く実行され、いくつのグループに分割され、グループ内のスレッドの数は重要ではありません。 グループが1つのスレッドのみで構成されている場合でも、フルワープと同じくらい実行に時間がかかります。 ハードウェアでは、これは特定のスレッドをマスクすることによって実装されます。つまり、命令は正式に実行されますが、実行結果はどこにも記録されず、将来使用されません。

各ミニプロセッサ（ストリーミングマルチプロセッサまたはSIMDエンジン）は、常に1つのワープ（スレッドの束）にのみ属する命令を実行しますが、実行可能プールには数十のアクティブなワープがあります。 ミニプロセッサは、あるワープの命令を実行した後、このワープのスレッドの次の命令ではなく、ワープ内の他の誰かの命令を実行します。 そのワープはプログラム内の完全に異なる場所にある可能性があります。これは速度に影響しません。ワープ内でのみ、フルスピードで実行するためにすべてのスレッドの命令が同じである必要があるためです。

この場合、20個のSIMDエンジンのそれぞれに、それぞれ64個のスレッドを持つ4つのアクティブな波面があります。 各スレッドは短い線で示されます。 合計：64×4×20=5120スレッド

したがって、各ワープまたは波面が32〜64のスレッドで構成されているとすると、ミニプロセッサには、ほぼ同時に実行されている数百のアクティブなスレッドがあります。 以下では、このような多数の並列スレッドがもたらすアーキテクチャ上の利点を示しますが、最初に、GPUを構成するミニプロセッサにどのような制限があるかを検討します。

主なことは、GPUには、関数パラメーターとローカル変数を格納できるスタックがないことです。 スタックのスレッド数が多いため、チップ上にスペースがありません。 実際、GPUは100 KBのシングルスレッドスタックサイズで約10,000スレッドを同時に実行するため、合計量は1 GBになります。これは、すべてのビデオメモリの標準量に相当します。 さらに、GPUコア自体に重要なサイズのスタックを配置する方法はありません。 たとえば、スレッドごとに1000バイトのスタックを配置すると、1つのミニプロセッサだけで1 MBのメモリが必要になります。これは、ミニプロセッサのローカルメモリとレジスタの格納に割り当てられたメモリの合計量のほぼ5倍です。

したがって、GPUプログラムには再帰がなく、関数呼び出しで実際に向きを変えることはできません。 プログラムのコンパイル時に、すべての関数がコードに直接置き換えられます。 これにより、GPUの範囲が計算タスクに制限されます。 既知の小さな反復深度を持つ再帰アルゴリズムにグローバルメモリを使用して制限付きスタックエミュレーションを使用できる場合がありますが、これは一般的なGPUアプリケーションではありません。 これを行うには、CPUと比較して正常なアクセラレーションを保証せずに、その実装の可能性を調査するために、特別にアルゴリズムを開発する必要があります。

Fermiは最初に仮想関数を使用する機能を導入しましたが、繰り返しになりますが、各スレッドに大規模で高速なキャッシュがないため、仮想関数の使用は制限されています。 1536スレッドは48KBまたは16KBL1を占めます。つまり、プログラム内の仮想関数は比較的まれにしか使用できません。そうしないと、スタックが低速のグローバルメモリを使用するため、実行速度が低下し、比較してメリットが得られない可能性があります。 CPUバージョンに。

したがって、GPUは計算コプロセッサーとして提示され、データがロードされ、何らかのアルゴリズムによって処理され、結果が生成されます。

アーキテクチャの利点

しかし、GPUは非常に高速であると考えています。 そしてこれで彼は彼の高いマルチスレッドによって助けられています。 アクティブなスレッドの数が多いと、別々に配置されたグローバルビデオメモリの大きな遅延（約500サイクル）を部分的に隠すことができます。 これは、算術演算の密度が高いコードに対して特に適切に平準化されます。 したがって、トランジスタの高価なL1-L2-L3キャッシュ階層は必要ありません。 代わりに、多くのコンピューティングモジュールをチップに配置して、卓越した演算性能を提供できます。 その間、1つのスレッドまたはワープの命令が実行され、他の数百のスレッドが静かにデータを待機しています。

Fermiは約1MBの第2レベルのキャッシュを導入しましたが、最新のプロセッサのキャッシュと比較することはできません。コア間の通信やさまざまなソフトウェアトリックを対象としています。 そのサイズを数万のスレッドすべてに分割すると、それぞれの量はごくわずかになります。

ただし、グローバルメモリのレイテンシに加えて、コンピューティングデバイスには非表示にする必要のあるレイテンシがさらに多くあります。 これは、コンピューティングデバイスから第1レベルのキャッシュ（GPUのローカルメモリ）、レジスタ、および命令キャッシュへのチップ内のデータ転送のレイテンシです。 レジスタファイルとローカルメモリは機能モジュールとは別に配置されており、それらへのアクセス速度は約12サイクルです。 また、多数のスレッド、アクティブなワープは、このレイテンシーを効果的に隠すことができます。 さらに、GPU全体のローカルメモリへのアクセスの合計帯域幅（帯域幅）は、それを構成するミニプロセッサの数を考慮に入れると、最新のCPUの第1レベルのキャッシュへのアクセスの帯域幅よりもはるかに大きくなります。 GPUは、単位時間あたりに大幅に多くのデータを処理できます。

GPUに多数の並列スレッドが提供されていない場合、GPUは完全にロードされているかのように同じペースで動作し、作業量がはるかに少ないため、パフォーマンスはほぼゼロになるとすぐに言えます。 たとえば、10,000ではなく1つのスレッドだけを残します。すべてのブロックがロードされるだけでなく、すべてのレイテンシも影響するため、パフォーマンスは約1000倍低下します。

レイテンシーを隠す問題は、最新の高周波CPUでも深刻です。レイテンシーを排除するために高度な方法が使用されています。つまり、深いパイプライン化、命令のアウトオブオーダー実行（アウトオブオーダー）です。 これには、複雑な命令実行スケジューラやさまざまなバッファなどが必要であり、チップ上のスペースを占有します。 これはすべて、シングルスレッドモードで最高のパフォーマンスを実現するために必要です。

ただし、GPUの場合、これはすべて必要ではありません。多数のスレッドを使用する計算タスクの場合、アーキテクチャ的に高速です。 代わりに、賢者の石が鉛を金に変えるように、マルチスレッドをパフォーマンスに変換します。

GPUは元々、三角形ピクセルのシェーダープログラムを最適に実行するように設計されていました。これは明らかに独立しており、並列で実行できます。 そして、この状態から、さまざまな機能（ローカルメモリとビデオメモリへのアドレス可能なアクセス、および命令セットの複雑化）を非常に強力なコンピューティングデバイスに追加することで進化しました。これは、高度な並列実装を可能にするアルゴリズムにのみ効果的に適用できます。限られた量のローカルメモリを使用します。メモリ。

例

最も古典的なGPUの問題の1つは、重力場を作成するN体の相互作用を計算する問題です。 しかし、たとえば、Earth-Moon-Sunシステムの進化を計算する必要がある場合、GPUは私たちにとって悪いヘルパーです。オブジェクトはほとんどありません。 オブジェクトごとに、他のすべてのオブジェクトとの相互作用を計算する必要があり、そのうちの2つだけがあります。 すべての惑星とその衛星（約数百のオブジェクト）を含む太陽系の動きの場合、GPUはまだあまり効率的ではありません。 ただし、マルチコアプロセッサは、スレッド管理のオーバーヘッドコストが高いため、その能力をすべて発揮することはできず、シングルスレッドモードで動作します。 ただし、彗星や小惑星帯のオブジェクトの軌道も計算する必要がある場合は、必要な数の並列計算スレッドを作成するのに十分なオブジェクトがあるため、これはすでにGPUのタスクです。

GPUは、数十万の星の球状星団の衝突を計算する必要がある場合にもうまく機能します。

N体問題でGPUの能力を使用する別の機会は、少数の体ではあるが、多くの個別の問題を計算する必要がある場合に現れます。 たとえば、初速度のさまざまなオプションについて1つのシステムの進化を計算する場合です。 そうすれば、GPUを問題なく効果的に使用できるようになります。

AMDRadeonマイクロアーキテクチャの詳細

GPU編成の基本原則を検討しました。最初は、シェーダープログラムという1つのターゲットタスクがあったため、すべてのメーカーのビデオアクセラレータに共通です。 ただし、製造業者は、マイクロアーキテクチャの実装の詳細について意見が一致しない可能性があることを発見しました。 Pentium 4とAthlonまたはCoreのように、互換性がある場合でも、ベンダーごとにCPUが大きく異なる場合があります。 Nvidiaのアーキテクチャはすでに広く知られています。次に、Radeonを見て、これらのベンダーのアプローチの主な違いを強調します。

AMDグラフィックスカードは、DirectX 11仕様のパイオニアでもあるEvergreenファミリー以来、汎用コンピューティングを完全にサポートしています。47xxファミリーカードには、以下で説明するいくつかの重要な制限があります。

ローカルメモリサイズの違い（Radeonの場合は32 KB、GT200の場合は16 KB、Fermiの場合は64 KB）は、一般的に基本的なものではありません。 また、AMDの波面サイズは64スレッドであるのに対し、Nvidiaの波面サイズはワープあたり32スレッドです。 ほとんどすべてのGPUプログラムは、これらのパラメーターに合わせて簡単に再構成および調整できます。 パフォーマンスは数十パーセント変化する可能性がありますが、GPUの場合、GPUプログラムは通常CPUの対応するプログラムの10倍遅いか、10倍速いか、まったく機能しないため、これはそれほど重要ではありません。

さらに重要なのは、AMDによるVLIW（Very Long Instruction Word）テクノロジーの使用です。 Nvidiaはスカラーを使用します 簡単な手順、スカラーレジスタで動作します。 そのアクセラレータは、単純な古典的なRISCを実装します。 AMDグラフィックカードにはGT200と同じ数のレジスタがありますが、レジスタは128ビットベクトルです。 各VLIW命令は、SSEに似たいくつかの4コンポーネント32ビットレジスタで動作しますが、VLIWの機能ははるかに広いです。 これはSSEのようなSIMD（単一命令複数データ）ではありません-ここでは、オペランドの各ペアの命令は異なり、依存することさえあります！ たとえば、レジ​​スタAのコンポーネントにa1、a2、a3、a4という名前を付けます。 レジスターBの場合-同様に。 たとえば、数値a1×b1+a2×b2+a3×b3+a4×b4または2次元ベクトル（a1×b1 + a2×b2、a3× b3 + a4×b4）。

これは、GPUの周波数がCPUよりも低く、近年の技術プロセスの大幅な減少のおかげで可能になりました。 これにはスケジューラは必要ありません。ほとんどすべてがクロックごとに実行されます。

ベクトル命令を使用すると、Radeonのピーク単精度パフォーマンスはテラフロップスで非常に高くなります。

1つのベクトルレジスタは、4つの単精度数の代わりに1つの倍精度数を格納できます。 また、1つのVLIW命令は、2組のdoubleを加算するか、2つの数値を乗算するか、2つの数値を乗算して3番目に加算することができます。 したがって、doubleのピークパフォーマンスはfloatの約5分の1になります。 古いRadeonモデルの場合、新しいFermiアーキテクチャでのNvidia Teslaのパフォーマンスに対応し、GT200アーキテクチャでのダブルカードのパフォーマンスよりもはるかに高くなります。 Fermiをベースにした消費者向けGeforceビデオカードでは、二重計算の最大速度が4分の1に低下しました。

Radeonの作業の概略図。 並行して実行されている20個のうち1個のミニプロセッサのみが示されています

GPUメーカーは、CPUメーカー（まず第一に、x86互換のメーカー）とは異なり、互換性の問題に縛られていません。 GPUプログラムは最初にいくつかの中間コードにコンパイルされ、プログラムが実行されると、ドライバーはこのコードをに固有のマシン命令にコンパイルします。 特定のモデル。 上記のように、GPUメーカーは、GPU用の便利なISA（命令セットアーキテクチャ）を発明し、世代から世代へと変更することで、これを利用しました。 いずれにせよ、これにより、デコーダーが（不要として）不足しているため、パフォーマンスがある程度向上しました。 しかし、AMDはさらに進んで、機械語で命令を配置するための独自のフォーマットを発明しました。 それらは（プログラムリストに従って）順番に配置されるのではなく、セクションに配置されます。

最初に、条件付きジャンプ命令のセクションがあります。これには、さまざまな分岐分岐に対応する連続算術命令のセクションへのリンクがあります。 それらはVLIWバンドル（VLIW命令のバンドル）と呼ばれます。 これらのセクションには、レジスタまたはローカルメモリからのデータを含む算術命令のみが含まれています。 このような組織は、命令の流れと実行ユニットへの命令の配信を簡素化します。 VLIW命令が比較的大きいことを考えると、これはさらに便利です。 メモリアクセス命令のセクションもあります。

両方のメーカー（NvidiaとAMDの両方）のGPUには、数サイクルで単一の精度の数値の基本的な数学関数、平方根、指数、対数、正弦、および余弦をすばやく計算するための組み込み命令もあります。 これには特別な計算ブロックがあります。 それらは、ジオメトリシェーダーでこれらの関数の高速近似を実装する必要性から「生まれました」。

GPUがグラフィックスに使用されていることを知らず、技術的な特性に精通しているだけでも、この兆候から、これらのコンピューティングコプロセッサーはビデオアクセラレーターに由来していると推測できます。 同様に、海洋哺乳類のいくつかの特徴により、科学者は彼らの祖先が陸生生物であると信じるようになりました。

しかし、デバイスのグラフィカルな原点を示すより明白な機能は、双一次補間をサポートする2次元および3次元のテクスチャを読み取るためのブロックです。 これらは、読み取り専用データ配列の読み取りを高速かつ容易にするため、GPUプログラムで広く使用されています。 GPUアプリケーションの標準的な動作の1つは、初期データの配列を読み取り、それらを計算コアで処理し、その結果を別の配列に書き込んでから、CPUに戻すことです。 このようなスキームは、GPUアーキテクチャに便利なため、標準的で一般的です。 グローバルメモリの1つの大きな領域への集中的な読み取りと書き込みを必要とし、データの依存関係を含むタスクは、GPUに並列化して効率的に実装するのが困難です。 また、それらのパフォーマンスは、非常に大きいグローバルメモリのレイテンシに大きく依存します。 しかし、タスクが「データの読み取り-処理-結果の書き込み」というパターンで記述されている場合、GPUでの実行からほぼ確実に大きな後押しを得ることができます。

GPUのテクスチャデータの場合、第1レベルと第2レベルの小さなキャッシュの個別の階層があります。 また、テクスチャの使用による加速も提供します。 この階層は元々、テクスチャへのアクセスの局所性を利用するためにGPUに表示されました。明らかに、1つのピクセルを処理した後、隣接するピクセル（高い確率で）には、間隔の狭いテクスチャデータが必要になります。 しかし、従来のコンピューティングの多くのアルゴリズムは、データアクセスの性質が似ています。 したがって、グラフィックからのテクスチャキャッシュは非常に便利です。

NvidiaカードとAMDカードのL1-L2キャッシュのサイズはほぼ同じですが、これは明らかにゲームグラフィックスの最適性の要件が原因ですが、これらのキャッシュへのアクセスの遅延は大幅に異なります。 Nvidiaのアクセスレイテンシはより高く、Geforceのテクスチャキャッシュは、データアクセスを直接高速化するのではなく、主にメモリバスの負荷を軽減するのに役立ちます。 これはグラフィックプログラムでは目立ちませんが、汎用プログラムでは重要です。 Radeonでは、テクスチャキャッシュのレイテンシは低くなりますが、ミニプロセッサのローカルメモリのレイテンシは高くなります。 次に例を示します。Nvidiaカードで最適な行列乗算を行うには、ローカルメモリを使用して、ブロックごとに行列をロードすることをお勧めします。AMDの場合は、低レイテンシのテクスチャキャッシュに依存して、行列要素を次のように読み取ることをお勧めします。必要です。 しかし、これはすでにかなり微妙な最適化であり、GPUに基本的に転送されているアルゴリズムの場合です。

この違いは、3Dテクスチャを使用する場合にも現れます。 AMDにとって深刻な利点を示した最初のGPUコンピューティングベンチマークの1つは、3次元データアレイで機能するため、3Dテクスチャを使用しただけです。 また、Radeonのテクスチャアクセスレイテンシは大幅に高速化され、3Dケースはハードウェアでさらに最適化されています。

さまざまな企業のハードウェアから最大のパフォーマンスを得るには、特定のカード用にアプリケーションを調整する必要がありますが、原則として、GPUアーキテクチャのアルゴリズムの開発よりも桁違いに重要ではありません。

Radeon47xxシリーズの制限

このファミリでは、GPUコンピューティングのサポートは不完全です。 3つの重要な点に注意することができます。 まず、ローカルメモリはありません。つまり、物理的には存在しますが、GPUプログラムの最新の標準で必要とされるユニバーサルアクセスがありません。 プログラムでグローバルメモリにエミュレートされます。つまり、フル機能のGPUとは対照的に、使用してもメリットはありません。 2つ目のポイントは、さまざまなアトミックメモリ操作命令と同期命令のサポートが制限されていることです。 そして3番目のポイントは、命令キャッシュのサイズがかなり小さいことです。特定のプログラムサイズから開始すると、速度が数倍遅くなります。 他にも小さな制限があります。 このビデオカードでは、GPUに最適なプログラムのみが適切に機能すると言えます。 ビデオカードは、レジスタのみで動作する単純なテストプログラムでギガフロップスで良好な結果を示すことができますが、複雑なものを効果的にプログラムすることには問題があります。

エバーグリーンの長所と短所

AMD製品とNvidia製品を比較すると、GPUコンピューティングの観点から、5xxxシリーズは非常に強力なGT200のように見えます。 非常に強力なので、ピークパフォーマンスでフェルミを約2.5倍上回ります。 特に、新しいNvidiaビデオカードのパラメータが削減された後、コアの数が削減されました。 ただし、FermiでのL2キャッシュの出現により、GPUでの一部のアルゴリズムの実装が簡素化され、GPUの範囲が拡大します。 興味深いことに、前世代のGT200 CUDAプログラムに最適化されているため、Fermiのアーキテクチャの革新はしばしば何もしませんでした。 それらは、コンピューティングモジュールの数の増加に比例して加速しました。つまり、メモリ帯域幅が増加しなかったため（または他の理由で）、2倍未満（単精度数の場合）、またはそれ以下でした。

また、GPUアーキテクチャにうまく適合し、ベクトルの性質がはっきりしているタスク（行列の乗算など）では、Radeonは理論上のピークに比較的近いパフォーマンスを示し、Fermiを追い越します。 マルチコアCPUは言うまでもありません。 特に単精度数の問題で。

しかし、Radeonのダイ面積は小さく、熱放散、消費電力、歩留まりが高く、したがってコストも低くなります。 そして、3Dグラフィックスの問題に直接、フェルミゲインは、もしあれば、水晶の面積の違いよりもはるかに小さいです。 これは主に、ミニプロセッサあたり16の計算ユニット、64スレッドの波面、およびVLIWベクトル命令を備えたRadeonの計算アーキテクチャが、その主要なタスクであるグラフィックシェーダーの計算に最適であるという事実によるものです。 通常のユーザーの大多数にとって、ゲームのパフォーマンスと価格が優先されます。

専門的で科学的なプログラムの観点から、Radeonアーキテクチャは、最高の価格性能比、ワットあたりのパフォーマンス、および原則としてGPUアーキテクチャに適合し、並列化とベクトル化を可能にするタスクの絶対パフォーマンスを提供します。

たとえば、完全に並列で簡単にベクトル化できるキー選択の問題では、RadeonはGeforceの数倍、CPUの数十倍高速です。

これは一般的なAMDFusionの概念に対応しており、GPUはCPUを補完し、数学コプロセッサーが以前に別のチップからプロセッサーコアに転送されたのと同じように、将来的にはCPUコア自体に統合されます（これは20回発生しました）。数年前、最初の登場前 Pentiumプロセッサ）。 GPUは、ストリーミングタスク用の統合グラフィックコアおよびベクトルコプロセッサーになります。

Radeonは、汎用モジュールによって実行されるときに、さまざまな波面からの命令を混合するというトリッキーな手法を使用します。 命令は完全に独立しているため、これは簡単に実行できます。 原理は、最新のCPUによる独立した命令のパイプライン実行に似ています。 どうやら、これにより、複雑なマルチバイトのベクトルVLIW命令を効率的に実行できるようになります。 CPUでは、これには、独立した命令を識別するための高度なスケジューラー、または異なるスレッドからの既知の独立した命令をCPUに提供するハイパースレッディングテクノロジーの使用が必要です。

それぞれ64の操作で構成される2つの波面の128の命令は、8サイクルで16のVLIWモジュールによって実行されます。 交代があり、2番目のサイクルで新しいモジュールの実行を並行して開始する場合、各モジュールには実際には命令全体を実行するための2つのサイクルがあります。 これはおそらく、a1×a2+b1×b2+c1×c2+d1×d2のようなVLIW命令をすばやく実行するのに役立ちます。つまり、8サイクルで8つのそのような命令を実行します。 （正式には、クロックごとに1つであることがわかります。）

Nvidiaには明らかにこのテクノロジーがありません。 また、VLIWがない場合、スカラー命令を使用した高性能には 高周波仕事は、自動的に熱放散を増加させ、技術的プロセスに高い要求を課します（回路をより高い周波数で動作させるため）。

GPUコンピューティングに関するRadeonの欠点は、分岐が非常に嫌いなことです。 GPUは通常、命令を実行するための上記のテクノロジーのために分岐を好みません。1つのプログラムアドレスを持つスレッドのグループによってすぐに実行されます。 （ちなみに、この手法はSIMT：単一命令-複数のスレッド（1つの命令-多数のスレッド）と呼ばれ、SIMDと同様に、1つの命令が異なるデータで1つの操作を実行します。） プログラムが完全にベクトルでない場合、ワープまたは波面のサイズが大きいほど悪化することは明らかです。隣接するスレッドのプログラムを通るパスが分岐すると、より多くのグループが形成され、順次実行する必要があるためです（シリアル化） ）。 すべてのスレッドが分散しているとしましょう。ワープサイズが32スレッドの場合、プログラムの実行速度は32倍遅くなります。 また、サイズ64の場合、Radeonのように、64倍遅くなります。

これは目立ちますが、「嫌い」の唯一の兆候ではありません。 Nvidiaビデオカードでは、CUDAコアとも呼ばれる各機能モジュールには、特別なブランチ処理ユニットがあります。 また、16個のコンピューティングモジュール用のRadeonビデオカードには、2つの分岐制御ユニットしかありません（これらは算術ユニットのドメインから派生しています）。 したがって、条件付き分岐命令の単純な処理でさ​​え、その結果が波面のすべてのスレッドで同じであっても、追加の時間がかかります。 そして、速度が低下します。

AMDはCPUも製造しています。 彼らは、多くのブランチを持つプログラムには、CPUがさらに適していると信じており、GPUは純粋にベクタープログラムを対象としています。

そのため、Radeonは全体的に効率の悪いプログラミングを提供しますが、多くの場合、価格とパフォーマンスの比率は高くなります。 言い換えると、Fermiで効果的に実行できるプログラムよりも、CPUからRadeonに効率的に（有益に）移行できるプログラムの数が少なくなります。 しかし一方で、効果的に転送できるものは、多くの点でRadeonでより効率的に機能します。

GPUコンピューティング用のAPI

GPUコンピューティングを理想化して絶対化する必要はありませんが、Radeon自体の技術仕様は魅力的に見えます。 しかし、パフォーマンスにとっても同様に重要です ソフトウェア GPUプログラムの開発と実行に必要-言語からのコンパイラ 上級ランタイム、つまり、CPUで実行されているプログラムの一部とGPU自体の間で相互作用するドライバー。 CPUの場合よりもさらに重要です。CPUはデータ転送を管理するためのドライバーを必要とせず、コンパイラーの観点からは、GPUはより扱いにくいです。 たとえば、コンパイラは、計算の中間結果を格納するために最小数のレジスタを処理し、最小数のレジスタを使用して関数呼び出しを慎重にインライン化する必要があります。 結局のところ、スレッドが使用するレジスタが少なければ少ないほど、実行できるスレッドが多くなり、GPUをより完全にロードできるため、メモリアクセス時間をより適切に隠すことができます。

そのため、Radeon製品のソフトウェアサポートは、ハードウェアの開発にまだ遅れをとっています。 （ハードウェアのリリースが遅れ、製品が簡素化された形でリリースされたNvidiaの状況とは対照的です。）最近、AMDのOpenCLコンパイラーはベータ版であり、多くの欠陥がありました。 誤ったコードを生成したり、正しいソースコードからコードをコンパイルすることを拒否したり、それ自体でエラーが発生してクラッシュしたりすることがよくありました。 春の終わりになって初めて、高性能のリリースが行われました。 また、エラーがないわけではありませんが、エラーの数は大幅に少なく、原則として、正しさの危機に瀕している何かをプログラムしようとすると、傍観者になります。 たとえば、4バイトの4コンポーネント変数を指定するuchar4タイプで動作します。 このタイプはOpenCL仕様に含まれていますが、レジスタが128ビットであるためRadeonで使用する価値はありません。同じ4つのコンポーネントですが、32ビットです。 そして、そのようなuchar4変数は依然としてレジスタ全体を占有し、個々のバイトコンポーネントをパックしてアクセスする追加の操作のみが必要になります。 コンパイラにバグはないはずですが、バグのないコンパイラはありません。 11バージョン以降のIntelコンパイラでもコンパイルエラーが発生します。 識別されたバグは次のリリースで修正され、秋にリリースされる予定です。

しかし、まだ改善が必要なことがたくさんあります。 たとえば、これまで、Radeonの標準GPUドライバーはOpenCLを使用したGPUコンピューティングをサポートしていません。 ユーザーは、追加の特別なパッケージをダウンロードしてインストールする必要があります。

しかし、最も重要なことは、関数のライブラリがないことです。 倍精度の実数の場合、正弦、余弦、指数すらありません。 まあ、これは行列の加算/乗算には必要ありませんが、もっと複雑なものをプログラムしたい場合は、すべての関数を最初から作成する必要があります。 または、新しいSDKのリリースを待ちます。 基本的な行列関数をサポートするEvergreenGPUファミリ用のACML（AMD Core Math Library）は、まもなくリリースされる予定です。

現時点では、記事の作成者によると、Direct Compute 5.0 APIの使用は、Radeonビデオカードのプログラミングには現実的であるように思われます。当然、制限を考慮に入れています。 Windowsプラットフォーム 7およびWindowsVista。 マイクロソフトはコンパイラの作成に多くの経験があり、すぐに完全に機能するリリースを期待できます。マイクロソフトはこれに直接関心を持っています。 しかし、Direct Computeは、インタラクティブなアプリケーションのニーズに焦点を合わせています。たとえば、何かを計算してすぐに結果を視覚化することです。たとえば、表面上の液体の流れなどです。 これは、単に計算に使用できないという意味ではありませんが、これは本来の目的ではありません。 たとえば、MicrosoftはDirectComputeにライブラリ関数を追加する予定はありません。AMDには現在ないものです。 つまり、Radeonで効果的に計算できるもの（あまり洗練されていないプログラムもあります）は、OpenCLよりもはるかに単純で安定しているDirectComputeにも実装できます。 さらに、完全に移植可能であり、NvidiaとAMDの両方で実行されるため、プログラムをコンパイルする必要があるのは1回だけですが、NvidiaとAMDのOpenCLSDK実装は完全に互換性がありません。 （AMD OpenCL SDKを使用してAMDシステムでOpenCLプログラムを開発する場合、Nvidiaでは簡単に実行できない可能性があります。NvidiaSDKを使用して同じテキストをコンパイルする必要がある場合があります。もちろんその逆も同様です。 ）。

次に、OpenCLは、幅広いシステム向けのユニバーサルプログラミング言語およびAPIとなることを目的としているため、OpenCLには多くの冗長機能があります。 そしてGPU、そしてCPU、そしてセル。 したがって、一般的なユーザーシステム（プロセッサとビデオカード）用のプログラムを作成したいだけの場合、OpenCLは、いわば「生産性が高い」とは思えません。 各関数には10個のパラメーターがあり、そのうちの9個を0に設定する必要があります。また、各パラメーターを設定するには、パラメーターもある特別な関数を呼び出す必要があります。

また、Direct Computeの現在の最も重要な利点は、ユーザーが特別なパッケージをインストールする必要がないことです。必要なものはすべてDirectX11に既に含まれています。

GPUコンピューティングの開発の問題

パーソナルコンピュータの分野を考えると、状況は次のようになります。多くの計算能力を必要とし、従来のデュアルコアプロセッサには深刻な不足があるタスクは多くありません。 まるで大きなごみのようでしたが、不器用な怪物が海から陸に這い出ており、陸で食べるものはほとんどありませんでした。 そして、地球の表面の原始的な住居は、天然資源が不足しているときにいつも起こるように、サイズが小さくなり、消費量が少なくなることを学んでいます。 今日、10〜15年前と同じパフォーマンスの必要性があったとしたら、GPUコンピューティングは大成功で受け入れられるでしょう。 そのため、互換性の問題とGPUプログラミングの相対的な複雑さが浮き彫りになります。 高速で実行されるがGPUでのみ実行されるプログラムよりも、すべてのシステムで実行されるプログラムを作成することをお勧めします。

GPUの見通しは、パフォーマンスに対する需要が高まっているため、プロフェッショナルアプリケーションおよびワークステーションセクターでの使用に関していくらか良くなっています。 GPU対応の3Dエディター用のプラグインが登場しています。たとえば、レイトレーシングを使用したレンダリング用です。通常のGPUレンダリングと混同しないでください。 複雑な効果をより速く作成することで、2Dおよびプレゼンテーションエディターにも何かが現れています。 ビデオ処理プログラムも徐々にGPUのサポートを獲得しています。 上記のタスクは、並列性の観点から、GPUアーキテクチャにうまく適合しますが、非常に大きなコードベースが作成、デバッグ、すべてのCPU機能に対して最適化されているため、適切なGPU実装が表示されるまでには時間がかかります。

このセグメントでは、限られた量のビデオメモリ（従来のGPUでは約1 GB）など、GPUのこのような弱点も明らかになります。 GPUプログラムのパフォーマンスを低下させる主な要因の1つは、低速バスを介してCPUとGPUの間でデータを交換する必要があることです。また、メモリの量が限られているため、より多くのデータを転送する必要があります。 そしてここで、GPUとCPUを1つのモジュールに組み合わせるというAMDの概念は有望に見えます。グラフィックスメモリの高帯域幅を犠牲にして、共有メモリへの簡単でシンプルなアクセスを実現し、さらに低レイテンシを実現できます。 現在のDDR5ビデオメモリのこの高帯域幅は、ほとんどのGPUコンピューティングプログラムよりもグラフィックプログラムによって直接要求されます。 一般に、GPUとCPUの共通メモリは、GPUの範囲を大幅に拡大し、プログラムの小さなサブタスクでそのコンピューティング機能を使用できるようにします。

そして、すべてのGPUのほとんどは、科学計算の分野で需要があります。 いくつかのGPUベースのスーパーコンピューターがすでに構築されており、マトリックス操作のテストで非常に高い結果を示しています。 科学的な問題は非常に多様で多数あるため、GPUアーキテクチャに完全に適合するセットが常に存在し、GPUを使用すると簡単に高性能を得ることができます。

すべてのタスクの中で 現代のコンピューターいずれかを選択してください。それはコンピュータグラフィックスになります。これは、私たちが住んでいる世界のイメージです。 そして、この目的に最適なアーキテクチャは悪いことではありません。 これは非常に重要で基本的なタスクであるため、そのために特別に設計されたハードウェアはユニバーサルであり、さまざまなタスクに最適である必要があります。 さらに、ビデオカードは順調に進化しています。

最近の最も隠された機能の1つ WindowsUpdate 10は、どのアプリケーションがグラフィックスプロセッシングユニット（GPU）を使用しているかを確認する機能です。 タスクマネージャを開いたことがあれば、CPU使用率を調べて、CPUを最も集中的に使用しているアプリケーションを確認したことがあるでしょう。 の 最新の更新同様の機能を追加しましたが、GPUGPU用です。 サードパーティのソフトウェアをダウンロードしなくても、ソフトウェアとゲームがGPUにどれほど集中しているかを理解するのに役立ちます。 CPUをGPUにオフロードするのに役立つもう1つの興味深い機能があります。 選び方を読むことをお勧めします。

タスクマネージャーにGPUがないのはなぜですか？

残念ながら、すべてのグラフィックカードがGPUを読み取るために必要な統計をWindowsに提供できるわけではありません。 確かに、DirectX診断ツールを使用してこのテクノロジをすばやくテストできます。

1. クリック " 始める"そして検索で書く dxdiag DirectX診断ツールを実行します。
2. タブに移動" 画面"、列の右側 運転手「あなたは持っているべきです WDDMモデルタスクマネージャーでGPUグラフを使用するための2.0以降のバージョン。

タスクマネージャーでGPUグラフを有効にする

各アプリケーションのGPU使用量を確認するには、タスクマネージャーを開く必要があります。

• ボタンの組み合わせを押す Ctrl + Shift + Escタスクマネージャを開きます。
• 空のフィールドでタスクマネージャを右クリックします" 名前"ドロップダウンメニューから確認してください GPU。また、注意することができます GPUコアどのプログラムがそれを使用しているかを確認します。
• タスクマネージャーで、GPUグラフとGPUコアが右側に表示されます。

全体的なGPUパフォーマンスを表示する

GPUの全体的な使用状況を監視して、高負荷の下で監視および分析できます。 この場合、あなたはあなたが必要とするすべてを「 パフォーマンス"を選択して グラフィックプロセッサ。

各GPU要素は個々のグラフに分割されており、GPUがどのように使用されているかをさらに詳しく知ることができます。 表示されるグラフを変更する場合は、各タスクのタイトルの横にある小さな矢印をクリックできます。 この画面には、ドライバーのバージョンと日付も表示されます。これは、DXDiagまたはデバイスマネージャーを使用する代わりに使用できます。

今日、一般的なコンピューティングにGPUを使用することについてのニュースは、隅々まで聞かれます。 CUDA、Stream、OpenCLなどの単語は、わずか2年でITインターネット上で最も引用されている単語になりました。 しかし、これらの言葉が何を意味するのか、そしてその背後にある技術が何であるのかは、誰にも知られていません。 そして、「飛行中」に慣れているLinuxoidにとって、一般的に、これはすべて暗い森と見なされます。

GPGPUの誕生

私たちは皆、注文されたコードを実行できるコンピューターの唯一のコンポーネントは中央処理装置であると考えることに慣れています。 長い間、ほとんどすべての主流のPCには、オペレーティングシステムのコード、すべてのソフトウェア、ウイルスなど、考えられるすべての計算を処理する単一のプロセッサが搭載されていました。

その後、マルチコアプロセッサとマルチプロセッサシステムが登場し、そのようなコンポーネントがいくつかありました。 これにより、マシンは同時に複数のタスクを実行でき、システムの全体的な（理論上の）パフォーマンスは、マシンにインストールされているコアの数とまったく同じくらい向上しました。 しかし、マルチコアプロセッサの製造と設計は非常に困難で費用がかかることが判明しました。

各コアは、独自の（かなり大きな）キャッシュ、命令パイプライン、SSEブロック、最適化を実行する多くのブロックなどを備えた、複雑で複雑なx86アーキテクチャの本格的なプロセッサをホストする必要がありました。 等 したがって、コアの数を増やすプロセスは大幅に遅くなり、2つまたは4つのコアでは明らかに不十分であった白い大学のコートは、科学計算に他の計算能力を使用する方法を見つけました。ビデオカード（その結果、BrookGPUツールでさえも登場し、エミュレートしました 追加のプロセッサ DirectXおよびOpenGL関数呼び出しを使用）。

中央処理装置の多くの欠点がないGPUは、優れた非常に高速な計算機であることが判明し、すぐにGPUメーカー自身が科学者の発達を注意深く観察し始めました（そしてnVidiaはほとんどの研究者を採用しました全般的）。 その結果がnVidiaのCUDAテクノロジーであり、複雑なアルゴリズムの計算を松葉杖なしでGPUの肩に転送できるようにするインターフェイスを定義します。 その後、Close to Metal（現在はStream）と呼ばれる独自のテクノロジーのバリエーションを備えたATi（AMD）が続き、その後まもなく、OpenCLと呼ばれるAppleの標準バージョンが登場しました。

GPUが私たちのすべてですか？

すべての利点にもかかわらず、GPGPU技術にはいくつかの問題があります。 これらの最初のものは非常に狭い範囲にあります。 GPUは、コンピューティング能力とコアの総数の増加という点で中央処理装置よりもはるかに進んでいます（ビデオカードは、100を超えるコアで構成されるコンピューティングユニットを搭載しています）が、チップ自体のデザイン。

本質的に、GPUの主なタスクは、入力としてそれほど大量の予測可能なデータを受け取らない単純なアルゴリズムを使用した数学的計算に還元されます。 このため、GPUコアは非常にシンプルな設計、わずかなキャッシュボリューム、および適度な命令セットを備えており、最終的には製造コストが低く、チップ上に非常に高密度に配置できる可能性があります。 GPUは、何千人もの労働者を抱える中国の工場のようなものです。 彼らはいくつかの簡単なことを非常にうまくやっています（そして最も重要なのは-迅速かつ安価に）が、航空機の組み立てを彼らに任せれば、結果は最大のハンググライダーになります。

したがって、GPUの最初の制限は、高速の数学的計算に焦点を当てることです。これにより、マルチメディアアプリケーションや、複雑なデータ処理に関連するプログラム（アーカイバーや暗号化システムなど、また、蛍光顕微鏡、分子ダイナミクス、静電学、およびLinuxユーザーにはほとんど関心のないその他のものに関連するソフトウェアも含まれます。

GPGPUの2番目の問題は、すべてのアルゴリズムをGPUで実行できるとは限らないことです。 個々のGPUコアは非常に低速であり、それらのパワーは、それらが連携して機能する場合にのみ機能します。 そしてこれは、プログラマーが効果的に並列化できるのと同じくらい効率的なアルゴリズムになることを意味します。 ほとんどの場合、そのような仕事に対処できるのは優秀な数学者だけであり、ソフトウェア開発者の中にはごくわずかです。

そして第3に、GPUはビデオカード自体にインストールされたメモリで動作するため、GPUがアクティブ化されるたびに、2つの追加のコピー操作が発生します。 ランダム・アクセス・メモリアプリケーション自体とGRAMからの出力をアプリケーションメモリに戻します。 これにより、アプリケーション時間の増加が無効になる可能性があることを推測するのは難しいことではありません（FlacCLツールで発生します。これについては後で説明します）。

しかし、それだけではありません。 OpenCLに直面して一般的に受け入れられている標準が存在するにもかかわらず、多くのプログラマーは依然としてGPGPU技術のベンダー固有の実装を使用することを好みます。 CUDAは特に人気があり、より柔軟なプログラミングインターフェイスを提供しますが（ちなみに、nVidiaドライバーのOpenCLはCUDAの上に実装されています）、アプリケーションを1つのメーカーのビデオカードに緊密に結び付けています。

今は何ですか？

その若さのために、そしてまた上記の問題のために、GPGPUは真に普及した技術にはなりませんでした、しかし、その機能を使用する有用なソフトウェアは存在します（わずかではありますが）。 さまざまなハッシュのクラッカーが最初に登場しましたが、そのアルゴリズムは非常に簡単に並列化できます。

トランスコードを可能にするFlacCLエンコーダーなどのマルチメディアアプリケーションも誕生しました オーディオトラック FLAC形式に。 一部の既存のアプリケーションもGPGPUのサポートを取得しており、その中で最も注目すべきものはImageMagickでした。これは、OpenCLを使用して作業の一部をグラフィックプロセッサにシフトする方法を知っています。 データアーカイバやその他の情報圧縮システムをCUDA/OpenCLに転送するプロジェクトもあります（ATi Unixoidは好きではありません）。 この記事の次のセクションでは、これらのプロジェクトの中で最も興味深いものを検討しますが、今のところ、これらすべてを開始して安定して動作させるために必要なものを理解しようとします。

GPUは、パフォーマンスにおいてx86プロセッサを長い間上回っています

・次に、システムにビデオカード用の最新のプロプライエタリドライバがインストールされている必要があります。これらのドライバは、カードのネイティブGPGPUテクノロジとオープンOpenCLの両方をサポートします。

・そして第3に、ディストリビューションビルダーはGPGPUをサポートするアプリケーションパッケージの配布をまだ開始していないため、自分でアプリケーションをビルドする必要があります。そのためには、メーカーの公式SDK（CUDAToolkitまたはATIStream SDK）が必要です。 これらには、アプリケーションの構築に必要なヘッダーファイルとライブラリが含まれています。

CUDAツールキットをインストールする

上記のリンクをたどり、Linux用のCUDA Toolkitをダウンロードします（Fedora、RHEL、Ubuntu、およびSUSEディストリビューションの場合、x86とx86_64の両方のアーキテクチャーのバージョンがあります）。 さらに、開発者向けのドライバーキットをダウンロードする必要があります（Linux用の開発者ドライバー。リストの最初にあります）。

SDKインストーラーを実行します。

$ sudo sh cudatoolkit_4.0.17_linux_64_ubuntu10.10.run

インストールが完了したら、ドライバのインストールに進みます。 これを行うには、Xサーバーをシャットダウンします。

＃sudo /etc/init.d/gdm stop

コンソールを開く ドライバーインストーラーを実行します。

$ sudo sh devdriver_4.0_linux_64_270.41.19.run

インストールが完了したら、Xを起動します。

アプリケーションがCUDA/OpenCLで動作するように、LD_LIBRARY_PATH変数にCUDAライブラリを含むディレクトリへのパスを書き込みます。

$ export LD_LIBRARY_PATH = / usr / local / cuda / lib64

または、32ビットバージョンをインストールした場合：

$ export LD_LIBRARY_PATH = / usr / local / cuda / lib32

また、コンパイラがアプリケーションのビルド段階でCUDAヘッダーファイルを見つけられるように、CUDAヘッダーファイルへのパスを指定する必要があります。

$ export C_INCLUDE_PATH = / usr / local / cuda / include

これで、CUDA/OpenCLソフトウェアの構築を開始できます。

ATIStreamSDKをインストールします

Stream SDKはインストールを必要としないため、AMD Webサイトからダウンロードしたアーカイブは、任意のディレクトリに簡単に解凍できます（ 最善の選択/ opt）になり、同じLD_LIBRARY_PATH変数にパスを書き込みます。

$ wget http://goo.gl/CNCNo

$ sudo tar -xzf〜/ AMD-APP-SDK-v2.4-lnx64.tgz -C / opt

$ export LD_LIBRARY_PATH = / opt / AMD-APP-SDK-v2.4-lnx64 / lib / x86_64 /

$ export C_INCLUDE_PATH = / opt / AMD-APP-SDK-v2.4-lnx64 / include /

CUDA Toolkitと同様に、32ビットシステムではx86_64をx86に置き換える必要があります。 次に、ルートディレクトリに移動し、icd-registration.tgzアーカイブを解凍します（これは一種の無料です） ライセンスキー):

$ sudo tar -xzf /opt/AMD-APP-SDK-v2.4-lnx64/icd-registration.tgz-から /

clinfoツールを使用して、パッケージの正しいインストール/操作を確認します。

$ / opt / AMD-APP-SDK-v2.4-lnx64 / bin / x86_64 / clinfo

ImageMagickとOpenCL

OpenCLのサポートはずっと前にImageMagickに登場しましたが、どのディストリビューションでもデフォルトで有効になっていません。 したがって、ソースから自分でIMを構築する必要があります。 これについて複雑なことは何もありません。必要なものはすべてSDKにすでに含まれているため、アセンブリではnVidiaまたはAMDから追加のライブラリをインストールする必要はありません。 したがって、ソースを含むアーカイブをダウンロード/解凍します。

$ wget http://goo.gl/F6VYV

$ tar -xjf ImageMagick-6.7.0-0.tar.bz2

$ cd ImageMagick-6.7.0-0

$ sudo apt-get install build-essential

configuratorを実行し、OpenCLサポートのためにその出力を取得します。

$ LDFLAGS = -L $ LD_LIBRARY_PATH ./configure | grep -e cl.h -e OpenCL

コマンドの正しい出力は次のようになります。

CL/cl.hのユーザビリティをチェックしています...はい

CL/cl.hの存在を確認しています...はい

CL/cl.hをチェックしています...はい

OpenCL/cl.hのユーザビリティをチェックしています...いいえ

OpenCL/cl.hの存在を確認しています...いいえ

OpenCL/cl.hをチェックしています...いいえ

OpenCLライブラリをチェックしています...-lOpenCL

「はい」という単語は、最初の3行または2行目（あるいはその両方）をマークする必要があります。 そうでない場合は、C_INCLUDE_PATH変数が正しく初期化されていない可能性があります。 「no」という単語が最後の行を示している場合、問題はLD_LIBRARY_PATH変数にあります。 すべて問題がない場合は、ビルド/インストールプロセスを開始します。

$ sudo make install clean

ImageMagickが実際にOpenCLサポートでコンパイルされたことを確認します。

$ / usr / local / bin / convert-version | grepの機能

機能：OpenMP OpenCL

次に、結果として得られる速度の向上を測定しましょう。 ImageMagickの開発者は、これに畳み込みフィルターを使用することをお勧めします。

$ time /usr/bin/convert image.jpg -convolve "-1、-1、-1、-1、9、-1、-1、-1、-1" image2.jpg

$ time /usr/local/bin/convert image.jpg -convolve "-1、-1、-1、-1、9、-1、-1、-1、-1" image2.jpg

サイズ変更などの他の操作もはるかに高速に動作するはずですが、ImageMagickがグラフィックの処理を驚異的な速度で開始することを期待するべきではありません。 これまでのところ、OpenCLで最適化されているパッケージはほとんどありません。

FlacCL（フラクーダ）

FlacCLは、OpenCL機能を利用するFLACオーディオエンコーダーです。 これはWindows用のCUEToolsパッケージの一部ですが、monoのおかげで、Linuxでも使用できます。 エンコーダーでアーカイブを取得するには、次のコマンドを実行します。

$ mkdir flaccl && cd flaccl

$ wget www.cuetools.net/install/flaccl03.rar

$ sudo apt-get install unrar mono

$ unrar x fl accl03.rar

プログラムがOpenCLライブラリを見つけることができるように、シンボリックリンクを作成します。

$ ln -s $ LD_LIBRARY_PATH / libOpenCL.so libopencl.so

それでは、エンコーダーを起動しましょう。

$ mono CUETools.FLACCL.cmd.exe music.wav

画面に「エラー：要求されたコンパイルサイズが必要なワークグループサイズの32を超えています」というエラーメッセージが表示された場合は、システムにビデオカードがありません。関連するコアの数を、指定された数に減らす必要があります。フラグ'-group-sizeXX'を使用します。ここで、XXは必要なコア数です。

OpenCLの初期化時間が長いため、目立ったゲインは十分に長いトラックでのみ得られるとすぐに言わなければなりません。 FlacCLは、従来のバージョンとほぼ同じ速度で短いオーディオファイルを処理します。

oclHashcatまたはクイックブルートフォース

すでに述べたように、さまざまなクラッカーとパスワードブルートフォースシステムの開発者は、自社製品にGPGPUサポートを最初に追加した企業の1つです。 彼らのために 新技術は本当の聖杯になり、自然に簡単に並列化できるコードを高速GPUプロセッサの肩に簡単に転送できるようになりました。 したがって、そのようなプログラムの非常に異なる実装が数十あることは驚くべきことではありません。 しかし、この記事では、そのうちの1つであるoclHashcatについてのみ説明します。

oclHashcatは、OpenCLを使用してGPUパワーを使用しながら、非常に高速でハッシュによってパスワードを解読できるクラッカーです。 プロジェクトのWebサイトで公開されている測定値によると、nVidia GTX580でのMD5パスワード選択の速度は、1秒あたり最大1億5800万の組み合わせです。これにより、oclHashcatはわずか9分で平均的な複雑さの8文字のパスワードを見つけることができます。

このプログラムは、OpenCLおよびCUDA、MD5アルゴリズム、md5（$pass。$salt）、md5（md5（$ pass））、vBulletinをサポートしています。< v3.8.5, SHA1, sha1($pass.$salt), хэши MySQL, MD4, NTLM, Domain Cached Credentials, SHA256, поддерживает распределенный подбор паролей с задействованием мощности нескольких машин.

$ 7z x oclHashcat-0.25.7z

$ cdoclHashcat-0.25

そして、プログラムを実行します（ハッシュのトライアルリストとトライアル辞書を使用します）：

$ ./oclHashcat64.bin example.hash？l？l？l？l example.dict

oclHashcatはテキストを開きます ユーザー規約、「YES」と入力して受け入れる必要があります。 その後、列挙プロセスが開始されます。進行状況は、を押すと確認できます。 。 プロセスを一時停止するには、を押します

再開します - 。 ブルートフォースを使用することもできます（たとえば、aaaaaaaaaからzzzzzzzまで）。

$ ./oclHashcat64.bin hash.txt？l？l？l？l？l？l？l？l

そして、辞書と直接列挙方法のさまざまな変更、およびそれらの組み合わせ（これについては、docs / examples.txtファイルで読むことができます）。 私の場合、辞書全体の列挙速度は11分でしたが、直接列挙（aaaaaaaaaからzzzzzzzzまで）は約40分続きました。 平均して、GPU（RV710チップ）の速度は8830万/秒でした。

結論

多くの異なる制限とソフトウェア開発の複雑さにもかかわらず、GPGPUは高性能デスクトップコンピューターの未来です。 しかし、最も重要なことは、このテクノロジーの機能を今すぐ使用できることです。これは、Windowsマシンだけでなく、Linuxにも当てはまります。