AMD APP SDK：中間言語（IL）

ATI Stream SDKはAMD Accelerated Parallel Processing（APP）SDKに名前が変更され、OpenCLはBrook +を計算するためのメインプログラミング言語GPGPUを置き換えました。 ただし、AMD Compute Abstraction Layer（CAL）/ Intermediate Language（IL）という別のテクノロジを使用して、ATIカードのコードを記述することができることを理解している人はあまりいません。 CALテクノロジは、GPUと相互作用してCPU上で実行されるコードを作成するように設計されていますが、 ILテクノロジを使用すると、GPUで直接実行されるコードを作成できます。



この記事では、 ILテクノロジー、その範囲、制限、およびOpenCLに対する利点を検証します。 猫の下で誰が気にしてください。

はじめに

はじめに、Nvidia CUDA SDKとの比較を次に示します。

1. 高レベルプログラミング言語：
   
   
   • Nvidia：CUDA C ++拡張機能
   • AMD：OpenCL 1.1またはCompute Abstraction Layer（CAL）
   
   
   
2. 低レベルプログラミング言語（擬似アセンブラー*）：
   
   
   • Nvidia：並列スレッド実行（PTX）
   • AMD：中間言語（IL）
   
   
   
3. 「GPU価格」に対する「1秒あたりのオウムの数」（たとえば、1秒あたりにソートされるハッシュの数）の比率：
   
   
   • NVIDIA：x
   • AMD：CAL / ILバンドルを使用する場合、約2倍
   
   
   

*は、言語はアセンブラーに似ていますが、それでもコンパイラーによって最適化され、GPUごとに異なるコードに変換されることを意味します



どのようにしてこのようなパフォーマンスの向上を得ることができますか？

AMD GPUアーキテクチャの機能

Nvidia PTX仕様とAMD IL仕様を注意深く読むと、Nvidia PTXのオペランドは単一コンポーネントベクトル（つまり、単純なnビットレジスタ）であり、AMD ILオペランドはnビットレジスタの4コンポーネントベクトルであることがわかります。 。 両方の言語で乗算の操作を考慮すると、これはより明確になります。

# Nvidia PTX mul.u32 %r0, %r1, %r2 # AMD IL umul r0.xyzw, r1.xyzw, r2.xyzw
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、1回（ほぼ1回）の操作で、AMD GPUは最大4つのnビットレジスタを変更でき、Nvidia GPUは1つのnビットレジスタのみを変更できます（1つのGPUストリーム内を意味します）。 ただし、OpenCLでは、マルチコンポーネントベクターを宣言して操作することもできます。 次に、違いは何ですか、なぜこのILはまったく必要ですか？

OpenCLとは異なり

そして、すべての違いは、AMD APP SDKの開発者がOpenCL仕様に従って書かれたコードをAMD ILで書かれたコードに変換するコンパイラーを作成するのが困難または技術的に不可能だったという点で、ひどいものです。 したがって、OpenCL標準のサポートに関する制限 ：

• OpenCL 1.0は、ほぼRadeon HD 4000シリーズからサポートされています（ベータレベルサポート）（画像オブジェクト、つまりテクスチャメモリのサポートがない場合があります）。
• Radeon HD 5000シリーズを中心にOpenCL 1.1がサポートされています
• OpenCL 1.2はRadeon HD 7000以降でサポートされていますが、このバージョンの標準をサポートするSDKはまだリリースされていません

AMD ILを使用すると、GPGPUコンピューティングにRadeon HD 3000シリーズやRadeon HD 2000シリーズのカードを使用できることに注意してください！ （完全に正確に言うと、これらはR600、RV610、RV630、およびRV670チップに基づくGPUです）

さらに、簡潔にするために、Radeon HD 5000シリーズ以降のすべてのGPUをEvergreen GPU（これはRadeon HD 5700チップ）として指定します。これらのカードでのみ興味深い操作がサポートされているためです。



AMD ILのコード作成の原則の説明に移る前に、注意を喚起したいと思います。

メモリを操作する機能

前述したように、AMD GPUはnビットレジスタの4つのコンポーネントベクトルで動作します。ここで、n = 32です（さらに64ビットレジスタの動作方法について）。 これにより、メモリに大きな制限が課されます。メモリは16バイトの倍数でのみ割り当てることができます。 メロンをメモリからロードするとき、これらの16バイトが再び最小伝送容量になることを覚えておく必要があります。 つまり、メモリが各1バイトの4つの成分ベクトル（char4）、各4バイトの4つの成分ベクトル（int4）で構成されることを示すかどうかはまったく関係ありません。結果は1つです。メモリから、1つの交換操作が読み込まれます16バイト。



さらに、Nvidia GPUとは異なり、AMD GPUはグローバル領域にローカルメモリを割り当てます（これは非常に遅いデータ転送速度を意味します）ので、ローカルメモリを忘れてください。 レジスタとグローバルメモリを使用します。



そして最後に：Nvidia GPUとは異なり、読み取りと書き込みに機能するグローバルメモリは1つのみ（以下「g []」）、テクスチャメモリにはさまざまなソースがあります（以下「i0」、「i1」 」など）とコンスタントメモリ（以下「cb0」、「cb1」など）は読み取り専用です。

定数メモリの機能は、すべてのGPUスレッドが1つのデータ領域にアクセスするときにキャッシュが存在することです（レジスタと同じくらい速く動作します）。

テクスチャメモリの機能は、読み取りキャッシュ（メモリが1つのストリームプロセッサにつき8 KBの場合）と、実際の座標でメモリにアクセスする機能です。 テクスチャの境界を超える場合、境界要素を読み取るか、ループして最初に読み取ることができます（座標はテクスチャの幅/長さを法として取得されます）。



そして今、楽しい部分のために：

AMD ILのコード構造

レジスタを操作する

まず、操作中のレジスタ間の交換がどのように発生するかについての簡単な説明。

ベクトルコンポーネントの代わりの出力レジスタには、コンポーネントの名前または記号「_」が含まれる場合があります。これは、このコンポーネントが変更されないことを意味します。

各コンポーネントの代わりの各入力レジスタには、「0」または「1」の4つのコンポーネントの名前を含めることができます。 これは、入力レジスタコンポーネントまたは定数のいずれかが、出力レジスタの対応するコンポーネントの操作に関与することを意味します。 例を挙げて説明します：

 # r0.x = r1.z # r0.y = r1.w # r0.w = r1.y mov r0.xy_w, r1.zwyy # r0.y = 1 # r0.z = 0 mov r0._yz_, r1.x100
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

シェーダー

AMD GPUのコードは、シェーダーの形式で発行されます。 コンピューターシェーダー（コンピューターシェーダー、CS）とピクセルシェーダー（ピクセルシェーダー、PS）の両方を実行することができます。 ただし、CSはRadeon HD 4000シリーズからのみサポートされます。 さらに、それらの速度はほぼ同じです。



GPUで同時に起動されるスレッドの数は、起動パラメーター（ブロック数、ブロックごとのスレッド数）によって決定されることが知られています。 GPUの各マルチプロセッサ（8個から）は、実行のために1ブロックを取ります。 次に、ブロックごとに要求されたスレッド数を断片に分割し（ワープ、32の倍数）、各スレッドプロセッサに実行用の1ワープを与えます。 したがって、同時に実行されるスレッドの実際の数は次のとおりです。



<multiprocessors_count> * <stream_processors_per_multiprocessor_count> * <warp_size>



そのため、最速の作業を行うには、1つのワープのフレームワーク内で、スレッドが分岐せずに同じ操作を実行する必要があります。 その後、この操作は一度に実行されます。



真空中の球形馬を考慮しないために、単純なタスクを考慮します：各スレッドはブロック内のローカル識別子（32ビット）、グローバル識別子（32ビット）を計算し、命令メモリとデータメモリから定数（64ビット）を読み取り、読み取りテクスチャの要素（128ビット）。 彼はこれをすべて出力メモリに書き込みます。各スレッドにはこれに256ビットが必要です。

注：テクスチャの各行には、1ブロックのフローのデータが含まれています。

ピクセルシェーダー

 il_ps_2_0 ;   (cb0): ; cb0[0].x -   ; cb0[0].y -   ; cb0[0].zw -  dcl_cb cb0[1] ;     (i0) ;   -  (   ),  (     float  0  1) ;          (   uint) dcl_resource_id(0)_type(2d,unnorm)_fmtx(uint)_fmty(uint)_fmtz(uint)_fmtw(uint) ;       dcl_input_position_interp(linear_noperspective) vWinCoord0.xy__ ;   (g[]) ; ,     dcl_literal l0, 0xFFFFFFFF, 0xABCDEF01, 0x3F000000, 2 ;         ; r0.x -   x  i0   (float) (     ) ; r0.y -   y  i0   (float) (   ) ftoi r0.xyzw, vWinCoord0.xyxy ;  r0.z -    (uint) umad r0.__z_, r0.wwww, cb0[0].yyyy, r0.zzzz ;       ftoi r1.x___, vWinCoord0.xxxx mov r1._y__, r0.zzzz mov r1.__z_, cb[0].xxxx mov r1.___w, l0.yyyy ;      g[] umul r0.__z_, r0.zzzz, l0.wwww ;       mov g[r0.z+0].xyzw, r1.xyzw ;     i0 ;     float   0.5 itof r0.xy__, r0.xyyy add r0.xy__, r0.xyyy, l0.zzzz sample_resource(0)_sampler(0)_aoffimmi(0,0,0) r1, r0 ; sample_resource(0) -   i0 ; _sampler(0) -   sampler'a #0 ; _aoffimmi(0,0,0) -   x, y, z ;        ,  _aoffimmi(1,0,0);   - _aoffimmi(0,1,0) ;       mov g[r0.z+1].xyzw, r1.xyzw ;     endmain ;    end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

計算シェーダー

すべての違いはフロー識別子の計算のみで、残りは同じです。

 il_cs_2_0 dcl_num_thread_per_group 64 ;   (cb0): ; cb0[0].x -   ; cb0[0].yzw -  dcl_cb cb0[1] ;     (i0) ;   -  (   ),  (     float  0  1) ;          (   uint) dcl_resource_id(0)_type(2d,unnorm)_fmtx(uint)_fmty(uint)_fmtz(uint)_fmtw(uint) ;   (g[]) ; ,     dcl_literal l0, 0xFFFFFFFF, 0xABCDEF01, 0x3F000000, 2 ;   mov r0._y__, vThreadGrpIDFlat.xxxx ;     mov r0.x___, vTidInGrpFlat.xxxx ;    mov r0.__z_, vAbsTidFlat.xxxx ;       mov r1.x___, vTidInGrpFlat.xxxx mov r1._y__, vAbsTidFlat.xxxx mov r1.__z_, cb[0].xxxx mov r1.___w, l0.yyyy ;      g[] umul r0.__z_, r0.zzzz, l0.wwww ;       mov g[r0.z+0].xyzw, r1.xyzw ;     i0 ;     float   0.5 itof r0.xy__, r0.xyyy add r0.xy__, r0.xyyy, l0.zzzz sample_resource(0)_sampler(0)_aoffimmi(0,0,0) r1, r0 ; sample_resource(0) -   i0 ; _sampler(0) -   sampler'a #0 ; _aoffimmi(0,0,0) -   x, y, z ;        ,  _aoffimmi(1,0,0);   - _aoffimmi(0,1,0) ;       mov g[r0.z+1].xyzw, r1.xyzw ;     endmain ;    end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

シェーダーの違い

さまざまなカードでのサポートに加えて、シェーダーの主な違いは、ブロックごとに起動されるスレッドの数の格納場所です。 PSの場合、この値はメモリに保存できますが、CSの場合、この値はコードにパンチする必要があります。 さらに、CSはフロー識別子を計算するのが簡単です。

おわりに

この記事では、GPU自体で実行するためにAMD ILで簡単なコードを記述する方法を説明しようとしました。 結論として、作業速度の最適化に関するいくつかの言葉：

• アセンブラー固有の最適化手法（定数による演算の事前計算、独立した演算の順列）を適用しようとしないでください。 これはまだ擬似アセンブラであることを忘れないでください。コンパイラが最適化を行います。 アルゴリズムについてよく考えてください。
• できるだけ多くのデータをカードにアップロードします。 ベクトルの4つのコンポーネントすべての32ビットをすべて使用することをお勧めします。
• 入力データに対して同じタイプの計算（ハッシュ計算など）がある場合、操作のコンポーネントの数を試してみる価値があります。r0.x___がより高速に動作する場合があり、r0.xy ___およびr0.xyzwが動作する場合があります。
• AMDは、ブロック内のスレッドの数は<warp_size>の倍数にでき、GPUは正しく動作すると主張していますが、実際はそうではありません。 実際には、<warp_size> = 32または64のみが表示され、GPUはブロック内のスレッド数が<warp_size>に等しい場合にのみ正しく機能しました。 さらに、Radeon HD 4650は、ブロック内の32スレッドで起動すると（および技術データによると、このカードの<warp_size> = 32）、アルゴリズムの1つで間違ったデータを提供しましたが、ブロック内に64スレッドのバンで動作しました。 結論：ブロックごとに64スレッドのみでアルゴリズムを実行します（ブロックの数はすでに変更可能です）。
• Evergreen GPUはいくつかのクールな機能をサポートしています：循環シフト、オーバーフローフラグのサポート、64ビット操作のサポート（このために2つのコンポーネントが予約されています）。 残念ながら、Evergreenよりも若い家族のGPUは、これらすべてのバンをサポートしていません。 誰かが64ビット操作を記述する方法を教えてくれたら、ありがたいです。

データをカードに転送し、そこからデータを収集する方法については、AMD Compute Abstraction Layer（CAL）に関する第2部で説明します。

知人向けリンク

• AMD Accelerated Parallel Processing SDK
• AMD中間言語（IL）
• AMD Compute Abstraction Layer（CAL）