取引におけるOpenCL - ページ 3

[MetaQuotes]

AMD デベロッパー セントラル: OpenCL プログラミング ウェビナー シリーズ.2。 OpenCL の概要

2- OpenCL の概要

このビデオでは、CPU と GPU を使用して計算を高速化できる並列コンピューティング用のプラットフォームである OpenCL について詳しく説明します。 OpenCL で書かれたプログラムはさまざまなデバイスやアーキテクチャ上で実行できるため、さまざまなプラットフォーム間でコードを移植できます。このビデオでは、データ並列処理やタスク並列処理など、OpenCL のさまざまな実行モデルについて説明し、メモリ オブジェクト、コマンド キュー、カーネル オブジェクトなど、OpenCL で使用されるさまざまなオブジェクトやコマンドについても説明します。このビデオでは、明示的なメモリ管理の必要性や並列プログラムのパフォーマンスが大幅に向上する可能性など、OpenCL を使用する利点と制限についても詳しく説明しています。

• 00:00:00 このセクションでは、講演者が OpenCL と、CPU と GPU を使用して並列計算を加速し、大幅な速度向上を実現するその機能を紹介します。 100 倍や 1000 倍といった数字が引用されることもありますが、現実的には、最適化されたプログラムでは約 10 ～ 20 倍のスピードアップが期待されます。 OpenCL は、さまざまなデバイスやアーキテクチャにわたって移植可能なコードを作成できます。したがって、AMD GPU 用に作成されたプログラムは通常、NVIDIA GPU でも実行できます。 AMD 実装では、他の競合他社の実装とは異なり、OpenCL の CPU 実装と GPU 実装の両方が提供されます。このセクションは、ヘテロジニアス コンピューティングの概要と、OpenCL がそれにどのように適合するかで終わります。
  
  
• 00:05:00 このセクションでは、講演者が OpenCL について紹介します。OpenCL は低レベルで冗長なプラットフォームであり、アプリケーションが適切な特性を備えていれば、パフォーマンスの面でメリットが得られます。 OpenCL は、ホスト API、接続されたデバイスのモデル、およびメモリ モデルで構成されるプラットフォーム ベースのモデルです。デバイスは計算ユニットの集合として見なされ、各計算ユニットは SIMD で実行される処理要素に分割されます。実行モデルは、カーネルの概念に基づいています。カーネルは、複数のデータに対して並行して実行できる実行可能コードの単位です。さらに、OpenCL は、読み取りおよび書き込み操作とカーネル実行の非同期実行を許可する一連のキューを提供します。これらの実行は、順序どおりまたは順序どおりに実行できません。
  
  
• 00:10:00 このセクションでは、講演者が OpenCL の 2 つの主要な実行モデル、データ並列処理とタスク並列処理について説明します。データ並列モデルは、GPU での実行が最も効率的であり、個々の要素が潜在的に並列実行できるワークアイテムと呼ばれる N 次元の計算ドメインを含みます。作業項目の実行は、使用可能なコンピューティング ユニットの 1 つで実行されるワーク グループと呼ばれるローカル ディメンションにグループ化できます。講演者は、OpenCL のデータ並列世界においてループがどのように暗黙的であるか、および a と b にインデックスを付けるためにグローバル識別子の取得ルーチンがどのように使用されるかについても説明します。
  
  
• 00:15:00 このセクションでは、講演者はローカル メモリについて説明します。ローカル メモリはキャッシュに似ており、ユーザーによって管理され、低遅延でグローバル メモリよりも高速です。同期機能を使用すると、ワークアイテムがメモリ位置に書き込み、完了を待ってから、別のワークアイテムにそのメモリ位置を読み取らせ、前のワークアイテムによって書き込まれた値を取得できます。同期はワークグループ内でのみ実行できます。 OpenCL は、単一のワークアイテムによって実行されるタスクの並列処理もサポートしており、OpenCL キューイング モデルとホスト API の同期機能を利用することで、コードをネイティブにコンパイルできるようになります。 OpenCL は、特定の GPU のメモリ階層が明示的に公開され、プログラマがバリア操作と同期を使用してデータの順序付けと一貫性を実現できるという点で C とは異なります。
  
  
• 00:20:00 このセクションでは、講演者が OpenCL の強力なパフォーマンス機能などの利点について説明します。ただし、OpenCL でのメモリ管理には明示的な操作が必要であり、複雑になる可能性があり、アルゴリズムを慎重に検討する必要があると彼らは指摘しています。コンパイル モデルは OpenGL に基づいており、オンライン コンパイル用に OpenCL ソース コードのストリームまたは文字列を渡すことができるオンライン コンパイル モデルを備えています。 OpenCL はコンテキスト、デバイスのコレクション、メモリ オブジェクトを中心に構築されており、コンテキストに関連付けられた特定のデバイスに作業を送信するためにキューが使用されます。メモリ オブジェクトはバッファであり、配列と考えることができるメモリの 1 次元ブロックです。
  
  
• 00:25:00 このセクションでは、講演者がメモリ オブジェクト、イメージ、プログラム、カーネルなどのさまざまな OpenCL オブジェクトについて説明します。メモリ オブジェクトはバッファまたはイメージ タイプであり、イメージにはアクセスを最適化するハードウェア実装が含まれています。実行用のカーネルを定義するプログラムは構築および抽出でき、カーネル引数の値はカーネル オブジェクトを使用して設定できます。コマンド キューは、カーネルおよびその他のコマンドを実行のためにキューに入れるために使用されます。さらに、OpenCL イベントは、コマンド間の依存関係を構築したり、コマンドのステータスをクエリしたりするのに役立ちます。講演者は、デバイスとその ID をクエリする方法の例も示します。
  
  
• 00:30:00 このセクションでは、OpenCL がエラー コードとオブジェクトを返す方法について講演者が説明します。関数が CL オブジェクトを返す場合、そのオブジェクトが結果として返されます。ただし、CL オブジェクトを返さない場合は、結果としてエラー コードが返されます。コンテキストと、コンテキスト レベルでメモリがどのように割り当てられるか、つまりバッファとイメージがデバイス間で共有される方法について説明します。講演者はまた、CL get X info 関数、特に CL get device info についても触れました。これにより、開発者はデバイスの機能をクエリして、アルゴリズムに最適なデバイスを判断できます。最後に、講演者はバッファとイメージ、カーネルがそれらにアクセスする方法、およびイメージ アクセスの制限について説明します。
  
  
• 00:35:00 このセクションでは、バッファへのアクセス方法やイメージを使用する利点の説明方法など、OpenCL でバッファとイメージを割り当てる方法について講演者が説明します。また、講演者は、明示的なコマンドを使用してメモリ オブジェクト データにアクセスする方法と、コマンドをキューに入れる方法についても説明します。さらに、ビデオでは、領域をマッピングしてバッファー間でデータを転送する方法と、DMA ユニットを使用する利点と欠点について説明します。このセクションは、プログラムとカーネル オブジェクトと引数値の設定について説明して終わります。
  
  
• 00:40:00 このセクションでは、講演者が OpenCL のディスパッチと依存関係について説明します。実行のドメインまたはグリッドに基づいてディスパッチがどのように実行されるか、および相互に追い越さないように依存関係を設定する方法について説明します。講演者は、待機リスト内のイベントの数とコマンドに関連付けられたイベントを考慮する、NQ コマンドの引数についても説明します。最後に、講演者は OpenCL C 言語の概要を説明します。この言語は C をベースにしており、ベクトル型や同期プリミティブなどの特定の制限と追加があります。この言語では、アドレス空間修飾子や組み込み関数だけでなく、作業項目や作業グループも使用できます。
  
  
• 00:45:00 このセクションでは、講演者が OpenCL とその機能 (カーネルのプログラミングで使用できるさまざまなアドレス空間、ベクトル型、スカラー型など) の概要を説明します。また、OpenCL API を使用してメモリ オブジェクトを作成し、プログラムを構築および実行する方法についても説明します。次に講演者は、OpenCL でのデータ並列処理とコンパイラでのループ展開がどのように異なるかについての質問に答えます。
  
  
• 00:50:00 このセクションでは、講演者がデータの並列実行の概念と、それを効率的に実行するコンポーネントの難しさを説明します。同氏は、OpenCL やその他のモデルのプログラムを明示的に並列化する必要性も強調しています。 inq_marker についても説明し、順序が崩れたキューでそれがどのように役立つかについて説明します。講演者は、定数メモリとは値が一定であることを意味し、読み取り専用の非常に高速な定数メモリに読み込むために特別な GPU で使用されることを繰り返し述べました。彼は、OpenCL と並列プログラミングの詳細については、MD Web サイトの OpenCL Zone をチェックすることを提案しています。最後に、get_global_ID(0) がカーネルの呼び出しごとにどのように同じ値を返すかについて説明します。
  
  
• 00:55:00 このセクションでは、講演者は、2 つの異なるアプリケーションが両方とも同じマシン上で実行され、OpenCL を使用しようとしている場合、今日のすべての実装がハードウェアを共有し、OS がアプリケーションを多重化することについて説明します。彼らは、ハードウェア ID に関する情報をクエリできる Visual Studio プラグインや Linux コマンド ライン バージョンなど、OpenCL 用のビジュアル プロファイラーを使用することを推奨しています。画像オブジェクトまたはバッファにデータをロードするオーバーヘッドはデバイスによって異なりますが、PCIe バスを介してデータを転送すると遅延が大きくなります。最後に講演者は、新しい AMD 680 100 GPU シリーズとそのベスト プログラミング プラクティスは、そのベースとなっている Evergreen アーキテクチャに似ていると述べました。

[MetaQuotes]

AMD デベロッパー セントラル: OpenCL プログラミング ウェビナー シリーズ。 3. GPU アーキテクチャ

3 - GPU アーキテクチャ

このビデオでは、グラフィックス プロセッサとしての GPU の起源と主な用途に注目しながら、GPU アーキテクチャの概要を説明します。低遅延パイプラインによるスカラー処理用に設計された CPU とは対照的に、GPU は高度な並列処理でピクセルを処理するように設計されています。 GPU のアーキテクチャはグラフィックス固有のタスク向けに最適化されているため、汎用の計算には適していない可能性があります。講演者は、GPU が単一スレッドの実行レイテンシーを最小化するのではなく、スレッドのセットのスループットを最大化する方法について説明します。ローカル データ共有、ウェーブ フロント、ワーク グループなど、GPU エンジン ブロックのアーキテクチャについても説明します。このビデオでは、単一パケットでの依存演算の発行や、グローバル ベータ シェアによる依存カウンターのサポートなど、コンパイラーが実行できるパッキング量の増加に役立つさまざまな GPU アーキテクチャの機能について説明します。 GPU と CPU コアの設計は類似している可能性がありますが、同様の設計にするためには、ワークロードが収束する必要があります。

GPU アーキテクチャに関するこのビデオでは、講演者がバリアの概念とその機能について詳しく説明しています。ワーク グループに GPU 内の複数のウェーブフロントが含まれている場合、バリアを使用してこれらのウェーブフロントが同期されます。ただし、グループ内に作業ウェーブフロントが 1 つだけ存在する場合、障壁は無意味になり、非運用状態になります。

• 00:00:00 このセクションでは、発表者がウェビナーの目的を紹介します。これは、低レベルのアーキテクチャや最適化を説明する従来のアプローチとは異なる視点から GPU アーキテクチャの概要を提供することです。発表者は、GPU アーキテクチャの起源とグラフィックス プロセッサとしての主な使用例について議論することで、GPU アーキテクチャを文脈に落とし込むことを目指しています。低遅延パイプラインによるスカラー処理用に設計された CPU とは異なり、GPU が高度な並列処理でピクセルを処理するように設計されている方法について説明しています。発表者はまた、グラフィックス固有のタスクを高速化するために設計された最適化されたハードウェア ブロックにより、GPU のアーキテクチャが汎用計算には適していない可能性についても触れています。
  
  
• 00:05:00 このセクションでは、GLSL または HLSL で書かれた独立した単一ピクセルに関連するフラグメント プログラムの実行について、また、このプログラミング パターンによって依存関係分析やピクセル間通信を行わずに効率的な並列処理がどのように可能になるかを学びます。このハードウェアは、ウェーブフロントと呼ばれる複数のピクセルでシェーダー コードを一度に実行するように設計されていますが、ブロック コードと分岐の問題があります。この問題は、すべての分岐が同じ方向に進んで問題が発生する場合に発生しますが、ハードウェアはマスクを生成して、すべてのピクセルが同じ命令を実行していることを確認します。
  
  
• 00:10:00 このセクションでは、講演者は、Cindy の実行に単純な命令とベクトル命令の使用がどのように必要かについて説明します。ベクトル命令はハードウェアまたはコンパイラで生成できますが、さまざまな操作の手動パッケージ化、分岐マスキング、および慎重なハンドコーディングが必要なため、開発が面倒で困難になる可能性があります。一方、ベクトル命令を使用して Cindy の実行をプログラミングすると、開発者にレーンが独立して分岐していると思わせる危険性がありますが、これは真実ではありません。それにもかかわらず、プログラマーにとってはまだ考えやすく、現在の AMD GPU ではマスキングはハードウェアによって制御されます。これは、特に広い Waveland でのブランチ分岐の場合にパフォーマンスに影響を与える可能性があるため、講演の目的であるコンピューティングについて考慮することが重要です。
  
  
• 00:15:00 このセクションでは、講演者は、スループット コンピューティングに基づく GPU アーキテクチャの目に見える側面について説明します。つまり、命令ベクトルが GPU でストールした場合、浮動小数点加算に数サイクルかかる場合に発生する可能性があります。完了すると、同じ命令を使用して次のベクトルのストール時間をカバーできるため、命令のデコードがより効率的になります。講演者は、ALU の使用率を削減するためにベクトル幅を増やす代わりに、複数のウェーブフロントが他の実行中のスレッドから命令を忍び込ませることができ、テクスチャ ユニットがメモリ データを返すのを待っている間に単純に停止しない可能性が得られると説明しています。ただし、アーキテクチャの仕組みにより、この方法で単一のウェーブフロントを実行すると時間がかかります。
  
  
• 00:20:00 このセクションでは、GPU が単一スレッドの実行レイテンシーを最小化するのではなく、スレッドのセットのスループットを最大化する方法をビデオで説明します。これは、GPU が最初のスレッドの実行が完了するのを待ってから次のウェーブフロントを供給することでスレッドの使用率を高めようとする一方、最初のピクセルのセットの結果が再利用されてパイプラインを可能な限り完全な占有に近づけることを意味します。 。 GPU は、実行中の各スレッドのベクトルの全幅をカバーするための大きなレジスタ プールを維持し、デバイス上のスペースを占有し、状態の数とベクトルの幅に応じてスケールされます。 GPU はレイテンシーをカバーするように設計されているため、レイテンシーを最小限に抑える代わりに、GPU は、作業項目間でのデータの再利用にテクスチャ キャッシュとローカル メモリを使用して、すべての並列処理を満たすことができるように利用可能なメモリ帯域幅を最大化します。
  
  
• 00:25:00 このセクションでは、講演者は、メイン メモリ インターフェイスからデータを 1 回だけコピーし、その後、さまざまなパスのさまざまなワークアイテムで再利用できるようにすることで、キャッシュとプログラム制御の共有メモリ領域がどのようにしてデータ転送の削減を実現できるかについて説明します。これらは、クワッドによる 2D アクセスをキャプチャするために、データに 2D 構造を自動的に効率的に適用するテクスチャ キャッシュの設計方法について説明しています。ローカル データ領域では、かなり詳細な制御が可能ですが、このメモリを使用するためにロードを効率的に構造化し、データを共有してグローバル メモリ要件を削減するのは開発者の責任です。このセクションでは、パイプラインのレイテンシーをカバーするために 4、8、または 16 スレッドをインターリーブする複数のプログラム状態を持つ有線 Cindy コアの集合として GPU をどのようにみなすかについても説明します。コア数と ALU 密度の間のトレードオフについて説明しますが、ワークロードに応じて使用率が向上する利点があります。
  
  
• 00:30:00 このセクションでは、講演者は、Andy Phenom 2 X6 6 や Intel i7 などの例を使用して、CPU と GPU のコア設計の類似点と相違点について説明します。 Pentium 4 と UltraSPARC T2 が採用したアプローチでは、命令レベルの並列性を高めるために複数のステート セットを備えた大きなコア サイズが必要でしたが、GPU は高度なデータ バランシングを備えたスペクトルの極限にあります。 AMD Radeon HD 5870 の技術的な詳細についても説明し、その高帯域幅と、各ウェーブフロントで使用されるレジスタの数に応じて利用可能な同時波形の数を指摘します。講演者は、CPU 9 と GPU 9 の間には設計空間に類似点があるかもしれないが、同様の設計にするためにはワークロードが収束する必要があると結論付けています。
  
  
• 00:35:00 このセクションでは、ローカル データ共有、ウェーブ フロント、分割されるワーク グループなど、GPU の設計要素について学びます。 GPU の設計には、波面を生成する大佐のディスパッチ コマンド プロセッサが含まれており、波面はスペースに適合するのに十分なリソースを持つ利用可能な SIMD ユニットに割り当てられます。チップ全体には、クロスバーとキャッシュ用に 8 つの GDDR5 メモリ バンクを備えた 20 個の Cindy エンジンが搭載されています。さらに、緩和されたグローバル メモリ整合性モデルを備えており、可視性の権利を確保するフェンス命令が必要であり、Cindy エンジンと固定ユニットが電力パフォーマンスのオーバーヘッドなしで可能な限り高度なデータの並列実行を維持できます。 GPU は句ベースの実行モデルを使用し、最も単純なエンジン上で多くの制御フロー プログラムを同時に実行できるようにします。
  
  
• 00:40:00 このセクションでは、GPU エンジン ブロックのアーキテクチャについて説明します。エンジン ブロックには 2 つの主要なコンポーネントがあります。1 つはワークグループ内の作業項目とポストテスト要素の間でデータを共有できるローカル データ共有、またはカーネル内の ALU 句からの命令を実行するストリーム コアです。ローカル データ共有には 32 のバンクがあり、エンジン内の 16 個の処理要素のそれぞれが、サイクルごとに任意のアドレスで LDS から 32 ビット ワードの読み取りまたは書き込みを要求でき、競合はユニットによって検出されます。アトミック操作は整数のみの ALU を使用して実行されますが、浮動小数点アトミックの実行はより複雑になります。 5870 アーキテクチャのプロセッシング エレメントは、コンパイラによってパッケージ化された 5 つの演算からなる非常に長い命令ワード パケットを処理する 5 つの同一の ALU のクラスターであり、独自の依存関係のセットがあり、ほとんどの基本的な演算を実行できます。
  
  
• 00:45:00 このセクションでは、単一パケットでの依存演算の発行や、グローバル ベータ シェアによる依存カウンターのサポートなど、コンパイラーが実行できるパッキング量を増やすのに役立つさまざまな GPU アーキテクチャの機能について講演者が説明します。グローバル ベータ シェアは、デバイス上のコンピューティング エンジンのセット全体に接続されており、他のメモリにアクセスするよりも待ち時間がはるかに短い、あまり知られていない機能です。また講演者は、テクスチャ キャッシュ内のランダム ピクセルにアクセスすると、データがクラスター化されている場合にのみグローバル メモリ アクセスを行うよりも高速になるため、パフォーマンスの問題が発生する可能性があると警告しています。
  
  
• 00:50:00 このセクションでは、GPU アーキテクチャでの完全占有の達成に関連する質問に講演者が回答します。示されている例では、完全な占有を得るには、ワーク グループが 64 の倍数の作業項目で構成されている必要があります。各コアに適合できる波面と波面の数も完全占有率に影響します。講演者はまた、5th Lane によって生成される超越関数の完全精度バージョンはなく、コードのニーズに応じて十分に優れている場合とそうでない可能性がある高速近似であるとも述べています。すべてのデバイス内の波面サイズをクエリする方法があるかどうか尋ねると、そのような方法はないと答えます。
  
  
• 00:55:00 このセクションでは、GPU アーキテクチャにおけるグローバル メモリ アクセスの観点から完全合体が何を意味するかを講演者が説明します。本質的に、これは、1/4 波面がメモリ リクエストを発行し、各レーンがコンピューティング ユニット全体で整列されたアドレスから 128 ビットに連続してアクセスすることを意味します。ただし、アクセス タイプ、アタッチされているかデタッチされているか、ランダム ギャザリングかどうかに応じて効率のレベルが異なります。講演者はまた、ウェーブフロントは 1 つの命令とともに実行される 64 個の作業項目で構成される作業単位であり、作業項目の集合であるワークグループとは同じではないことも明確にしています。
  
  
• 01:00:00 このセクションでは、講演者が GPU アーキテクチャにおけるバリアの概念を説明します。ワークグループに複数のウェーブフロントがある場合、バリア命令を発行すると、これらのウェーブフロントが同期されます。ただし、グループ内に作業ウェーブフロントが 1 つしかない場合、障壁は業務以外のものになり、意味がありません。

[MetaQuotes]

AMD デベロッパー セントラル: OpenCL プログラミング ウェビナー シリーズ。 4 OpenCL プログラミングの詳細

4 - OpenCL プログラミングの詳細

このビデオでは、講演者が OpenCL プログラミングの概要を説明し、その言語、プラットフォーム、ランタイム API について説明します。彼らは、きめ細かい並列化、作業項目とグループまたはスレッド、同期、メモリ管理を必要とするプログラミング モデルについて詳しく説明します。次に講演者は、n 体アルゴリズムとその計算次数 n 乗の性質について説明します。 OpenCL カーネル コードがニュートン力学で粒子の位置と速度を更新する方法、1 つの粒子の位置を保存するキャッシュの導入方法、および浮動小数点ベクトル データ型を使用してカーネルが粒子の位置と速度を更新する方法について説明します。また、講演者は、パラメーターと引数を明示的に設定し、ホストと GPU の間でデータを転送し、同期のためにカーネル実行をキューに入れることによって、ホスト コードが OpenCL カーネルとどのように対話するかについても詳しく説明します。最後に、ビデオでは、複数のデバイスをサポートするように OpenCL コードを変更し、GPU 間でデータを同期し、それらを表す半分のサイズの配列にデバイス ID を設定する方法を説明します。

2 番目の部分では、OpenCL プログラミングのさまざまな側面について説明します。 2 つの配列間で更新されたパーティクル位置を同期するためのダブルバッファー方式、OpenCL の制限、メモリ割り当てにおけるグローバル ポインターとローカル ポインターの違いなどのトピックについて説明します。さらに、ベクトル演算、制御されたメモリ アクセス、ループ アンローリングなどの OpenCL プログラミングの最適化手法と、プロファイリング ツールなどの OpenCL 実装の分析に利用できるツールについても取り上げます。発表者は、OpenCL プログラマ向けのリソースとして OpenCL 標準を推奨し、標準と ATI Stream SDK の URL を提供します。このビデオでは、メモリ共有、コードの最適化、メモリ割り当て、計算ユニットの使用率などのトピックに関する質問も取り上げています。

• 00:00:00 このセクションでは、講演者が OpenCL の概念を紹介し、ハイブリッド CPU-GPU アーキテクチャの出現と、それがプログラミングにもたらす課題について説明します。 OpenCL は、業界全体のサポートを備えたプラットフォームおよびデバイスに依存しない API を提供し、講演者は OpenCL API の 3 つの部分 (言語仕様、プラットフォーム API、ランタイム API) について概説します。実行モデルは 2 つの部分に分かれています。OpenCL デバイス上で実行される実行可能コードを表すカーネルと、メモリ管理を実行し、コマンド キューを使用して 1 つ以上のデバイスでのカーネル実行を管理するホスト プログラムです。カーネル プログラミングに使用される C 言語拡張機能は、ISO C99 に基づいていますが、並列処理をサポートするためにいくつかの制限と追加が加えられています。
  
  
• 00:05:00 このセクションでは、講演者が OpenCL のプログラミング モデルについて説明します。これには、スレッド間でのきめ細かい並列化と同期が必要です。ワークアイテムとワークグループはスレッドとして導入され、同期と共有メモリへのアクセスに関して特別なプロパティを持つワークグループにグループ化されます。講演者はホスト側の実行モデルについても説明し、デバイス、プログラム オブジェクト、カーネル、メモリ オブジェクト、およびカーネルとメモリまたはデータ転送操作をキューに入れるためのコマンド キューのコレクションを含むコンテキスト内にすべてがまとめられていることを説明しました。 。 OpenCL は、分散メモリを備えたハイブリッド システムにおけるメモリの性質を反映するために、さまざまなタイプのメモリの階層もサポートしています。
  
  
• 00:10:00 このセクションでは、講演者が OpenCL プログラミングを使用する際のメモリと同期の管理の重要性について説明します。 OpenCL には緩和されたメモリ整合性モデルがあり、データ転送を管理し、あるデバイスから別のデバイスにデータを移動するタイミングを制御するのはプログラマの責任になります。複数のデバイスを使用する場合は同期が不可欠であり、カーネルの実行やデータ転送などのイベントが正しく同期されていることを確認するのはプログラマの責任です。講演者は、OpenCL への簡素化されたインターフェイスである Standard CL の使用法を紹介し、すぐに使用できるデフォルトのコンテキストを提供し、すべてのデバイスを含み、OpenCL の完全な機能が中断されません。さらに、Standard CL は、OpenCL デバイス間で共有可能なメモリを割り当てる CL Maylock を通じてメモリ管理を簡素化します。
  
  
• 00:15:00 このセクションでは、講演者が基本的な n 体アルゴリズムについて説明します。このアルゴリズムは、何らかの形式の粒子間相互作用を受ける n 粒子の動きをモデル化します。このアルゴリズムでは、システム内の他のすべての粒子との相互作用の寄与を合計することによって、各粒子にかかる力を計算します。すべての粒子にかかる力が判明すると、粒子の位置と速度が小さな時間ステップで更新されます。このプロセスは粒子ごとに繰り返され、その結果、相互作用力を受けて移動する粒子のシミュレーションが行われます。このアルゴリズムは計算上 n 乗であり、メモリ転送帯域幅に制限があるコプロセッサを使用しても高速化が可能です。アルゴリズム全体は、C のわずか数十行のコードで記述できます。
  
  
• 00:20:00 このセクションでは、講演者が粒子間の相互作用を蓄積するループによる n-body アルゴリズムの実装について説明します。カーネル コードは、OpenCL の観点から優れた実践方法を使用して合理的な標準実装を提供するように設計されていますが、特定のアーキテクチャには最適ではない可能性があります。カーネルはインデックス空間内のすべての作業項目に対して実行され、各スレッドは単一パーティクルの位置と速度を更新します。アプリケーションには、システム内のパーティクルの数と同じ数のワークアイテムを備えた単純な 1 次元のインデックス ベースがあります。ホスト コードは、OpenCL デバイスでの初期化、メモリ管理、および調整操作にも不可欠です。
  
  
• 00:25:00 このセクションでは、講演者はニュートン力学で粒子の位置と速度を更新するためのカーネル コードを紹介します。カーネル コードのプロトタイプは C 関数のプロトタイプに似ていますが、アドレス空間とブロッキング スキームの使用を修飾する修飾子がいくつかあります。カーネル コードは別のファイルに保存され、プログラムの実行時にジャストインタイム コンパイルで使用されます。次に講演者は、実際の物理計算に入る前に、カーネル コードがサイズとインデックスをどのように決定するかを説明します。グローバル スレッド ID とローカル スレッド ID についても詳細に説明され、講演者は、カーネルがシステム内のすべてのパーティクルに対して自動的に実行されるため、カーネル コードに外部ループが暗黙的に含まれていることを指摘しました。
  
  
• 00:30:00 このセクションでは、講演者がキャッシュを使用したペアワイズ フォース計算のための OpenCL カーネルの実装について説明します。カーネルは 1 つのパーティクル位置をキャッシュし、ワーク グループ内の他のワークアイテムにも依存してキャッシュを埋めます。 64 個の粒子位置がキャッシュされると、カーネルはキャッシュされた粒子位置をループして、C コードに示されているのと同じ力の計算を実装しますが、OpenCL に特有の顕著な違いがあります。これらには、粒子の位置に float ベクトルを使用すること、平方根に OpenCL 組み込み関数を使用すること、便宜上、float ベクトルの未使用の 4 番目のコンポーネントに質量を格納することが含まれます。カーネルは、float ベクトル データ タイプを使用して、単一クロックでパーティクルの位置と速度を更新します。最後に、講演者は、キャッシュのフィルアップとループ操作中の同期のためのバリアの必要性について説明します。
  
  
• 00:35:00 このセクションでは、他のスレッドが依然として必要とするデータの上書きを避けるために、新しい位置と新しい速度を新しい配列のグローバル メモリに書き戻す方法について学びます。この二重バッファリング スキームは、スレッドの同時実行の問題が発生することなくパーティクルの位置を安全に更新するために、後の段階で使用されます。カーネルのホスト コード実装に移り、プログラムがどのようにパラメータを設定し、メモリを割り当て、位置と速度を初期化し、OpenCL カーネルを構築してコンパイルし、必要な現在の n ボディ カーネルを名前でクエリし、1 つのカーネルを作成するかを学びます。 -次元カーネル計算ドメインを定義し、カーネル引数を明示的に設定します。全体として、このコードは、ホストがプロキシによってカーネルを実行する点と、カーネルの引数を直接設定する必要がある点で、OpenCL が基本的な C プログラムとどのように異なるかを示しています。
  
  
• 00:40:00 このセクションでは、講演者は、clm シンク呼び出しを使用してホストから GPU にデータを転送し、呼び出しをブロックするためのフラグを使用してデバイス (GPU) 上の配列を同期するプロセスを説明します。次に、ループ オーバー ステップについて説明し、診断目的で使用される値とバーストを紹介し、ダブル バッファリングのためのカーネル引数 2 と 3 の設定を遅延します。講演者は、カーネルの実行がキューに入れられ、続行する前にすべてのカーネルの実行が完了していることを確認するために CL 待機同期呼び出しが使用されることに注意しました。最後に、CL エンキュー読み取りバッファを使用して、データを GPU からホストに戻します。
  
  
• 00:45:00 このセクションでは、ビデオで複数のデバイスをサポートするようにコードを変更する方法、特に 2 つの GPU でコードを実行する方法について説明します。このアプローチでは、力の計算と粒子位置の更新の作業を 2 つの GPU 間で分割し、1 つの GPU が粒子の半分を担当します。カーネル コードにはほとんど交換が見られず、プロトタイプに追加された引数が「position Remote」と呼ばれる追加引数だけです。これは、特定の GPU が更新する責任はないものの、総力を計算するために必要な粒子の位置を指します。 。ホスト側では、2 つのデバイスの使用により発生するメモリ管理と同期の問題に関連する顕著な変更があります。
  
  
• 00:50:00 このセクションでは、2 つの GPU で粒子シミュレーションを実行するためにカーネル コードに加える必要がある変更について説明します。キャッシュ パーティクルの位置をめぐるループは以前と同じですが、21 行目より前で、ループは GPU が所有するローカル パーティクルの位置をめぐるようになりました。次に、他の GPU が更新を担当するリモート パーティクルに対してコードが繰り返されます。パーティクルの位置と速度を更新するコードは同じままです。 2 つの GPU のホスト コードを変更する場合、初期化は同じですが、パーティクルの半分を保持するパーティクルの位置と速度の配列も割り当てられます。A と B は 2 つの GPU を表します。元のサイズの半分だけのインデックス空間を持つ計算ドメインが作成され、引数ポインタを速度配列に静的に設定するコードが削除されます。
  
  
• 00:55:00 このセクションでは、ハーフサイズの配列をそれぞれの GPU にコピーするときに、データがどの GPU に書き込まれるかを定義するために、デバイス ID を設定する方法を学びます。また、複数の GPU 間でデータを交換するには、更新されたパーティクル位置を表す半分のサイズのパーティクル配列を切り替えることで、更新されたパーティクル位置を GPU に同期させる必要があることもわかります。また、OpenCL の一部の実装では、真の同時実行のために CL フラッシュ呼び出しを導入する必要がある場合があることもわかりましたが、これは標準の一部ではありません。
  
  
• 01:00:00 このセクションでは、プレゼンターは、2 つの配列間で古い粒子の位置と新しい粒子の位置を交換するダブル バッファー スキームを実装するコードを確認します。このスキームにより、更新されたパーティクルの位置が配列 A または B のいずれかに戻されます。パーティクルがホストに同期されたら、ヘルパー関数の一部を再利用するために、パーティクルをより大きな配列にコピーして戻す必要があります。発表者は、OpenCL プログラマに必要なリソースとして OpenCL 標準を推奨し、その標準と ATI Stream SDK の URL を提供します。発表者はまた、OpenCL が特異値分解や非負行列因数分解などのアルゴリズムに使用できるかどうかに関する質問に答え、GPU 上のグローバル メモリ内のデータがカーネル実行間で同じままであることを確認しました。これは、より複雑なアルゴリズムにとって重要です。
  
  
• 01:05:00 このセクションでは、ビデオで OpenCL API の現在の制限について説明します。OpenCL API は Unix/Linux システムのみをサポートし、Windows への移植に向けて開発が進められています。このビデオでは、GPU とホスト間のメモリ共有の問題についても取り上げており、可能ではあるもののパフォーマンスが低下するため、グラフィックス カードに割り当てられたグローバル メモリを使用するのが一般的であると説明しています。 OpenCL API を通じてメモリを割り当てる場合、その処理方法を制御する方法がありますが、その一部は実装レベルで自動的に行われます。さらに、ビデオでは、メモリ割り当てにおけるグローバル ポインタとローカル ポインタの違いと、最適なコア数の選択が実行されるアルゴリズムにどのように依存するかについて説明しています。
  
  
• 01:10:00 このセクションでは、FTL FGL RX モジュールをロードして実行するかどうか、Lib 標準 CL と C++ バインディングの互換性、パフォーマンス向上のための OpenCL カーネルの最適化、およびCL mem を読み取り専用で使用するか、メモリー バッファーを割り当てるときに読み取り/書き込みをシールします。講演者はまた、OpenCL カーネルを編集し、AMD GPU 向けに最適化するための特定のツールが存在する可能性があることを指摘する一方で、最適化技術は非常に微妙で多くの調整が必要になる可能性があることにも言及しました。
  
  
• 01:15:00 このセクションでは、ベクトル演算を利用するためのデータの編成、パフォーマンス向上のためのメモリ アクセスの慎重な制御、最適化のためのループの手動展開など、OpenCL プログラミングの最適化テクニックについて講演者が説明します。さらに、複雑なデータ型の使用と、ホストに戻らずに GPU 間でデータを転送する機能は実装固有であり、コンパイラによって異なる場合があります。講演者は、システム内の OpenCL デバイス間で利用可能なメモリに依存するメモリ バッファのサイズ制限があることにも言及しました。パフォーマンスを向上させるために、より単純な浮動小数点数パラメータを定数メモリに保存できる場合があります。
  
  
• 01:20:00 このセクションでは、計算ユニットの使用率やメモリ転送の使用率を測定するプロファイリング ツールなど、OpenCL 実装を分析するためにさまざまな SDK で利用できるツールがあることを講演者が説明します。講演者はまた、GPU 側でのメモリ断片化の管理は実装に固有であり、実装側で適切に管理する必要があることも明確にしています。倍精度を使用する場合、ローカル ワーク グループ サイズを 32 に下げるか 16 に下げるかについては、使用されているアーキテクチャに依存するため、明確な答えはありません。講演者は、標準 GPU コンテキスト内のすべてのデバイスに関する情報を簡単に取得するためのヘルパー呼び出しの可用性についても言及しました。

[MetaQuotes]

AMD デベロッパー セントラル: OpenCL プログラミング ウェビナー シリーズ。 5. 現実世界の OpenCL アプリケーション

5 - 現実世界の OpenCL アプリケーション

このビデオでは、Joachim Deguara が、パフォーマンスの最適化に重点を置いて、彼が取り組んだマルチストリーム ビデオ処理アプリケーションについて語ります。このビデオでは、ビデオ形式のデコード、DMA を使用した CPU と GPU 間のメモリ転送、ダブル バッファリング、カーネルの実行、イベント オブジェクトを使用した操作の同期とプロファイル、OpenCL と OpenGL の相互運用、ビデオでのスワイプの処理、次のいずれかの選択など、さまざまなトピックを取り上げています。アルゴリズムを処理する場合は OpenCL および OpenGL。 Joachim 氏は、OpenCL アプリケーションで利用できるさまざまなサンプリングと SDK についても説明していますが、ビデオで説明されている特定のアプリケーションで利用できるサンプル コードは現時点では存在しないことに注意してください。

• 00:00:00 このセクションでは、Joachim Deguara が取り組んだマルチストリーム ビデオ処理アプリケーションについて説明します。このアプリケーションには、複数のビデオ ストリームを開いてデコードし、ビデオ効果を適用して結合し、最後に繰り返し処理される 1 つのビデオ ストリームを表示することが含まれます。 Joachim Deguara 氏は、このアプリケーションではパフォーマンスが重要な焦点であり、リアルタイム プレゼンテーションを実現するには、デコード、処理、表示を 1 秒あたり 30 回発生するループ構造または入力ビデオのフレーム レートに適合させることが不可欠であると述べています。 。
  
  
• 00:05:00 このセクションでは、ビデオ形式のデコードとフレームの GPU への移動に焦点を当てます。ビデオ形式をデコードするには、パフォーマンスに影響を与えないように、これをできるだけ高速に実行する必要があります。これを行う 1 つの方法は、デコード関数をメイン ループとは別に実行し、呼び出されたときに最新のフレームを返すようにすることです。これにより、メイン ループが中断されることなく継続されている間、デコードがバックグラウンドで実行されることが保証されます。フレームを GPU に移動するには、書き込むイメージの指定と、書き込みを同期的に行うか非同期的に行うかを指定する API 呼び出しが使用されます。
  
  
• 00:10:00 このセクションでは、講演者は DMA (ダイレクト メモリ アクセス) と、CPU がメモリをコピーせずにシステムのメイン メモリと GPU のメモリ間でメモリを転送するために DMA (ダイレクト メモリ アクセス) を使用する方法について説明します。 DMA エンジンはこの操作を並行して処理し、CPU と GPU のリソースを解放します。バッファと画像の転送は非同期で実行でき、特別なフラグが必要です。ただし、コピー後すぐにデータを使用できるわけではないため、DMA を利用できるようにプログラムを再構築する必要があります。講演者は、現在処理されているデータや表示されているデータの破損を避けるために、ダブル バッファリングとループ プロセスの再構築を提案しています。全体として、DMA は CPU と GPU サイクルをオフロードすることでアプリケーションのパフォーマンスを大幅に向上させることができます。
  
  
• 00:15:00 このセクションでは、講演者が、OpenCL でビデオのフレームを処理および表示するために使用されるダブル バッファリング アプローチについて説明します。このアプローチでは、2 つのフレーム A と B を常にバッファリングし、一方をアップロードしている間にもう一方を処理します。これにより、処理時間とアップロード時間を加算する必要がなくなり、どちらかのプロセスにかかる最大時間だけがかかります。講演者は、カーネルの引数の設定についても説明します。これは一度行うだけでよく、パラメータを変更する必要がない場合は、その後のすべての処理実行に使用できます。
  
  
• 00:20:00 このセクションでは、講演者はカーネルの実行方法について説明し、ブロッキング メソッドとノンブロッキング メソッドを含む、処理を呼び出す 2 つの方法について言及します。ブロックするとデバッグが容易になりますが、パフォーマンスにとっては最適ではないため、講演者は、イベントとイベントのベクトルを使用して操作を待機したり、複数の操作の依存関係グラフを設定したりするオプションを紹介しました。イベント オブジェクトを使用して特定の作業項目の完了を通知することにより、それらの作業が完了した後にのみダウンストリーム操作が開始されるようになり、より効率的な処理が可能になります。
  
  
• 00:25:00 このセクションでは、講演者が OpenCL イベント オブジェクトを使用して操作を同期する方法と、イベント プロファイリングをパフォーマンス テストに使用する方法を説明します。フィルターの依存関係グラフを作成するとき、イベントへのポインターはエンキュー操作の最後の引数として渡されますが、イベント オブジェクトは InQ 内に作成されます。これにより混乱が生じる可能性がありますが、フィルタとアップロード操作の間の依存関係を設定できるようになります。講演者は、イベント プロファイリングを使用して、イベント参照の操作がキューに入れられたとき、送信されたとき、実行を開始したときなど、イベントのライフ サイクル内で特定のイベントがいつ発生したかに関するタイムスタンプをイベントから取得する方法について説明しました。そして走行を完了しました。これにより、すべての操作を非同期に保ちながらプロファイリングが可能になります。
  
  
• 00:30:00 ビデオのこのセクションでは、講演者が、OpenCL の使用時にイベントが通過するさまざまな状態 (キュー登録、送信済み、実行中、完了など) と、イベント プロファイル データとタイムスタンプを使用してパフォーマンスを測定する方法について説明します。操作やデータのアップロードの実行時間の長さなどの潜在的な問題を特定します。講演者は、さまざまなフィルターやエフェクトを使用してビデオ ストリームを正確に表示するために、イベントが完了するのを待つ方法についても説明します。
  
  
• 00:35:00 このセクションでは、講演者が OpenCL と OpenGL の相互運用性について説明します。これにより、両者間で特定の情報を共有できるようになります。この機能はオプションであるため、すべての実装がこの機能をサポートする必要はありません。講演者は、拡張機能をチェックし、特定のフラグを使用して OpenCL でコンテキストを作成し、OpenCL-OpenGL 相互運用を有効にすることの重要性を強調しました。これは、すでに作成されている OpenGL テクスチャから OpenCL イメージを作成することで機能するため、データが不必要に前後にコピーされることはありません。
  
  
• 00:40:00 このセクションでは、OpenCL と OpenGL が Interop を通じてどのように画像データを共有できるかを講演者が説明します。これらは、Open GL テクスチャを参照するために必要なターゲット、NIP レベル、およびテクスチャ オブジェクトをカバーします。 OpenCl イメージを作成すると、通常の OpenCl イメージとして使用できますが、2 つのプログラムは相互に干渉しないようにハンドシェイクを行う必要があります。講演者は、ビデオ レンダリングでトランジションを作成する方法に関する質問にも答えます。スワイプの位置をフィルターへの入力として使用することで実現できると彼は言います。最終的に、最終結果は表示目的で OpenGL に引き渡され、これですべての手順が完了します。
  
  
• 00:45:00 このセクションでは、スピーカーが、各フレームのタイム マーカーを確認し、キーフレームを使用してスワイプの位置を補間することにより、ビデオ内のスワイプを処理する方法を説明します。また、OpenCL でのプロファイリングに関する質問にも答えており、タイムスタンプは外部の高解像度タイマーに依存するが、CLfinish の呼び出しには依存しないと述べています。さらに、講演者は OpenCL デバイスとランタイムでの実行順序について説明し、ほとんどのデバイスで操作が順序どおりに処理されることを確認します。
  
  
• 00:50:00 このセクションでは、講演者がアルゴリズムを処理する際の OpenCL と OpenGL の違いについて説明します。どのプラットフォームを使用するかの決定は個人の好みによって異なりますが、OpenCL はその包括的な言語構造によりプログラミングが容易である可能性があります。パフォーマンスの点では、OpenCL を使用すると、より複雑なハードウェアを必要とするアプリケーションを処理できる可能性があります。ただし、OpenGL シェーディングを使用するとパフォーマンスが向上する場合があります。さらに、講演者は特定のアプリケーション向けに利用可能なサンプル コードを提供できませんでしたが、AMD の OpenCL SDK にはユーザーが学習できるさまざまなコード例があります。
  
  
• 00:55:00 このセクションでは、開発者が OpenCL アプリケーション用に利用できるさまざまなサンプルと SDK について講演者が説明します。このサンプルでは、デバイスとランタイムをクエリして拡張機能を取得する方法と、OpenCL OpenGL の相互運用の例を示します。ただし、ビデオで説明されている特定のアプリケーション用に現在利用できるサンプル コードはありませんが、これは将来変更される可能性があります。ウェビナーは終了し、録画が参加者に提供されます。

[MetaQuotes]

AMD デベロッパー セントラル: OpenCL プログラミング ウェビナー シリーズ。 6. OpenCL 用の Device Fission 拡張機能

6 - OpenCL 用の Device Fission 拡張機能

このビデオでは、講演者が OpenCL のデバイス分裂拡張機能に関連するさまざまなトピックを取り上げています。さまざまなタイプの拡張機能と、デバイスの分裂によって大きなデバイスを小さなデバイスに分割する方法について説明します。これは、優先度の高いタスク用にコアを予約したり、特定のワーク グループを特定のコアに確実に割り当てたりするのに役立ちます。彼らは、ベクトル プッシュバック操作を並列化するとき、並列パターンを使用してプロセスを最適化するとき、および OpenCL でネイティブ カーネルを作成するときにシーケンシャル セマンティクスを保持することの重要性について説明します。講演者はまた、OpenCL のデバイス分裂を利用するアプリケーションをデモンストレーションし、メモリ アフィニティと他のデバイスでのデバイス分裂の将来について説明します。

• 00:00:00 このセクションでは、講演者は OpenCL の拡張機能、特に 3 つの異なるタイプの拡張機能 (KHR 拡張機能、EXT 拡張機能、およびベンダー拡張機能) について説明します。 KHR 拡張機能は OpenCL ワーキング グループによって承認されており、一連の適合テストが付属しています。 EXT 拡張機能は少なくとも 2 人のワーキング グループ メンバーによって開発されており、適合性テストは必要ありません。 CL_AMD_printf などのベンダー拡張機能は単一のベンダーによって開発されており、そのベンダーによってのみサポートされる場合があります。すべての拡張機能のドキュメントは Chronos OpenCL レジストリ Web サイトで入手できるため、ベンダー間での透明性とアクセスが可能になります。
  
  
• 00:05:00 このセクションでは、講演者はデバイス ビジョンと呼ばれる OpenCL のデバイス フィッション拡張機能について言及しています。この拡張機能を使用すると、ユーザーは、名前またはメモリ アフィニティのいずれかによって、多くの計算ユニットを備えた大きなデバイスを小さな OpenCL デバイスに分割できます。この分割は、SMP ベースのシステムのように、優先タスク用にコアを予約したり、特定のワーク グループが特定のコアに割り当てられるようにしたりするのに役立ちます。講演者は、OpenCL 上に構築された並列アルゴリズムと並列コンテナの例を示してデバイス ビジョンの使用を促し、この拡張機能は現在 AMD と IBM の CPU および Cell Broadband デバイスでサポートされていると述べました。
  
  
• 00:10:00 このセクションでは、ベクトル プッシュバック操作を並列化しながらシーケンシャル セマンティクスを保持することの重要性について講演者が説明します。彼らは、逐次ループ中にベクトルに要素を挿入すると、期待される順序がループの関数として現れると説明しています。ただし、並列化すると、この順序は失われ、要素が順序どおりに挿入されない可能性があるため、講演者は、ベクトル プッシュバック操作の順次セマンティクスを保持することを提案しています。次に、これが MPEG-2 ストリームの簡易バージョンなどのアプリケーションでどのように重要になるかを例を挙げて説明します。彼らは、C 関数を導入し、これらの並列演算を CPU 上で実装する方法について説明して締めくくっています。
  
  
• 00:15:00 このセクションでは、講演者が並列パターンを使用して OpenCL プロセス用の Device Fission Extensions を最適化する方法を説明します。パイプライン パターンを使用して関数を並列実行し、入力データから読み取るデータ ブロックを導入して、ローカル メモリ内の 1 つの作業項目を処理します。次に、このアプローチでは、メールボックスのオフセットを対応するワークグループに書き込み、出力の順序を維持しながらオフセットを計算します。順序付けは、任意の順序で実行されるグローバル ID に依存するのではなく、ワークグループ間の通信を通じて実現されます。パイプライン パターンにより、関数が並行して実行され、プロセスが最適化されます。
  
  
• 00:20:00 このセクションでは、講演者が自社のパイプラインと、単に物事を数えるという枠を超えて、「カウンター」という用語をメールボックスとしてどのように使用しているかについて説明します。彼らは、メールボックスにインデックスを作成するためにグループ ID を渡し、単純な計算にローカル メモリとグローバル メモリを使用していると説明しています。ただし、ワークグループの実行には保証がないことを指摘し、これがどのようにしてデッドロック状況を引き起こす可能性があるかを説明しています。この問題に対処するために、講演者は、デバイス ビジョンを使用してデバイスを 2 つの別々のコアに分割し、各コアで 1 つのワークグループを起動し、進捗を保証することを提案しています。また、ホスト デバイス上で実行するために OpenCL によって提供される重要なメカニズムも導入されています。
  
  
• 00:25:00 このセクションでは、講演者が、任意の C または C++ 関数の実行を可能にする OpenCL でネイティブ カーネルを使用する利点について説明します。これにより、さまざまな実装を試す際の柔軟性が向上するほか、標準 I/O ルーチンや OpenCL では利用できない他のライブラリ関数を呼び出す機能も提供されます。 OpenCL でネイティブ カーネルを作成するプロセスには、コマンド キューと関数をその引数とメモリ オブジェクトとともに渡すことが含まれます。ただし、関数が組み込まれたときと同じスレッドで実行されない可能性があるため、スレッド ローカル ストレージの場合は注意が必要です。講演者は、C API の上にいくつかの抽象化を提供する OpenCL C++ バインディング API も紹介します。プログラムは、利用可能なプラットフォームを照会し、コンテキストとデバイス タイプを作成することから始まります。
  
  
• 00:30:00 このセクションでは、講演者が OpenCL のデバイス分裂拡張機能の使用について説明します。有効なデバイスがクエリされると、デバイスのリストが返され、デバイスの分裂をサポートするために最初のデバイスが選択されます。デバイスの分裂は OpenCL API の新機能であり、パーティションの記述を可能にする拡張メカニズムが必要です。パーティションを均等に使用して、1 つ単位のデバイスに分割します。次に、サブデバイスのプロパティが設定され、サブデバイスの作成関数が呼び出されます。少なくとも 1 つのサブデバイスが作成されると仮定して、デバイスごとにメールボックスが作成され、コマンド キューが作成されます。結果として得られるデバイスは他のデバイスとまったく同じであり、既存のライブラリと互換的に使用できます。次に、講演者はネイティブ OpenCL カーネルのセットアップに進みます。
  
  
• 00:35:00 このセクションでは、講演者が OpenCL の Device Fission 拡張機能の実装に必要な入力と引数について説明します。講演者は、入力のメモリ バッファが 4 つの部分に分割され、FN c ランタイムによってポインタがそこに配置されると説明しました。メモリ バッファはメールボックス、ブロック、キャッシュ トランザクションで構成され、カーネルごとに一意の ID が生成されます。講演者はさらに、カーネルの各インスタンスは個別のデバイス上で実行され、すべてのイベントが完了すると、パディングが挿入されたデータが書き込まれると説明しました。カーネル自体には、効率的な実行を確保するためのブロックとキャッシュに関連する最適化が含まれます。
  
  
• 00:40:00 このセクションでは、講演者が OpenCL のデバイス分裂を利用するアプリケーションの実装について説明します。入出力、メールボックス、ローカル ブロック配列、ブロック サイズ、グループ ID などのさまざまなタイプを使用して、データ セットに並行してインデックスを付けるアプリケーションがどのように機能するかについて説明します。また、アプリケーションは、すべてが可能な限り並行して実行されるようにするために、単純なビジー待機およびブロックの最適化も実装しています。デバイスの分裂を利用することにより、このアプリケーションの実装は、ALU 演算をほとんどまたはまったく行わずに CPU の高速化を達成できる可能性を示しており、将来的にはより幅広いベクトルの実装でさらに高速化する可能性があります。講演者は、無限および Numa 空間システムに関する分割など、デバイス分裂の他のアプリケーションとユースケースについても説明します。
  
  
• 00:45:00 このセクションでは、講演者が OpenCL のメモリ アフィニティの利点について説明します。これにより、バッファと特定のデバイスの正確な関連付けが可能になります。これにより、競合やネガティブ シェアリングが回避され、キャッシュの局所性が向上し、パフォーマンスが向上します。 OpenCL で使用されるメールボックス スキームは複数の反復をサポートするように拡張でき、ウォーターフォール パイプラインを何度も開始するループを可能にします。講演者はまた、developer.amd.com の OpenCL ゾーンでリソースが利用可能であることにも言及しました。このゾーンでは、興味のある人は、ウェビナー、過去のプレゼンテーション、ヘテロジニアス コンピューティングに関する今後のサミットなど、OpenCL に関する詳細情報を見つけることができます。講演者はまた、将来的には GPU 上でデバイスの分裂をサポートする可能性についても示唆しています。これにより、コアの一部が優先度の高いタスク用に予約され、パフォーマンスの向上が保証されます。
  
  
• 00:50:00 ビデオのこのセクションでは、講演者が他のデバイスに向けて進むデバイスの分裂の将来について説明します。現在、OpenCL のデバイス Fission 拡張機能をサポートしているのは AMD と IBM だけですが、他のベンダーもこの提案に関心を示しています。 BLAS や FFT などの数学ライブラリがサポートされるかどうかについて疑問が生じ、講演者は、BLAS と、FFT スタイルのライブラリで提供される線形代数のさまざまなバリアントおよび実装の両方の OpenCL 実装に取り組んでいることを確認しました。

[MetaQuotes]

AMD デベロッパー セントラル: OpenCL プログラミング ウェビナー シリーズ。 7. 平滑化された粒子の流体力学

7 - 平滑化された粒子の流体力学

このビデオでは、流体力学方程式、特にナビエ・ストークス方程式を解くための手法である平滑化粒子流体力学 (SPH) について説明します。このビデオでは、密度、圧力、粘度の項を含む方程式内のさまざまな項と、それらがスムージング カーネルを使用して近似される方法について説明しています。 SPH に使用される数値アルゴリズム、および空間インデックスと相互運用機能の使用についても説明します。講演者は、空間インデックスと近隣マップを構築するプロセスと、物理がどのように計算されるかについて説明します。このビデオでは、視聴者にプログラムをダウンロードして使用するよう促し、シミュレーションの制限について説明しています。次に、講演者は、GPU のパフォーマンス、非圧縮の動作、キャッシュされたイメージの使用に関する聴衆からの質問に答えます。

• 00:00:00 このセクションでは、AMD のテクニカル スタッフのシニア メンバーである Alan Hierich が、数値流体力学、特に平滑粒子流体力学 (SPH) の概要を説明します。 SPH はもともと天体物理学の計算に使用されていましたが、ビデオ ゲームやシミュレーションでも非常に人気があります。この技術は、1900 年代に定式化された偏微分方程式であり、今日のほとんどの流体力学の基礎となっているナビエ・ストークス方程式を解くために使用されます。アレンは、液体と気体に焦点を当てて、流体の定義を説明し、それらがどのように機能するかを直感的に説明します。また、流体は一般にナビエ・ストークス方程式によって記述され、非圧縮性のナビエ・ストークス方程式は通常の速度および通常の温度の水のような流体を支配することも概説しています。
  
  
• 00:05:00 このセクションでは、ナビエ・ストークス方程式として知られる、流体を支配する方程式について講演者が説明します。運動方程式は重力、圧力、粘度の関数として速度の変化を表しますが、質量連続方程式は質量が生成も破壊もされないことを示しています。流体を支配する現象は重力、圧力、速度であり、粘度は流体の粘着性であり、流体粒子が同じ方向に移動する可能性を決定します。対流加速項についても説明します。これは、庭のホースのノズルなど、小さな開口部を通過する流体の加速を表します。講演者は、デモされたボックス内の流体をシミュレートするプログラムをダウンロードして遊んでみるように聴衆に勧めます。
  
  
• 00:10:00 このセクションでは、対流加速度、圧力勾配、粘度など、流体力学の運動方程式のさまざまな用語について講演者が説明します。圧力は、ある点における流体の実際の密度と静止密度との差として定義されます。運動方程式の右辺の最後の項である粘性項はシステムの運動量を拡散し、最終的にはすべての場所で速度が等しい状態になります。また、質量連続方程式、del dot V が 0 に等しいというものもあります。これは、非圧縮性方程式では質量が生成も破壊もされないことを意味します。最後に、システムのダイナミクスを表すために、話者は方程式の材料導関数を取得して、粒子の運動方程式を取得します。
  
  
• 00:15:00 このセクションでは、ビデオでは、前のセクションで紹介した単純化された非圧縮性ナビエ・ストークス方程式を解くための平滑化粒子流体力学 (SPH) 手法について説明します。 SPH 手法は、天体物理学と銀河の研究のために 1992 年に初めて導入されましたが、流体方程式にも使用できます。これには、量のスムージング カーネル表現の導入が含まれます。これは、近傍の点での量の合計と重み付け関数を乗算することによって任意の量を近似できる基底関数のようなものです。 SPH 手法は、ナビエ・ストークス方程式の密度および圧力勾配項を近似するために使用されます。このビデオでは、ナビエ・ストークス方程式はスケールに数値的に敏感であり、粒子を空間内で移動させるために通常の空間スケールに拡張する前に、より小さなスケールで計算が行われることにも言及しています。
  
  
• 00:20:00 このセクションでは、平滑化粒子流体力学 (SPH) で近似される 3 つの主要な項、つまり密度、圧力、粘度の項について講演者が説明します。密度を計算するために、プログラムはさまざまな点で粒子の質量を計算し、それにスムージング カーネルの勾配を乗算します。次に、圧力のスカラー量を密度で割った値に平滑化カーネルの勾配を乗じて、圧力項が計算されます。一方、粘性項は、流体の粘性のレベルと、2 点間の速度の差を点 J の密度で割った値を決定するスカラー係数を使用して近似されます。講演者は、スムージング カーネルの特性についても説明します。 SPH シミュレーションで使用される値と、半径 H の球上での合計が 1 になる方法。
  
  
• 00:25:00 このセクションでは、講演者が平滑化粒子流体力学 (SPH) に使用される数値アルゴリズムについて説明します。このアルゴリズムには、密度、圧力、圧力勾配、粘性項、加速度の計算が含まれており、これらは粒子の速度と位置をタイムステップ化するために使用されます。講演者は、最初のアルゴリズムにはすべての粒子に対するすべての粒子の相互作用のテストが含まれており、これは正しいが、十分な速度ではないと説明しました。そこで、空間をボクセルに分割し、相互作用半径内の粒子のみとの相互作用を可能にする、より優れたアルゴリズムが導入されました。さらに、相互作用を計算するためにすべての粒子を考慮するのではなく、粒子のサブセットがランダムに選択されるため、効率的なプログラムが生成されます。
  
  
• 00:30:00 このセクションでは、講演者は、OpenCL シミュレーションで限られた数のパーティクルとの相互作用のみを計算するための空間インデックスの使用法と、Interop を使用してデータ バッファーをグラフィックス システムと共有することの重要性について説明します。 Interop を使用すると、GPU バッファーから直接レンダリングでき、グラフィックス メモリのスペースが節約されますが、Interop がないと、プログラムはデータをホスト メモリにコピーしてから戻す必要があり、シミュレーションが大幅に遅くなります。講演者は、別のコンテキストの作成など、Interop の使用に必要な変更について説明し、ソート用のパーティクル インデックスなど、シミュレーションに必要なバッファのセットを紹介します。 Interop の重要性について議論しているにもかかわらず、示されているプログラムは Interop を利用していないため、シミュレーションが遅くなります。
  
  
• 00:35:00 このセクションでは、講演者が平滑化粒子流体力学アルゴリズムで使用されるさまざまなカーネルについて説明します。最初のカーネルは「ハッシュ パーティクル」で、パーティクルをボクセルに関連付けます。次に、「ソート」および「パス後のソート」カーネルは粒子をボクセルにソートし、空間インデックス構築のためにそれらを整理します。次に、「インデックス」および「インデックス ポスト パス」カーネルは、ボクセルからパーティクルまでの空間インデックスを構築します。その後、「ファインネイバー」カーネルは、どのネイバーが相互に対話するかを決定します。最後に、「密度圧力の計算」、「加速度の計算」、および「統合」カーネルは、粒子間の相互作用と物理学を計算します。講演者は、GPU バージョンのコードでは基数ソートが使用され、CPU バージョンのコードでは Q ソートが使用されると説明しました。
  
  
• 00:40:00 このセクションでは、ビデオでは、平滑化粒子流体力学 (SPH) でボクセルから粒子までの空間インデックスを構築するプロセスを説明します。カーネルは二分探索を使用して各ボクセル内の最小番号のパーティクルを識別し、パーティクルを含まないボクセルには負の 1 の値を残します。次に、インデックス ポストパスは、グリッド セル インデックス内の次の空ではないボクセルの値をコピーすることによって、空のボクセルのインデックス値を埋めます。インデックス付けが完了すると、プログラムは各粒子を囲む 2 x 2 x 2 のボクセルの局所領域を検索して近傍マップを構築します。バイアスを排除するために、プログラムは各ボクセルにランダムなオフセットを生成し、検索の方向を交互に切り替えます。次に、カーネルは相互作用半径内の最初の 32 個の粒子を選択し、それらを近傍マップに追加します。
  
  
• 00:45:00 このセクションでは、講演者が、32 個の粒子と相互作用できる近傍マップを構築することで物理をどのように計算したかについて説明します。彼らは、密度と圧力を近似するために使用される方程式を検討し、加速度項を計算し、すべてを組み合わせて総加速度を決定します。次に、粒子がボックスから逃げるのを防ぐために境界条件が設定され、速度と位置が数値積分によって進められます。講演者は視聴者にソースコードをダウンロードして遊んでみるよう促し、ナビエ・ストークス方程式を解くには遅い方法がたくさんあるが、遅いことが必ずしも良いことを意味するわけではないことを強調した。
  
  
• 00:50:00 ビデオのこのセクションでは、スピーカーがシミュレーションの更新ステップについて説明します。このステップでは、位置を更新する前に速度が新しい位置に統合されます。速度の更新は明示的ですが、位置の更新は次のタイム ステップでの速度の値を使用して半暗黙的です。シミュレーションはパフォーマンス上の理由から float ですが、高い忠実度と精度が必要な場合は double を使用することをお勧めします。このアルゴリズムは完全に並列化可能ですが、空間分割のトレードオフを考慮する必要があります。最後に、講演者は、複数の GPU での Interop の使用、乱気流のシミュレーション、およびシミュレーションでの実際の最大粒子数に関する質問に答えます。
  
  
• 00:55:00 このセクションでは、講演者が聴衆からのいくつかの質問に答えます。彼らは、シミュレーションの実際的な制限はパフォーマンス レートであり、それは使用される GPU と CPU のクラスに依存すると説明しています。また、彼らのシミュレーションは非圧縮性方程式に基づいているが、非圧縮性条件を明示的に解いていないため、圧縮性挙動が制限される可能性があるとも述べています。講演者はまた、キャッシュされた画像メモリの代わりにバッファを使用した理由に関する質問に答え、プログラムを開発した時点では、キャッシュされた画像を使用することによるパフォーマンス上の利点は見出せなかったと述べています。ただし、OpenCL は将来的にキャッシュされたバッファーのサポートを提供する予定であり、それらをサポートするためにプログラムを変更する可能性があると述べています。全体として、講演者は聴衆に対し、プログラムをダウンロードして、制限がないので好きなように使用するよう勧めています。

[MetaQuotes]

AMD デベロッパー セントラル: OpenCL プログラミング ウェビナー シリーズ。 8. 最適化手法: 画像畳み込み

8 - 最適化テクニック: 画像畳み込み

このビデオでは、Udeepta D. Bordoloi が画像畳み込みにおける最適化手法について説明しています。

[MetaQuotes]

AMD Developer Inside Track: イメージ コンボリューションを最適化する方法

画像の畳み込みを最適化する方法

このビデオでは、ローカル データ共有の使用、定数の最適化、より大きなローカル領域を使用して効率を向上させるなど、画像畳み込みを最適化するためのさまざまな方法について説明します。講演者は、全体的なパフォーマンスを向上させるために画像畳み込みの処理時間を最小限に抑えることの重要性を強調し、ローカル メモリを使用してデータを再利用する新しい方法を強調しました。このビデオでは、明白なテクスチャやテクスチャの使用、思考力の使用、カウンターへのパス オプションの使用などの最適化手順についての提案が提供されています。画像畳み込み技術の最適化に関する段階的な記事は、開発者の AMD Web サイトで入手できます。

• 00:00:00 このセクションでは、AMD のグラフィックス チームの Udeepta Bordolo が、入力画像の領域に対して加重合計を実行して出力画像ピクセルを生成する画像畳み込みの概念について説明します。彼は OpenCL と 5870 GPU を使用して最適化を実行し、基本的な相関コードから段階的に作業を進めます。使用される最適化方法の一部としてミラーリングと LDS (ローカル データ共有) が使用され、実行時間が大幅に短縮されます。
  
  
• 00:05:00 このセクションでは、講演者は、すべてのフィルター サイズとすべての入力サイズで機能するプログラムでの画像畳み込みの最適化について説明します。彼はローカルエリアを利用してデータ共有を改善し、待ち時間を短縮することに重点を置いています。定数と入力を 128 ビット値として解釈することにより、コンパイラーとジーニーはコードをより簡単に解釈し、処理時間を短縮できます。彼は、定数を最適化し、より大きな局所領域を使用することで、画像畳み込みの効率が大幅に向上する方法を示しています。全体として、講演者は、全体のパフォーマンスを向上させるために、画像畳み込みの処理時間を最小限に抑える方法を見つけることの重要性を強調しています。
  
  
• 00:10:00 このセクションでは、フィルター サイズを決定することによって画像の畳み込みを最適化する方法と、さまざまなマスクに合わせてフィルター サイズを変更する方法について講演者が説明します。講演者は、最適化をさまざまなタイミングで適用するとパフォーマンスに影響を与える可能性があるが、予期しない問題を発見するのに役立つ可能性があると述べています。講演者は、フルフォースデータを使用して 2k x 2k の入力画像に対して同じ数の要素を実行することについても説明します。これにより、より効率的なデータ形式が得られます。さらに、講演者は、モーターを使用する代わりに、ハードウェアでは LDS として知られるローカル メモリを使用してデータを再利用する新しい方法を強調しました。
  
  
• 00:15:00 このセクションでは、講演者が画像畳み込み技術の最適化について話します。すべての入力をロードし、特定のグループだけ遅延させてから、明らかな作業を実行します。彼らは知っているとおりに現金を使い、LDS の使用をやめてテクスチャを使用しようとします。彼らは 2K × 2K の解像度とさまざまなフィルター サイズで実験を実施し、テクスチャを使用したときに最速の数値を取得しました。彼らは、明白なテクスチャの使用、思考力の使用、カウンターへのパスオプションの使用という最適化ステップを提案しています。また、可能であれば現金モンスターを使用することも推奨しています。画像畳み込み技術の最適化に関する段階的な記事を開発者の AMD Web サイトに公開しており、ビデオの隣にリンクされています。

[MetaQuotes]

AMD デベロッパー セントラル: OpenCL の技術概要。 OpenCL の概要

AMD デベロッパー セントラル: OpenCL の技術概要。 OpenCL の概要

このビデオでは、Michael Houston が、マルチコア CPU、モバイル デバイス、およびその他の形式のシリコンを対象としたデータ並列計算の業界標準である OpenCL の概要を説明します。 OpenCL は、CUDA や Brook+ など、これまで競合していた独自の実装を統合し、独立系ソフトウェア ベンダーの開発を簡素化することを目的としています。ここでは、デバイス上で実行されるコードと、ゲーム開発者とのフィードバック用に設計されたキュー システムを使用してデバイスを管理するコードとの間の内訳が示されています。 OpenCL はグラフィック API と連携して動作するように設計されており、写真やビデオの編集、人工知能システム、モデリング、物理学などのさまざまなアプリケーションに使用できるユビキタス コンピューティング言語を作成します。発表者はハリウッド レンダリングでの OpenCL の使用についても説明しており、この分野でのさらなる取り組みを期待しています。

• 00:00:00 このセクションでは、Mike Houston が、マルチコア CPU、モバイル デバイス、およびその他の形式のシリコンを対象とした、データ並列計算の業界標準としての OpenCL の目的について説明します。 OpenCL は、CUDA や Brook+ など、これまで競合していた独自の実装を統合し、独立系ソフトウェア ベンダーの開発を簡素化することを目的としています。 OpenCL には異なる方言や小さな違いがありますが、CUDA などの他のデータ並列言語からの移行は直接的かつ迅速です。 OpenCL は、デバイス上で実行されるコードと、ゲーム開発者とのフィードバック用に設計されたキュー システムを使用してデバイスを管理するコードの間の内訳も提供します。グラフィックス API と連携して動作するように設計されており、写真やビデオ編集などのアプリケーションにおける消費者向けのユビキタス コンピューティング言語を作成します。
  
  
• 00:05:00 このセクションでは、画像や高解像度ビデオの処理、ウイルス スキャナの実行など、OpenCL の初期の使用法のいくつかを講演者が説明します。さらに、このテクノロジーは、人工知能システム、モデリング システム、物理学、後処理、映画のライティングとレンダリングの高速化にも役立ちます。講演者は、特にハリウッド レンダリングでの OpenCL の使用に関するさらなる取り組みを期待しています。

[MetaQuotes]

AMD デベロッパー セントラル: エピソード 1: OpenCL™ とは何ですか?

AMD デベロッパー セントラル:エピソード 1: OpenCL™ とは何ですか?

このビデオでは、OpenCL とその設計目標の概要を説明します。この設計目標は、さまざまなプロセッサを活用して逐次計算ではなく並列計算を高速化することに重点を置いています。 OpenCL を使用すると、カーネル、グローバルおよびローカル ディメンション、およびワーク グループを使用して、さまざまなプロセッサ向けに移植可能なコードを作成できます。ワークアイテムとワークグループはリソースを共有することで共同作業できますが、異なるワークグループ内のワークアイテム間で同期することはできません。最適な問題の次元は処理の種類によって異なり、最高のパフォーマンスを得るには最適な次元を選択することが重要です。 OpenCL は、OpenCL イベント モデルを使用してタスクとデータの並列処理を一緒に表現することで、システムの機能を最大限に活用できます。

• 00:00:00 このセクションでは、Justin Hensley が OpenCL の基本とその設計目標について説明します。主に、CPU、GPU、またはセル ブロードバンド エンジンや DSP などのその他のプロセッサを活用して、並列計算を高速化することに焦点を当てています。シーケンシャルな処理により、劇的なスピードアップが実現します。 OpenCL を使用すると、並列処理を活用するために使用される C 関数に似たカーネルと、カーネルとその他の関数のコレクションであるプログラムを使用して、AMD CPU や GPU などの任意のプロセッサ タイプで実行する移植性の高いコードを作成できます。アプリケーションは、以下を使用してカーネル インスタンスを実行します。キューに入れられ、順番または順不同で実行されるキュー。 OpenCL のグローバル ディメンションとローカル ディメンションは計算の範囲を定義しますが、OpenCL の要点は、高度な並列デバイスを使用して計算を同時に高速化することであり、グローバル ワークアイテムは同期のみ可能で独立している必要があるため、ローカル ワーク グループがリソースを共有して共同作業できるようになります。作業グループ内で。
  
  
• 00:05:00 このセクションでは、作業項目とワークグループについて、また OpenCL でバリアやメモリ フェンスを使用してワークグループ内の作業項目間を同期する方法について学びます。ただし、異なるワークグループ内の作業項目は相互に同期できません。最適な問題のディメンションも処理の種類によって異なります。最高のパフォーマンスを得るには、特定の問題に最適なディメンションを選択することが重要です。 OpenCL では、OpenCL イベント モデルを使用して単一のワークアイテムをタスクとして実行することにより、タスクの並列性を表現することもできます。タスクとデータの並列処理を連携させることで、OpenCL はシステムの機能を最大限に活用できます。