問題タブ [cuda-context]

PhysiXを使用して流体シミュレータを実装しています。残念ながら、sthはcuda context managerで間違っており、それが何であるかを認識するのに問題があります。私は次のようなinitメソッドを持っています：

アプリケーションを実行しようとすると、mCudaContextMangerが正しく作成されないことがあります。「cudaコンテキストマネージャーの作成に失敗しました」がコンソールに書き込まれ、次のようになります。

".... \ LowLevel \ software \ src \ PxsContext.cpp（1122）：警告：GPU操作が失敗しました。px::CudaContextManagerが利用できません。....\ SimulationController \ src \particles \ ScParticleSystemSim.cpp（73）：警告：GPUパーティクルシステムの作成に失敗しました。CPUの実装にフォールバックします。」

最新のドライバーを搭載したGeForce560Tiを使用しています（友人のラップトップのGeForce460にもエラーが表示されます）。Physixは、NVidiaコントロールパネルでGPUを使用するように設定されています。

私たちが何を間違えたのか、GPUを機能させる方法を知っている人はいますか？前もって感謝します！

Web のほとんどのチュートリアル、ガイド、書籍、Q&A は CUDA 3 および 4.x に言及しているようです。そのため、特に CUDA 5.0 について質問しています。質問に...

2 つの CUDA デバイスを備えた環境用にプログラムしたいのですが、設計を単純にするために 1 つのスレッドのみを使用します (特にプロトタイプであるため)。次のコードが有効かどうかを知りたい:

同じスレッドでcudaMalloc(...)交換が発生しても、テスト前の s が持続するかどうかを具体的に知りたいです。また、やcudaSetDevice()などのコンテキスト依存オブジェクトでも同じことが起こるかどうかを知りたいです。cudaEvent_tcudaStream_t

このスタイルのアプリケーションでマッピング エラーが発生し続けており、メモリ リークが不足していたり​​、API の使用法が間違っていたりすると、それが何であるかを見つけることができないため、私はそれを求めています。

注: 元のコードでは、すべての CUDA 呼び出しをチェックしています。コードを読みやすくするために、ここには入れませんでした。

最近、最も内側のループに CUDA を使用するために、非常にブーストに依存するプロジェクトを拡張し始めました。私が見た奇妙な行動についてここに投稿する価値があると思いました。特定のブースト ヘッダーを含めるだけで、最初の cuda 呼び出しで多数のカーネルが生成されます。

次のコードをコンパイルしてデバッグする場合: simplestCase.cu

cudaMalloc を実行すると、次のデバッグ メッセージ行が表示されます (定義したカーネルを実行した場合と同じ動作です。コンテキスト作成をトリガーするものはすべて、これをトリガーするようです)。

これまでのところ、問題を引き起こす 2 つのヘッダーを特定しました: boost/thread.hpp boost/mpi.hpp

問題を再現するのに役立つ情報を次に示します。

• IDE: nSight Eclipse エディション
• OS: Ubuntu 12.04 x64
• GPU: GeForce GTX 580 (私の OS は GeForce GT 520 を使用していると思います)
• ブースト ライブラリ: 1.52
• cat /proc/driver/nvidia/version:
  • NVRM バージョン: NVIDIA UNIX x86_64 カーネル モジュール 310.32 Mon Jan 14 14:41:13 PST 2013
  • GCC バージョン: gcc バージョン 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

プロジェクト設定:

• プロパティ - >ビルド - > CUDA - > DeviceLinkerMode =個別のコンパイル
• プロパティ->ビルド->CUDA->GenerateGPUCode = 2.0
• プロパティ -> ビルド -> 設定 -> ツール設定 -> NVCCLinker -> ライブラリ = boost_system
• プロパティ -> 名前 = simplest_case_example

それがすべてだと思います。

編集：

私が質問をしていなかったという事実に注意を向けてくれてありがとう。重要なことを忘れていたことに気づきました。私の質問はこれです：

特に私はこれらのインクルードを使用していないため、周辺カーネル呼び出しの生成に非常に具体的なインクルードが含まれていることは奇妙に思えます。CUDA との対話にどのように影響するかわかりません。cuda は、私が使用していないコードのために、これほど多くの余分なカーネルを起動する必要がありますか? 現在取り組んでいるプロジェクトで 100 を超えるカーネルが起動されていますが、プロジェクトにある CUDA 関連のコードはプログラムのエントリ ポイントにある単一の cudaMalloc だけです。

編集2:

また、Tesla K20 (ケプラー アーキテクチャ カード、GTX 580 はフェルミだと思います) でも発生します。

編集3:

cuda ドライバーをバージョン 319.23 に更新しました。上記の動作に変更はありませんが、これにより、大規模なプログラムで発生していたデバッガーの問題が修正されました。

同じ GPU を使用する異なるコンテキスト (CPU スレッド) 間で cudaMalloc の GPU バッファを共有することは可能ですか? 各コンテキストは、GPU 全体を使用して出力を配布する前処理カーネルによって満たされる必要がある入力バッファーを割り当てます。

このシナリオは、GPU との間で複数のデータ転送を回避するのに理想的です。アプリケーションは、複数のアンテナ信号を組み合わせて複数のビームを生成するビームフォーマーであり、各ビームは異なる GPU コンテキストによって処理されます。ビームの処理パイプライン全体が既に配置されているので、ビームフォーミング部分を追加するだけです。各スレッドに独自のビームを生成させると、入力データが複製されるため、それを避けたいと思います (また、一度に複数のビームを生成する方がはるかに効率的です)。

マルチ GPU フレームワーク (Windows 上) があり、特定の GPU で実行される「ジョブ」(実行する GPU も指定する) を指定できます。現在、フレームワークの起動時に GPU ごとに 1 つの「ワーカー スレッド」を作成し、ジョブが処理されるのを待つというアプローチをとっています。具体的には、 https: //devtalk.nvidia.com/search/more/sitecommentsearch/GPUworker/ の「GPUWorker」クラスを使用します。

これまでのところ問題なく動作しますが、パフォーマンスに関連する重大な欠点がいくつかあります。

• 私たちのフレームワークでは、GPU が実際にはジョブの時間の 50% しか使用されていない場合でも、特定の GPU が「ジョブ」の全時間にわたってロックされます。ジョブの粒度が非常に粗いことに注意してください。たとえば、「オプティカル フローの計算を行う」には、50 ～ 100 ミリ秒かかることがあります。

• GPU をロックしない特定の「非同期」ジョブ (非同期ホスト デバイス コピーなど) を指定することはできません。

だから私は今、その問題に対する「より良い」戦略について考えています。私の考えは次のとおりです。「起動」された新しいジョブごとに、新しい「一時的な」CPU スレッドを作成します。次に、CPU スレッドは、作業が行われる GPU のデバイス番号を (「cudaSetDevice」を介して) 設定します。この時点でも (私にとっては透過的に) Cuda コンテキストが作成されると思います。正しいデバイスを確認した後、ジョブの「doWork」関数が CPU スレッドによって実行されます。ジョブが同期または非同期で実行されるかどうかに応じて、 「結合」が完了した (CPU スレッドの完了を待っている) かどうか。

いくつか質問があります。

• それは「良い」戦略ですか、それともこれを処理するより良い方法を誰かが知っていますか? もちろん、それはスレッドセーフな戦略でなければなりません。

• 私の提案した戦略では、新しい CPU スレッドの作成と Cuda コンテキストの (隠された) 作成の典型的なオーバーヘッド (ミリ秒単位) はどれくらいですか? さらに、たとえば Cuda コンテキストの作成が重要な場合、このオーバーヘッドを削減する方法 (たとえば、cuda デバイス API と何らかの「コンテキスト移行」を使用) はありますか?

実行時に問題固有のcubinファイルをロードするMATLAB mexライブラリがあります。この mex 関数は、MATLAB によって数百回呼び出されます。cuModuleLoad を呼び出すと、CUDA によって毎回カーネルがリロードされますか? それとも何らかの形でキャッシュされていますか？そうでない場合、ロードされたモジュールをその間に保持する方法はありますか? 現在、cuModuleUnload を呼び出していません。

ライブラリへの最初の呼び出しのみが遅いため、CUDA コンテキストは MATLAB プロセスに対して 1 回だけ作成されるようです。mex ライブラリへの後続の matlab 関数呼び出しは高速です。したがって、同じ CUDA コンテキストが再利用されていると推測できます。

GPUコンピューティングに関連するいくつかの論文を読んでいる間、私はこれら2つの用語GPUコンテキストを理解することに行き詰まりました.GPUハードウェアチャネルベローはそれらに簡単に言及していますが、それらが何を意味するのか理解できません.

Command : GPU はアーキテクチャ固有のコマンドを使用して動作します。各GPU コンテキストには、CPU で実行されているプログラムがコマンドを送信する FIFO キューが割り当てられます。GPU での計算とデータ転送は、対応するコマンドが GPU 自体によってディスパッチされた場合にのみトリガーされます。

Channel : 各GPU コンテキストには、コマンドのディスパッチが管理されるGPU ハードウェア チャネルが割り当てられます。Fermi は、複数のチャネルが同じ GPU 機能ユニットに同時にアクセスすることを許可しませんが、ハードウェアで自動的に切り替えられて共存できるようにします。

そのための明確で簡単な説明があります。