6

OMAP3430 のビデオ コーデックに取り組んでいます。私はすでに C++ で記述されたコードを持っており、DSP (私が持っている SDK (OMAP ZOOM3430 SDK) には追加の DSP があります) を利用するために、その特定の部分を変更/移植しようとしています。

非常に少量のデータ (〜 250 バイト) で実行されている小さな for ループを移植しようとしましたが、異なるデータでは約 2M 回です。しかし、CPU と DSP 間の通信による過負荷は、ゲインよりもはるかに大きい (もしあれば)。

このタスクは、通常のコンピューターで GPU のコードを最適化するのとよく似ていると思います。私の質問は、どのような部品を移植すると有益でしょうか? GPU プログラマーはそのようなタスクをどのように処理するのでしょうか?

編集：

  1. GPP アプリケーションは、サイズ 0x1000 バイトのバッファーを割り当てます。
  2. GPP アプリケーションは、DSPProcessor_ReserveMemory を呼び出して、自動ページ アライメントを考慮して、割り当てられたバッファーよりも 4K 大きいサイズを使用して、割り当てられたバッファーごとに DSP 仮想アドレス空間を予約します。合計予約サイズも、4K ページ境界に沿って配置する必要があります。
  3. GPP アプリケーションは、DSPProcessor_Map を呼び出して、割り当てられた各バッファーを、前の手順で予約された DSP 仮想アドレス空間にマップします。
  4. GPP アプリケーションは、GPP 上に割り当てられたバッファにマッピングされた仮想アドレス空間のベース アドレスを DSP 実行フェーズに通知するメッセージを作成します。GPP アプリケーションは、DSPNode_PutMessage を使用してメッセージを DSP に送信します。
  5. GPP は memcpy を呼び出して、処理対象のデータを共有メモリにコピーします。
  6. GPP アプリケーションは DSPProcessor_FlushMemory を呼び出して、データ キャッシュがフラッシュされたことを確認します。
  7. GPP アプリケーションは、バッファへの書き込みが完了し、DSP がバッファにアクセスできるようになったことを DSP 実行フェーズに通知するメッセージを準備します。メッセージには、バッファに書き込まれたデータの量も含まれているため、DSP はコピーするデータの量を把握できます。GPP は、DSPNode_PutMessage を使用してメッセージを DSP に送信し、DSPNode_GetMessage を呼び出して、DSP からメッセージが返されるのを待ちます。

その後、DSP プログラムの実行が開始され、DSP は処理が終了するとメッセージで GPP に通知します。試しに、DSP プログラム内には何も処理を入れていません。「処理が完了しました」というメッセージを GPP に送り返すだけです。そして、これにはまだ多くの時間がかかります。内部/外部メモリの使用が原因でしょうか、それとも単に通信の過負荷が原因でしょうか?

4

3 に答える 3

2

OMAP3430にはオンボードDSPがなく、システムバスに接続されたIVA2 +ビデオ/オーディオデコードエンジンがあり、CortexコアにはDSPのようなSIMD命令があります。OMAP3430のGPUは、PowerVRSGXベースのユニットです。プログラム可能なシェーダーがありますが、CUDAまたはOpenCLの汎用プログラミングはサポートされていないと思います。私は間違っているかもしれませんが、そのようなサポートについて聞いたことがありません

搭載されているIVA2+エンコード/デコードエンジンを使用している場合は、このユニットに適切なライブラリを使用する必要があり、私が知っている特定のコーデックのみをサポートします。このモジュールに独自のライブラリを書き込もうとしていますか？

Cortexの組み込みDSPish（SIMD命令）を使用している場合は、コードを投稿してください。

開発ボードに追加のDSPがある場合、DSPとは何ですか？OMAPにどのように接続されていますか？

デスクトップGPUの質問に関しては、ビデオデコードの場合、ベンダーが提供する関数ライブラリを使用してハードウェアを呼び出します。Linux上のNvidia用のVDAPU、Windows上の同様のライブラリ（PureViewHDと呼ばれると思います）がいくつかあります。ATIには、オンボードデコードエンジン用のLinuxライブラリとWindowsライブラリの両方があります。名前はわかりません。

于 2009-06-25T16:03:28.047 に答える
2

データ転送のタイム ベースが何であるかはわかりませんが、SDK のスペックシートに記載されている TMS32064x が非常に強力な DMA エンジンを備えていることは知っています。(元の ZOOM OMAP34X MDK だと思います。64xx があると書かれています。) OMAP にも同様の機能があり、それらを最大限に活用できることを願っています。64xx の内部 RAM に「ピンポン」バッファを設定し、SDRAM を DMA による転送処理で共有メモリとして使用することをお勧めします。外部 RAM は 6xxx シリーズのどの部品でもボトルネックになるため、パフォーマンスを向上させるために内部メモリにロックできるものは何でも保持してください。通常、これらのパーツは、内部メモリに入ると、8 つの 32 ビット ワードをプロセッサ コアにバス接続する機能を備えています。ただし、直接アクセス RAM としてマップできるレベルのキャッシュに基づいて、パーツごとに異なります。TI のコスト重視の部品は、「マッピング可能なメモリ」を他の一部のチップよりも遠くに移動します。また、部品のすべてのマニュアルは、TI から無料で PDF 形式でダウンロードできます。彼らは、TMS320C6000 CPU と命令セットのマニュアルやその他の多くの本のハードコピーを無料でくれました。

プログラミングに関する限り、実行中の計算を最適化するために、「プロセッサ組み込み関数」またはインライン アセンブリの一部を使用する必要がある場合があります。64xx では、浮動小数点コアが組み込まれていないため、可能な場合は整数演算を優先します。(これらは 67xx シリーズにあります。) 実行ユニットを見て、単一のサイクルで発生する可能性のある方法で、さまざまな部分がさまざまな操作を対象とするように計算をマッピングできる場合、最高のパフォーマンスを達成することができます。それらの部品の。命令セットのマニュアルには、各実行ユニットによって実行される操作の種類がリストされています。計算を 2 つのデータ フロー セットに分割し、ループを少し巻き戻すことができれば、完全な最適化がオンになっていると、コンパイラは「より適切」になります。

お役に立てれば。

于 2009-06-25T16:47:18.837 に答える
-1

私が行った測定によると、CPU と DSP 間の 1 つのメッセージング サイクルには約 160us かかります。これが私が使用しているカーネルによるものなのか、ブリッジ ドライバーによるものなのかはわかりません。しかし、これは単純なやり取りのメッセージには非常に長い時間です。

総計算負荷がメッセージングに必要な時間に匹敵する場合にのみ、アルゴリズムを DSP に移植することが合理的であるように思われます。アルゴリズムが CPU と DSP での同時計算に適しているかどうか。

于 2009-07-14T10:36:33.410 に答える