AMD APP SDK：抽象化レイヤーの計算（CAL）

前半では、AMD Intermediate Language（IL）テクノロジーについて説明しました。 タイトルから推測できるように、この記事では2番目のコンポーネントであるAMD Compute Abstraction Layer（CAL）について説明します。 これらの2つのテクノロジーは互いに切り離せません。一方を使用せずに他方を使用することは不可能です。 したがって、さらに理解するために、最初の部分に慣れることをお勧めします。

AMD GPUを使用してトップレベルで作業する際の主な側面を強調し、このテクノロジーの限界と、使用する際に起こりうる問題について説明します。 猫の下で誰が気にしてください。

導入する代わりに

私がAMD GPUのプログラミングを理解し始めたとき、彼らは私がこれに何を使うのか尋ねてきました。 「ATI CAL 」と答えた。 「はい、ATIは本当にCALです 」と私は答えました。
一般に、略語CALの発音はわかりませんが、人を困らせないように「O」で発音します。

簡潔にするために、最初の部分でカーネルによって記述されたプログラムを示します 。 カーネルとは、プログラムのソースコードと、GPUにロードされたコンパイル済みのバイナリコードの両方を意味します。 AMD CALを介してGPUで動作するプログラムの全文は提供しませんが、主な作業点について説明します。

• ドライバーの初期化
• サポートされているすべてのGPUに関する情報を取得する
• メモリの割り当てとコピー
• GPUでのカーネルのコンパイルとロード
• カーネル起動
• CPU同期

開始するには、AMD APP SDKの2つのヘッダーファイルが必要です。

• cal.h-ドライバーの主な機能について説明します。機能の先頭には「cal」 （aticalrt.dllライブラリ）が付いています
• calcl.h-テキストカーネルコンパイラの基本機能をバイナリコードに記述します。機能の先頭には「calcl」 （aticalcl.dllライブラリ）が付きます

ご覧のとおり、ランタイムAPIとドライバーAPIを備えたNvidia CUDAとは異なり、AMDではドライバーAPIのみが使用可能です。 したがって、アプリケーションの操作のために、適切なライブラリへのリンクを忘れないでください。

ほとんどの関数呼び出しは、CALresult型の値を返します。 合計11の戻りコードが使用可能です。 私たちにとって最も重要なのは、CAL_RESULT_OKというコードで、0に等しい（呼び出しが正常に完了したことを示します）。

行きましょう。

ドライバーの初期化

ルール番号1： GPUでの作業を開始する前に、次の呼び出しで手を洗ってドライバーを初期化します。

CALresult result = calInit(); 

ルール番号2： GPUで作業した後、ジョブを正しく完了するために自分ですすぐことを忘れないでください。 これは、次の呼び出しによって行われます。

 CALresult result = calShutdown(); 

これらの2つの呼び出しは常にペアにする必要があります。 プログラムにはそれらのいくつか（そのような呼び出しのペア）が存在する可能性がありますが、これらの呼び出し以外でGPUを使用しないでください。この動作はハードウェア例外を伴う場合があります 。

GPU情報の取得

サポートされている GPUの数を確認します（システム内のAMD GPUの総数よりも少ない場合があります）。

 unsigned int deviceCount = 0; CALresult result = calDeviceGetCount( &deviceCount ); 

この記事では、GPU識別子の使用場所を示しますが、識別子0の下でGPUを「使用」します。一般に、この識別子は0から（deviceCount-1）までの値を取ります。

GPUに関する情報をご覧ください。

 unsigned int deviceId = 0; //  GPU CALdeviceinfo deviceInfo; CALresult result = calDeviceGetInfo( &deviceInfo, deviceId ); CALdeviceattribs deviceAttribs; deviceAttribs.struct_size = sizeof( deviceAttribs ); CALresult result = calDeviceGetAttribs( &deviceAttribs, deviceId ); 

CALdeviceinfo構造で最も重要なことは、GPUチップ識別子です。 ここでは、デバイスカーネルISAと呼びます 。

 typedef struct CALdeviceinfoRec { CALtarget target; /**< Device Kernel ISA */ CALuint maxResource1DWidth; /**< Maximum resource 1D width */ CALuint maxResource2DWidth; /**< Maximum resource 2D width */ CALuint maxResource2DHeight; /**< Maximum resource 2D height */ } CALdeviceinfo; 

構造体の残りのフィールドは、このGPUに割り当てることができる2つの座標でのテクスチャメモリの最大サイズを決定します。

GPU属性を担当するCALdeviceattribs構造は、はるかに興味深いものです（構造体フィールドをいくつか紹介します）。

 typedef struct CALdeviceattribsRec { CALtarget target; /**< Asic identifier (  Device Kernel ISA) */ CALuint localRAM; /**<   GPU RAM   */ CALuint wavefrontSize; /**<  warp'a (      ) */ CALuint numberOfSIMD; /**<   */ CALboolean computeShader; /**<   Compute Shader */ CALuint pitch_alignment; /**<        calCreateRes */ /*   */ } CALdeviceattribs; 

ルール番号3： CALdeviceattribs.pitch_alignmentフィールドは、バイトではなくメモリ要素で測定されます。 メモリ要素は、8、16、または32ビットレジスタの1、2、または4コンポーネントベクトルです。

そして、CALdeviceinfo.targetフィールド（CALdeviceattribs.target）が取りうる値を詳しく見てみましょう：

 /** Device Kernel ISA */ typedef enum CALtargetEnum { CAL_TARGET_600, /**< R600 GPU ISA */ CAL_TARGET_610, /**< RV610 GPU ISA */ CAL_TARGET_630, /**< RV630 GPU ISA */ CAL_TARGET_670, /**< RV670 GPU ISA */ CAL_TARGET_7XX, /**< R700 class GPU ISA */ CAL_TARGET_770, /**< RV770 GPU ISA */ CAL_TARGET_710, /**< RV710 GPU ISA */ CAL_TARGET_730, /**< RV730 GPU ISA */ CAL_TARGET_CYPRESS, /**< CYPRESS GPU ISA */ CAL_TARGET_JUNIPER, /**< JUNIPER GPU ISA */ CAL_TARGET_REDWOOD, /**< REDWOOD GPU ISA */ CAL_TARGET_CEDAR, /**< CEDAR GPU ISA */ CAL_TARGET_RESERVED0, CAL_TARGET_RESERVED1, CAL_TARGET_WRESTLER, /**< WRESTLER GPU ISA */ CAL_TARGET_CAYMAN, /**< CAYMAN GPU ISA */ CAL_TARGET_RESERVED2, CAL_TARGET_BARTS, /**< BARTS GPU ISA */ } CALtarget; 

このフィールドは、GPUが構築されているチップを示していることがわかります。 したがって、AMD CALを使用して、GPUが世界で何と呼ばれているのか（Radeon HD 3850など）を正確に見つけることは不可能です。 ここにそのような便利な技術があります...しかし、例えば、Radeon HD 5750とRadeon HD 6750は実際には同じビデオカードであるということを観察するのは面白かったです！ メモリ操作の頻度はわずかに異なります（数パーセント以内）。

もう1つ注意してください。このリストにはEvergreen GPUがありません。これについては前半で説明しました。 私の推測では、EvergreenファミリGPUはサイプレスチップ（CAL_TARGET_CYPRESS）から始まると思われます。 以前のものは、新しい機能（循環シフト、操作フラグと64ビット操作のサポート）をサポートしない前世代のみです。

さらに作業を進めるには、GPUとやり取りするデバイス記述子（デバイス）を作成する必要があります。

 unsigned int deviceId = 0; //  GPU CALdevice device; CALresult result = calDeviceOpen( &device, deviceId ); CALcontext context; result = calCtxCreate( &context, device ); 

このGPUを使用してアプリケーション内で動作するには、コンテキストが必要です。 すべてのGPU作業は、このコンテキストを使用して行われます。 コンテキストを削除するとすぐに、割り当てられたすべてのリソースが解放されたと見なされ、GPU上のすべての不完全なタスクが強制的に完了します。

デバイスでの作業を終えた後、ペアの呼び出しを忘れないでください。

 calCtxDestroy( context ); calDeviceClose( device ); 

呼び出しはこの順序で実行する必要があります。そうしないと、 ハードウェア例外が発生します。

それで、デバイスとそのコンテキストを作成しました。

メモリ割り当て

メモリを操作するには、 リソースを割り当てる必要があります。 ドキュメントによると、リソースはローカルメモリ（ローカルメモリ=ストリームプロセッサメモリ）およびリモートメモリ（リモートメモリ=システムメモリ）に配置できます。 私が理解しているように、リモートメモリはRAMに過ぎず、ローカルメモリはGPU自体のメモリです。

ローカルメモリがあるのにリモートメモリが必要なのはなぜですか？ まず、複数のGPU間で同じメモリを共有する必要があります。 つまり、リモートメモリを一度割り当てて、複数のGPUから操作できます。 第二に、すべてのGPUがメモリへの直接アクセスをサポートしているわけではありません（以下の「メモリへの直接アクセスの取得」を参照）。

 CALresource resource; unsigned int memoryWidth; unsigned int memoryHight; CALformat memoryFormat; unsigned int flags; //      // 1D  CALresult result = calResAllocRemote1D( &resource, &device, 1, memoryWidth, memoryFormat, flags ); /*         GPU,    -     ,   -      (1   ) */ // 2D  CALresult result = calResAllocRemote2D( &resource, &device, 1, memoryWidth, memoryHeight, memoryFormat, flags ); //      // 1D  CALresult result = calResAllocLocal1D( &resource, device, memoryWidth, memoryFormat, flags ); /*  ,       ,       */ // 2D  CALresult result = calResAllocLocal2D( &resource, device, memoryWidth, memoryHeight, memoryFormat, flags ); 

割り当てられたリソースの幅と高さは、メモリ要素で測定されます。
メモリー要素自体は、memoryFormatパラメーターによって記述されます。

 //  ,         /** Data format representation */ typedef enum CALformatEnum { CAL_FORMAT_UNORM_INT8_1, /**< 1 component, normalized unsigned 8-bit integer value per component */ CAL_FORMAT_UNORM_INT8_4, /**< 4 component, normalized unsigned 8-bit integer value per component */ CAL_FORMAT_UNORM_INT32_1, /**< 1 component, normalized unsigned 32-bit integer value per component */ CAL_FORMAT_UNORM_INT32_4, /**< 4 component, normalized unsigned 32-bit integer value per component */ CAL_FORMAT_SNORM_INT8_1, /**< 1 component, normalized signed 8-bit integer value per component */ CAL_FORMAT_SNORM_INT8_4, /**< 4 component, normalized signed 8-bit integer value per component */ CAL_FORMAT_SNORM_INT32_1, /**< 1 component, normalized signed 32-bit integer value per component */ CAL_FORMAT_SNORM_INT32_4, /**< 4 component, normalized signed 32-bit integer value per component */ CAL_FORMAT_UNSIGNED_INT8_1, /**< 1 component, unnormalized unsigned 8-bit integer value per component */ CAL_FORMAT_UNSIGNED_INT8_4, /**< 4 component, unnormalized unsigned 8-bit integer value per component */ CAL_FORMAT_SIGNED_INT8_1, /**< 1 component, unnormalized signed 8-bit integer value per component */ CAL_FORMAT_SIGNED_INT8_4, /**< 4 component, unnormalized signed 8-bit integer value per component */ CAL_FORMAT_UNSIGNED_INT32_1, /**< 1 component, unnormalized unsigned 32-bit integer value per component */ CAL_FORMAT_UNSIGNED_INT32_4, /**< 4 component, unnormalized unsigned 32-bit integer value per component */ CAL_FORMAT_SIGNED_INT32_1, /**< 1 component, unnormalized signed 32-bit integer value per component */ CAL_FORMAT_SIGNED_INT32_4, /**< 4 component, unnormalized signed 32-bit integer value per component */ CAL_FORMAT_UNORM_SHORT_565, /**< 3 component, normalized 5-6-5 RGB image. */ CAL_FORMAT_UNORM_SHORT_555, /**< 4 component, normalized x-5-5-5 xRGB image */ CAL_FORMAT_UNORM_INT10_3, /**< 4 component, normalized x-10-10-10 xRGB */ CAL_FORMAT_FLOAT32_1, /**< A 1 component, 32-bit float value per component */ CAL_FORMAT_FLOAT32_4, /**< A 4 component, 32-bit float value per component */ CAL_FORMAT_FLOAT64_1, /**< A 1 component, 64-bit float value per component */ CAL_FORMAT_FLOAT64_2, /**< A 2 component, 64-bit float value per component */ } CALformat; 

古いビデオカード（エバーグリーンではない）での64ビット操作がfloat型のデータでのみ実行できるのは残念です...

ルール番号4：要素フォーマットは、GPUがこの要素にあるデータを解釈する方法のみを説明します。 物理的には、要素は常に16バイトのメモリを占有します。

これは、最初の部分でリソースを次のように説明したことを思い出すと理解できます。

 dcl_resource_id(0)_type(2d,unnorm)_fmtx(uint)_fmty(uint)_fmtz(uint)_fmtw(uint) 

また、AMD IL言語仕様によると、fmtx-fmtw値が必要です。 つまり、次のコード（このようなものは、1コンポーネントベクトル型の要素を持つテクスチャーを記述できます）は正しくありません。

 dcl_resource_id(0)_type(2d,unnorm)_fmtx(uint) 

ルール番号5：カーネルで宣言するタイプを遵守し、リソースを割り当てるとき。 それらが一致しない場合、リソースをカーネルにバインドできません。

ルール番号6：定数メモリの場合、要素タイプは常にfloatタイプでなければなりません。

なぜこれが行われるのかは定かではありません。なぜなら、定数メモリから整数値をロードできるからです（この例ではこれを実行しています）。

メモリを割り当てるときに必要なフラグについて、もう少し説明します。

 /** CAL resource allocation flags **/ typedef enum CALresallocflagsEnum { CAL_RESALLOC_GLOBAL_BUFFER = 1, /**< used for global import/export buffer */ CAL_RESALLOC_CACHEABLE = 2, /**< cacheable memory? */ } CALresallocflags; 

セカンドフラグを使用したことはありません。それが有利な場合はわかりません。 そして、著者自身のコメントにある疑問符から判断すると、彼らも知らない（微笑）。
ただし、グローバルバッファを割り当てるには最初のフラグが必要です（ "g []"）。

次に、理論を実際に適用します。 前の記事で説明した例を念頭に置いて、カーネルの起動パラメーターも設定します。

 unsigned int blocks = 4; //  4  unsigned int threads = 64; //  64    //    cb0 CALresource constantResource; CALresult result = calResAllocLocal1D( &constantResource, device, 1, CAL_FORMAT_FLOAT32_4, 0 ); //    i0 CALresource textureResource; result = calResAllocLocal2D( &textureResource, device, threads, blocks, CAL_FORMAT_UNSIGNED_INT32_4, 0 ); //    g[] CALresource globalResource; result = calResAllocLocal1D( &globalResource, device, threads * blocks, CAL_FORMAT_UNSIGNED_INT32_4, CAL_RESALLOC_GLOBAL_BUFFER ); 

リソースが不要になったら、リソースを解放する必要があります。

 calResFree( constantResource ); calResFree( textureResource ); calResFree( globalResource ); 

コピーメモリ

メモリに直接アクセスする

GPUがメモリのマッピング（メモリアドレスをプロセスアドレス空間にマッピング）をサポートしている場合、他のメモリと同様に、このメモリへのポインタを取得して操作できます。

 unsigned int pitch; unsigned char* mappedPointer; CALresult result = calResMap( (CALvoid**)&mappedPointer, &pitch, resource, 0 ); //    ,   ,    

そして、メモリの操作が終了したら、ポインターを解放する必要があります。

 CALresult result = calResUnmap( resource ); 

ルール番号7： GPUメモリを使用する場合、 アライメントを考慮する必要があることを常に忘れないでください。 この調整は、可変ピッチによって特徴付けられます。

ルール番号8：ピッチはバイト単位ではなく要素単位で測定されます。

なぜこのアライメントについて知る必要があるのですか？ 実際、RAMとは異なり、GPUメモリは常に連続した領域ではありません。 これは、テクスチャを操作する場合に特に当てはまります。 例で言われたことを説明しましょう：100x100要素のテクスチャを操作したい場合、calResMap（）関数が200に等しいピッチの値を返した場合、これは実際にGPUが200x100のテクスチャで動作し、最初の100だけが各テクスチャラインで考慮されることを意味します要素。

ピッチ値に基づくGPUメモリへのコピーは、次のように整理できます。

 unsigned int pitch; unsigned char* mappedPointer; unsigned char* dataBuffer; CALresult result = calResMap( (CALvoid**)&mappedPointer, &pitch, resource, 0 ); unsigned int width; unsigned int height; unsigned int elementSize = 16; if( pitch > width ) { for( uint index = 0; index < height; ++index ) { memcpy( mappedPointer + index * pitch * elementSize, dataBuffer + index * width * elementSize, width * elementSize ); } } else { memcpy( mappedPointer, dataBuffer, width * height * elementSize ); } 

当然、dataBufferのデータは、要素のタイプを考慮して準備する必要があります。 ただし、要素のサイズは常に16バイトであることに注意してください。
つまり、形式CAL_FORMAT_UNSIGNED_INT16_2の要素の場合、メモリ内のバイト表現は次のようになります。

 // w - word, 16  // wi.j - i- word, j-  // x -  [ w0.0 | w0.1 | x | x ][ w1.0 | w1.1 | x | x ][ x | x | x | x ][ x | x | x | x ] 

リソース間でデータをコピーする

データはリソース間で直接コピーされるのではなく、コンテキストにマップされた値間でコピーされます。 コピー操作は非同期であるため、コピー操作の完了を確認するために、CALeventタイプのシステムオブジェクトが使用されます。

 CALresource inputResource; CALresource outputResource; CALmem inputResourceMem; CALmem outputResourceMem; //     CALresult result = calCtxGetMem( &inputResourceMem, context, inputResource ); result = calCtxGetMem( &outputResourceMem, context, outputResource ); //   CALevent syncEvent; result = calMemCopy( &syncEvent, context, inputResourceMem, outputResourceMem, 0 ); //    ,   ,    //     while( calCtxIsEventDone( context, syncEvent ) == CAL_RESULT_PENDING ); 

GPUでのカーネルのコンパイルとロード

「針でのコシェイの死、卵の針、アヒルの卵、うさぎのアヒル、胸のうさぎ...」

カーネルをGPUにロードするプロセスは次のように説明できます：ソース（txt）はオブジェクト（オブジェクト）にコンパイルされ、1つ以上のオブジェクトはイメージ（イメージ）にリンクされ、GPUモジュール（モジュール）にロードされます。カーネルエントリポイントへのポインター（このポインターにより、実行のためにカーネルを開始できます）。

そして今、これはどのように実装されていますか：

 const char* kernel; //       // ,   GPU  unsigned int deviceId = 0; //  GPU CALdeviceinfo deviceInfo; CALresult result = calDeviceGetInfo( &deviceInfo, deviceId ); //   CALobject obj; result = calclCompile( &obj, CAL_LANGUAGE_IL, kernel, deviceInfo.target ); //     CALimage image; result = calclLink( &image, &obj, 1 ); //   -  ,  -   //     ,   result = calclFreeObject( obj ); //     CALmodule module; result = calModuleLoad( &module, context, image ); //      CALfunc function; result = calModuleGetEntry( &function, context, module, "main" ); 

ルール番号9：リンク後の関数は「メイン」関数のみであるため、カーネルへのエントリポイントは常に1です。

つまり、Nvidia CUDAとは異なり、AMD CALコアには1つのグローバル関数「メイン」しか存在できません。

お気づきかもしれませんが、コンパイラーはILで記述されたソースコードのみを処理できます。

画像をモジュールにロードすることは、選択したGPUコンテキストに画像をロードする必要があるという事実によって説明されます。 したがって、説明されているコンパイルプロセスは各GPUで実行する必要があります（2が同じGPUの場合を除きます：一度コンパイルしてリンクするだけで十分ですが、それでも各カードのモジュールにイメージをロードする必要があります）。

複数のオブジェクト所有者をリンクする可能性に注意を喚起したいと思います。 この機会は誰かに役立つかもしれません。 私の意見では、同じサブ機能の異なる実装の場合に適用できます。AMDILには#ifdefのようなプリプロセッサディレクティブがないため、これらの実装は異なるオブジェクトに移動できます。

GPUでのカーネルの実行が完了したら、適切なリソースを解放する必要があります。

 CALresult result = calclFreeImage( image ); result = calModuleUnload( context, module ); 

カーネル起動

カーネル起動オプションの設定

そのため、リソース、フルメモリ、およびコンパイルされたカーネルを割り当てました。 リソースを特定のコアにバインドして実行するだけです。 これを行うには、カーネルから起動パラメーターを取得し、リソースをコンテキストにマップする必要があります。

 const char* memoryName; //    ,       //      CALname kernelParameter; CALresult result = calModuleGetName( &kernelParameter, context, module, memoryName ); //     CALmem resourceMem; result = calCtxGetMem( &resourceMem, context, resource ); //         result = calCtxSetMem( context, kernelParameter, resourceMem ); 

そして今、私たちは例の一部としてこれを行います：

 CALname kernelParameter; CALmem resourceMem; //      CALresult result = calModuleGetName( &kernelParameter, context, module, "cb0" ); result = calCtxGetMem( &resourceMem, context, constantResource ); result = calCtxSetMem( context, kernelParameter, resourceMem ); //      result = calModuleGetName( &kernelParameter, context, module, "i0" ); result = calCtxGetMem( &resourceMem, context, textureResource ); result = calCtxSetMem( context, kernelParameter, resourceMem ); //      result = calModuleGetName( &kernelParameter, context, module, "g[]" ); result = calCtxGetMem( &resourceMem, context, globalResource ); result = calCtxSetMem( context, kernelParameter, resourceMem ); 

GPUでのカーネルの実行が完了したら、カーネルからリソースを解放する必要があります。 これは次のように実行できます。

 CALname kernelParameter; //      CALresult result = calModuleGetName( &kernelParameter, context, module, "cb0" ); result = calCtxSetMem( context, kernelParameter, 0 ); //      result = calModuleGetName( &kernelParameter, context, module, "i0" ); result = calCtxSetMem( context, kernelParameter, 0 ); //      result = calModuleGetName( &kernelParameter, context, module, "g[]" ); result = calCtxSetMem( context, kernelParameter, 0 ); 

これで、カーネルはデータを取得する場所を認識します。 小規模の場合はそのままです。

カーネル起動

覚えているように、最初の部分でPSシェーダーとCSシェーダーに言及しました。 後者がGPU属性でサポートされているかどうかを確認できます（上記を参照）。

PSローンチ：

 unsigned int blocks = 4; //  4  unsigned int threads = 64; //  64    CALdomain domain; domain.x = 0; domain.y = 0; domain.width = threads; domain.height = blocks; CALevent syncEvent; CALresult result = calCtxRunProgram( &syncEvent, context, function, &domain ); while( calCtxIsEventDone( context, syncEvent ) == CAL_RESULT_PENDING ); 

ここで、関数は、GPUにカーネルをロードする段階で取得したカーネルエントリポイントです（上記の「 GPUにカーネルをコンパイルしてロードする」を参照）。

ルール番号10： PSは内部のスレッドの値を知らないため、メモリを介して送信する必要があります（この例では、これは定数メモリを介して行われます）。

CSローンチ：

 unsigned int blocks = 4; //  4  unsigned int threads = 64; //  64    CALprogramGrid programGrid; programGrid.func = function; programGrid.flags = 0; programGrid.gridBlock.width = threads; programGrid.gridBlock.height = 1; programGrid.gridBlock.depth = 1; programGrid.gridSize.width = blocks; programGrid.gridSize.height = 1; programGrid.gridSize.depth = 1; CALevent syncEvent; CALresult result = calCtxRunProgramGrid( &syncEvent, context, &programGrid ); while( calCtxIsEventDone( context, syncEvent ) == CAL_RESULT_PENDING ); 

ルール番号11：スレッドの値は、カーネルのソースコードで壊れた値に対応する必要があります。 カーネルはどのような場合でも起動されますが、メモリの制限を超えることができます（カーネルで宣言されたよりも少ないスレッドの起動）、またはすべての入力データが処理されるわけではありません（カーネルで宣言されたよりも多くのスレッドの起動）。

できた！ カーネルが起動し、すべてがうまくいった場合、処理されたデータは出力メモリにあります（ "g []"）。 それらをコピーアウトするためだけに残ります（上記の「メモリのコピー」セクションを参照）。

便利な機能

日常生活で役立つかもしれないいくつかの機能に言及するだけです。

 CALresult result; //     CALdevicestatus status; result = calDeviceGetStatus( &status, device ); //      GPU  result = calCtxFlush( context ); //       ( ) CALfunc function; CALfuncInfo functionInfo; result = calModuleGetFuncInfo( &functionInfo, context, module, function ); /*      ,       (     ,      ) */ //        aticalrt.dll const char* errorString = calGetErrorString(); //        aticalcl.dll () const char* errorString = calclGetErrorString(); 

クロススレッド同期

Nvidia CUDAとは異なり、異なるスレッドのGPUを使用している場合、コンテキストで追加のアクションを実行する必要はありません。 しかし、まだいくつかの制限があります。

ルール番号12： CALコンパイラのすべての機能はスレッドセーフではありません 。 1つのアプリケーション内では、一度に1つのスレッドのみがコンパイラーで動作できます。

ルール13：特定のコンテキスト/デバイス記述子（コンテキスト/デバイス）で動作するメインCALライブラリのすべての機能はスレッドセーフです。 他のすべての関数はスレッドセーフではありません 。

ルール番号14：特定のコンテキストで動作できるアプリケーションスレッドは一度に1つだけです。

おわりに

AMD CALおよびAMD ILテクノロジーを最もアクセスしやすい方法で記述しようとしたため、誰でもAMD GPU向けのシンプルなアプリケーションをほぼゼロから作成できます。主なものは、常に1つの黄金律を覚えておくことです：RTFM！

あなたがそれを読むのが面白いと思ってください。

知人向けリンク

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