パフォーマンスの最適化

データベース分析のようなアプリケーションでは、アクセラレーション デバイスで使用可能なグローバル デバイス メモリよりも大きなデータ セットが使用され、データ全体をブロック単位で転送して処理する必要があります。これらのアプリケーションで優れたパフォーマンスを達成するには、データ転送と計算をオーバーラップさせる手法が必要となります。

この例は、GitHub の Vitis Accelerated Examples の host カテゴリにある overlap 例からの vadd カーネルのものです。この例は、アプリケーションでホスト (CPU) と FPGA の計算をオーバーラップさせる手法を示します。カーネルは 2 つの配列をまとめて追加し、出力に書き込んでいます。この例では、ホストで実行する必要のあるタスクは次の 4 つです。

1. バッファー a の書き込み (Wa)
2. バッファー b の書き込み (Wb)
3. vadd カーネルの実行
4. バッファー c の読み出し (Rc)

データ転送の最適化をせずに単純な順番どおりのコマンド キューを使用すると、実行タイムライン全体のトレースは次のようになります。

順不同コマンド キューを使用すると、次の図に示すように、データ転送とカーネル実行をオーバーラップできます。この例のホスト コードでは、カーネルが 1 セットのバッファーを処理している間に、ホストでもう 1 つのバッファーのセットを処理できるように、すべてのバッファーにダブル バッファリングが使用されます。

OpenCL event オブジェクトを使用すると、複雑な操作依存を簡単に設定して、ホスト スレッドとデバイス動作を同期できます。イベントは、操作のステータスを調べるための OpenCL オブジェクトです。イベント オブジェクトは、read、write、およびメモリ オブジェクトの copy コマンドで作成されるか、clCreateUserEvent を使用して作成されたユーザー イベントです。

これらのコマンドで返されるイベントをクエリすることにより、操作が完了したかどうかを確認できます。次の図の矢印は、最適なパフォーマンスを達成するために、イベント トリガーをどのように設定できるかを示しています。

例では、ホスト コード (host.cpp) は、ループ内の 4 つのタスクをエン キューしてデータ セット全体を処理します。また、各タスクのデータ依存が満たされるように、異なるタスク間のイベント同期を設定します。ダブル バッファリングは、異なるメモリ オブジェクト値を clEnqueueMigrateMemObjects API に渡すことにより設定します。イベント同期は、各 API 呼び出しがほかのイベントを待ち、その API が終了してからそれ自身のイベントをトリガーするようにすると達成できます。

次に示す [Application Timeline] ビューでは、計算ユニット vadd_1 が継続的に実行されており、データ転送時間は完全に隠されています。

メモリ バッファーの割り当ておよび割り当て解除により、DDR コントローラーでメモリが分割されることがあります。これにより、計算ユニットが論理的には並列実行できるはずなのに、最適なパフォーマンスが得られない可能性があります。

この問題は、異なる計算ユニットに対して複数の pthread が使用されており、スレッドでカーネルがエンキューされるたびに異なるサイズのデバイス バッファーが多数割り当てられ、解放される場合によく発生します。この場合、タイムライン トレースでカーネル実行間にギャップが表示され、プロセスがスリープ状態になっているように見えます。

ランタイムで割り当てられる各バッファーは、ハードウェアで連続している必要があります。大型メモリの場合、多数のバッファーの割り当ておよび割り当て解除が発生すると、その空間が空くのを待機する時間が長くなることがあります。これは、デバイス バッファーを割り当て、カーネルの異なるエンキュー間で再利用すると回避できます。

次の図に、2 つの順序どおりのコマンド キュー (CQ0 および CQ1) の例を示します。スケジューラは各キューからのコマンドを順序どおりに実行しますが、CQ0 および CQ1 からのコマンドはどの順序でも取り出すことができます。必要な場合は、CQ0 および CQ1 間の同期を管理する必要があります。

次は、concurrent_kernel_execution_c 例の host.cpp からのコードで、複数の順序どおりのコマンド キューを設定し、各キューにコマンドをエンキューしています。

   OCL_CHECK(
        err,
        cl::CommandQueue ooo_queue(context,
                                   device,
                                   CL_QUEUE_PROFILING_ENABLE |
                                       CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE,
                                   &err));
...
    printf("[OOO Queue]: Enqueueing scale kernel\n");
    OCL_CHECK(
        err,
        err = ooo_queue.enqueueTask(
            kernel_mscale,nullptr,&ooo_events[0]));
    set_callback(ooo_events[0], "scale");
...
    // This is an out of order queue, events can be executed in any order. Since
    // this call depends on the results of the previous call we must pass the
    // event object from the previous call to this kernel's event wait list.
    printf("[OOO Queue]: Enqueueing addition kernel (Depends on scale)\n");
    kernel_wait_events.resize(0);
    kernel_wait_events.push_back(ooo_events[0]);
    OCL_CHECK(err,
              err = ooo_queue.enqueueTask(
                  kernel_madd,
                  &kernel_wait_events, // Event from previous call
                  &ooo_events[1]));
    set_callback(ooo_events[1], "addition");
...
    // This call does not depend on previous calls so we are passing nullptr
    // into the event wait list. The runtime should schedule this kernel in
    // parallel to the previous calls.
    printf("[OOO Queue]: Enqueueing matrix multiplication kernel\n");
    OCL_CHECK(err,
              err = ooo_queue.enqueueTask(
                  kernel_mmult,
                  nullptr,
                  &ooo_events[2]));
    set_callback(ooo_events[2], "matrix multiplication");

次の図に、1 つの順不同コマンド キューの例を示します。スケジューラは、キューからのコマンドをどの順序でも実行できます。必要に応じて、ユーザーがイベントの依存性と同期を手動で定義する必要があります。

次は、concurrent_kernel_execution_c 例の host.cpp からのコードで、1 つの順不同コマンド キューを設定し、必要に応じてコマンドをエンキューしています。

    OCL_CHECK(
        err,
        cl::CommandQueue ooo_queue(context,
                                   device,
                                   CL_QUEUE_PROFILING_ENABLE |
                                       CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE,
                                   &err));
...
    printf("[OOO Queue]: Enqueueing scale kernel\n");
    OCL_CHECK(
        err,
        err = ooo_queue.enqueueTask(
            kernel_mscale,nullptr, &ooo_events[0]));
    set_callback(ooo_events[0], "scale");
...
    // This is an out of order queue, events can be executed in any order. Since
    // this call depends on the results of the previous call we must pass the
    // event object from the previous call to this kernel's event wait list.
    printf("[OOO Queue]: Enqueueing addition kernel (Depends on scale)\n");
    kernel_wait_events.resize(0);
    kernel_wait_events.push_back(ooo_events[0]);
    OCL_CHECK(err,
              err = ooo_queue.enqueueTask(
                  kernel_madd,
                  &kernel_wait_events, // Event from previous call
                  &ooo_events[1]));
    set_callback(ooo_events[1], "addition");
    // This call does not depend on previous calls so we are passing nullptr
    // into the event wait list. The runtime should schedule this kernel in
    // parallel to the previous calls.
    printf("[OOO Queue]: Enqueueing matrix multiplication kernel\n");
    OCL_CHECK(err,
              err = ooo_queue.enqueueTask(
                  kernel_mmult,
                  nullptr,
                  &ooo_events[2]));
    set_callback(ooo_events[2], "matrix multiplication");

[Application Timeline] ビューには、複数の順番キュー手法と単一の順不同キュー手法の両方を使用して、計算ユニット mmult_1 が計算ユニット mscale_1 および madd_1 と並列で実行されているとことが示されます。

データをバースト転送すると、メモリ アクセスのレイテンシは表示されず、帯域幅の使用およびメモリ コントローラーの効率が改善されます。HLS レポートでバースト情報も確認してください。

バースト転送が発生すると、詳細なカーネル トレースに表示されるバースト率とバースト長の値が大きくなります。

上の図では、AXI インターコネクトの後のメモリ データ転送も異なる方法でインプリメントされているのがわかります (トランザクション時間が短縮)。これらのトランザクション上にカーソルを置くと、AXI インターコネクトが 16 x 4 バイトのトランザクションを 1 つの 1 x 64 バイトのパッケージ トランザクションにパックしたことがわかります。この方が、AXI4 帯域幅がより効率的に使用されます。次のセクションでは、この最適化手法について詳細に説明します。

バースト インターフェイスはコーディング スタイルとアクセス パターンによって大きく異なります。ただし、次のコード例に示すように、データ転送と計算を分離すると、バースト検出が容易になり、パフォーマンスが改善します。

void kernel(T in[1024], T out[1024]) {
    T tmpIn[1024];
    T tmpOu[1024];
    read(in, tmpIn);
    process(tmpIn, tmpOut);
    write(tmpOut, out);
}

つまり、read 関数が AXI 入力から内部変数 (tmpIn) に読み込みをします。計算は、内部変数 tmpIn および tmpOut で動作する process 関数でインプリメントされます。write 関数は生成された出力を取り込んで AXI 出力に書き出しますバーストの詳細は、『Vitis 高位合成ユーザー ガイド』 (UG1399: 英語版、日本語版) を参照してください。

計算結果からの read および write 関数を分離すると、次のようになります。

• 読み出し/書き込み関数の制御構造 (ループ) がシンプルになり、バースト検出がシンプルになります。
• AXI インターフェイスから計算関数を分離すると、可能なカーネル最適化が単純になります。詳細は、カーネル最適化 を参照してください。
• 内部変数はオンチップ メモリにマップされるので、AXI トランザクションよりも高速にアクセスできます。Vitis コア開発キットでサポートされるアクセラレーション プラットフォームには最大 10 MB のオンチップ メモリがあり、パイプ、ローカル メモリ、およびプライベート メモリとして使用できます。これらのリソースを効率的に使用することで、アプリケーションの効率およびパフォーマンスを大幅に向上できます。

Vitis コンパイラでは、カーネル引数のデータ型に基づいてカーネルおよびメモリ コントローラー間のユーザー データ幅を設定できます。ザイリンクスでは、データ スループットを最大にするため、ユーザーがメモリ コントローラーの全データ幅にマップされるデータ型を選択することをお勧めします。サポートされるアクセラレーション カードすべてのメモリ コントローラーで 512 ビットのユーザー インターフェイスがサポートされており、C/C++ 任意精度データ型 ap_int<512> や int16 などの OpenCL ベクター データ型にマップできます。

メモリ インターフェイスの幅に関する考慮事項 に示すように、デフォルトでは、Vitis HLS ツールでカーネル インターフェイス ポートのサイズが最大 512 ビットまで変更され、バースト アクセスを向上するようになっています。次の図では、バースト AXI トランザクション (バースト長 16) およびパッケージ サイズ 512 ビット (バースト サイズ 64 バイト) です。

この例は、AXI データ幅を最大にした良いインターフェイス設定と、実際のバースト トランザクションを示しています。

インターフェイスを宣言するのに使用される複雑な構造体またはクラスがあると、メモリ レイアウトやデータ パッケージの違いにより、ハードウェア インターフェイスが複雑になることがあります。これにより、複雑なシステムでデバッグするのが困難な問題が発生する可能性があります。

アルゴリズムの FPGA へのインプリメンテーションで計算の並列処理を活用するには、まずソース コードの計算の並列処理が合成ツールで認識されるようにする必要があります。ループおよび関数は、ソース記述で計算の並列処理および計算ユニットを反映する主な候補ですが、ソース コードの構造によっては Vitis テクノロジで必要な変換を適用できないことがあるので、インプリメンテーションで計算の並列処理の利点が活かされているかどうかを検証することが重要です。

計算の並列処理には、ソース コードに反映されないものもあるので、ソース コードに追加する必要があることもあります。たとえば、カーネルは 1 つの入力値に演算を実行するよう記述されているのに、FPGA インプリメンテーションでは計算が効率的に複数の値に対して並列に実行されるようになることがあります。このような並列モデルについては、タスクの並列処理 を参照してください。

512 ビットのインターフェイスは、int16 または C/C++ 任意精度データ型 ap_int<512> などの OpenCL ベクター データ型を使用して作成できます。これらのベクター型も、カーネル内のデータの並列処理をモデリングする方法として使用できます (int16 の場合は 16 個までのデータパスを並列処理可能)。ベクター型の使用に推奨される方法は、GitHub の Xilinx Getting Started Examples の vision カテゴリから Median Filter Example を参照してください。

ループは、アルゴリズム コードの繰り返しを示す基本的な C/C++/OpenCL API 手法です。次の例に、ループ構造のさまざまな側面を示します。

  for(int i = 0; i<255; i++) {
    out[i] = in[i]+in[i+1];
  }
  out[255] = in[255];

このコードは、最後の値を除き、配列のすべての値に対して実行され、2 つの連続する値を加算します。このループが記述どおりにインプリメントされると、ループの各反復に 2 サイクルかかるので、合計 510 サイクルかかります。この詳細は、HLS プロジェクトのスケジュール ビューアーで確認できます。

Vivado 合成結果では、これは合計とレイテンシで示されます。

ここで重要なのは、レイテンシ値と LUT の使用数です。たとえば、コンフィギュレーションによって、レイテンシが 511、LUT の使用数が 47 個になることがあります。これらの値は、インプリメンテーションでの選択によって大きく異なります。この例では、必要なエリアは小さいですが、レイテンシは長くなります。

タスクの並列処理を使用すると、データフロー並列処理の利点を活かすことができます。ループの並列処理とは異なり、タスクの並列処理ではタスク間で発生するバッファリングの利点を活かして、全実行ユニット (タスク) を並列実行できます。

次に例を示します。

void run (ap_uint<16> in[1024],
	  ap_uint<16> out[1024]
	  ) {
  ap_uint<16> tmp[128];
  for(int i = 0; i<8; i++) {
    processA(&(in[i*128]), tmp);
    processB(tmp, &(out[i*128]));
  }
}

このコードを実行すると、processA および processB 関数が順に 128 回実行されます。ループ内の processA および processB のレイテンシが合わせて 278 だとすると、総レイテンシは次のように見積もられます。

余分なサイクルはループ設定が原因で、これはスケジュール ビューアーで確認できます。

C/C++ コードの場合、タスク並列処理は for ループに DATAFLOW プラグマを追加すると実行されます。

#pragma HLS DATAFLOW

OpenCL API コードでは、for ループ前に次の属性を追加します。

__attribute__ ((xcl_dataflow))

このトピックの詳細は、データフロー最適化、HLS プラグマ、および OpenCL 属性 を参照してください。

HLS レポートの見積もりで示したように、タスク間にダブル (ピンポン) バッファーを使用すると、全体的なパフォーマンスを大幅に改善できます。

この場合、異なる反復で異なるタスクが並行実行されるので、デザインの全体的なレイテンシがほぼ 1/2 になります。各関数の処理に 139 サイクルかかり、128 反復が完全にオーバーラップしているので、総レイテンシは次のようになります。

(1x only processA + 127x both processes + 1x only processB) * 139 cycles = 17931 cycles 

タスクの並列処理は、インプリメンテーションでパフォーマンスを改善できる効果的な手法ですが、DATAFLOW プラグマを特定の任意のコード部分に適用するのがどれくらい効率的かは、状況によってかなり異なることがあります。DATAFLOW プラグマの最終的なインプリメンテーションを理解するには、個々のタスクの実行パターンを確認することが必要です。Vitis コア開発キットには、同時実行を示す Detailed Kernel Trace が提供されています。

前の図に示すように、この Detailed Kernel Trace の場合、データフロー フロー ループの始点が表示されます。processA はループの最初に即座に開始し、processB は processA の終了を待ってから最初の反復を開始します。processB がループの最初の反復を完了している間に、processA は 2 回目の反復の演算を開始します。

この情報のより抽象的な表示は、ホストとデバイスのアクティビティの アプリケーション タイムライン に示されます。

Vitis ツール フローでは、カーネル ポートのメモリへのマップ に説明するように --connectivity.sp オプションを使用すると、カーネル ポートからメモリ バンクへの接続ができます。v++ で生成された xclbin には、XRT でバッファーを適切に割り当てることができるように、カーネル ポートとメモリの接続に関する情報が含まれます。ホスト コードでバッファーが作成されると、XRT は自動的に xclbin カーネルからメモリにバッファーを割り当て、内部でバッファーを管理します。1 つのカーネル ポートが複数のメモリ バンクに接続される場合、XRT は常に番号の小さいバンクから開始します。

ほとんどの場合これで問題ありませんが、場合によっては、ホスト コードでバッファーの場所 (または特殊なプロパティ) を手動で割り当てる必要があります。このため、ザイリンクス の OpenCL ベンダー拡張機能には、ホスト コードでのバンク割り当てを管理する CL_MEM_XRT_PTR_XILINX というバッファー拡張機能があります。次の例は、入力および出力バッファーを DDR バンク 0 とバンク 1 に割り当てるのに必要なヘッダー ファイルとコードを示しています。

#include <CL/cl_ext.h>
…
int main(int argc, char** argv) 
{
…
    cl_mem_ext_ptr_t inExt, outExt;  // Declaring two extensions for both buffers
    inExt.flags  = 0|XCL_MEM_TOPOLOGY; // Specify Bank0 Memory for input memory
    outExt.flags = 1|XCL_MEM_TOPOLOGY; // Specify Bank1 Memory for output Memory
    inExt.obj = 0   ; outExt.obj = 0; // Setting Obj and Param to Zero
    inExt.param = 0 ; outExt.param = 0;

    int err;
    //Allocate Buffer in Bank0 of Global Memory for Input Image using Xilinx Extension
    cl_mem buffer_inImage = clCreateBuffer(world.context, CL_MEM_READ_ONLY | CL_MEM_EXT_PTR_XILINX,
            image_size_bytes, &inExt, &err);
    if (err != CL_SUCCESS){
        std::cout << "Error: Failed to allocate device Memory" << std::endl;
        return EXIT_FAILURE;
    }
    //Allocate Buffer in Bank1 of Global Memory for Input Image using Xilinx Extension
    cl_mem buffer_outImage = clCreateBuffer(world.context, CL_MEM_WRITE_ONLY | CL_MEM_EXT_PTR_XILINX,
            image_size_bytes, &outExt, NULL);
    if (err != CL_SUCCESS){
        std::cout << "Error: Failed to allocate device Memory" << std::endl;
        return EXIT_FAILURE;
    }
…
}

cl_mem_ext_ptr_t 拡張ポインターは次のように定義される struct です。

typedef struct{
    unsigned flags;
    void *obj;
    void *param;
  } cl_mem_ext_ptr_t;

• flags の有効な値は、次のとおりです。
  • XCL_MEM_DDR_BANK0
  • XCL_MEM_DDR_BANK1
  • XCL_MEM_DDR_BANK2
  • XCL_MEM_DDR_BANK3
  • <id> | XCL_MEM_TOPOLOGY
    注記: <id> は xxx.xclbin ファイルの次に生成される xxx.xclbin.info ファイルの [Memory Configuration] セクションから判断されます。xxx.xclbin.info ファイルには、グローバル メモリ (DDR、HBM、PLRAM など) が <id> を示すインデックスと共にリストされます。
• obj: CL_MEM_USE_HOST_PTR フラグが clCreateBuffer API に渡された場合に CL メモリ バッファーに割り当てられるホスト メモリに関連付けられているポインターです。それ以外の場合は NULL に設定されます。
• param: 今後の使用のために予約されています。常に 0 または NULL に設定します。

拡張ポインターは、次のような特殊なケースで使用できます。

P2P バッファー

説明と例については、https://xilinx.github.io/XRT/master/html/p2p.html を参照してください

ホスト メモリ バッファー

説明と例については、https://xilinx.github.io/XRT/master/html/sb.html を参照してください

カーネル ポートが複数のバンクに接続される場合、特定のバンクにホスト バッファーを割り当てます。

たとえば、DDR[0:1] のようにします。このユース ケースについては、Vitis チュートリアルのアクセラレーション FPGA アプリケーションの最適化: ブルーム フィルターの例の「複数 DDR バンクの使用」を参照してください。

[connectivity]
sp=runOnfpga_1.input_words:DDR[1:2]

#include <CL/cl_ext.h>
…
int main(int argc, char** argv) 
{
cl_mem_ext_ptr_t buffer_words_ext[2];

buffer_words_ext[0].flags = 1 | XCL_MEM_TOPOLOGY; // DDR[1]
buffer_words_ext[0].param = 0;
buffer_words_ext[0].obj   = input_doc_words;
buffer_words_ext[1].flags = 2 | XCL_MEM_TOPOLOGY; // DDR[2]
buffer_words_ext[1].param = 0;
buffer_words_ext[1].obj   = input_doc_words;
…

DDR メモリ リソースは、プラットフォームの SLR (Super Logic Region) をまたいで分配されます。SLR をまたぐ接続の数は制限されるので、カーネルを DDR メモリ リソースとの接続数が最も多い SLR に配置するのが一般的です。これにより、SLR をまたぐ接続の競合が削減し、SLR をまたぐためにロジック リソースが消費されるのを回避できます。

上の図に示すように、カーネルに 1 つの AXI インターフェイスがあり、1 つのメモリ バンクにのみマップされる場合、platforminfo ユーティリティ で説明される platforminfo ユーティリティにより、カーネルのメモリ バンクに接続されている SLR がリストされるので、これがカーネルが最適に配置される SLR です。この場合、追加の入力なしでもデザイン ツールによりカーネルが自動的にその SLR に配置される可能性はありますが、次の場合は明示的に SLR を割り当てる必要があります。

• デザインに同じメモリ バンクにアクセスするカーネルが多数含まれる場合。
• カーネルにメモリ バンクの SLR に含まれない特殊なロジック リソースが必要な場合。

カーネルに複数の AXI インターフェイスがあり、すべてのインターフェイスが同じメモリ バンクにアクセスする場合、1 つの AXI インターフェイスを含むカーネルと同様に処理でき、カーネルを AXI インターフェイスがマップされているメモリ バンクと同じ SLR に配置する必要があります。

カーネルに複数の AXI インターフェイスがあり、異なる SLR にある複数のメモリ バンクに接続されている場合は、カーネルがアクセスするメモリ バンクの大部分が含まれる SLR にカーネルを配置することをお勧めします。これにより、このカーネルで必要な SLR をまたぐ接続数が最小限に抑えられ、ユーザー デザイン内のほかのカーネルでメモリ バンクに接続するために使用可能な SLR をまたぐリソースが増えます。

カーネルが別の SLR にあるメモリ バンクに接続される場合は、カーネル SLR および DDR メモリの割り当て のように SLR の割り当てを明示的に指定します。

プラットフォームに含まれる SLR が 3 つ以上になると、上の図に示すように、最も多くマップされるメモリ バンクのすぐ隣ではない SLR のメモリ バンクにカーネルがマップされることもあります。このような場合、離れたメモリ バンクにアクセスするために複数の SLR 境界をまたぐ必要があるので、SLR をまたぐリソースの使用量が増加します。このようなリソース使用量の増加を避けるには、カーネルを中央の SLR に配置して、隣接する SLR にまたぐリソースのみが使用されるようにします。