私はこれを理解していると思っていましたが、明らかにそうではありません:)エンコーダーによって受け入れられる形式のいずれでもないフレームからNVENCを使用して並列H.264ストリームエンコーディングを実行する必要があるため、次のコードパイプラインがあります。
- 新しいフレームが到着したことを通知するコールバックが呼び出されます
- フレームを CUDA メモリにコピーし、必要な色空間変換を実行します (最初の変換のみ
cuMemcpyが同期であるため、コールバックから戻ることができます。保留中の操作はすべて専用ストリームにプッシュされます)。 - イベントをストリームにプッシュし、別のスレッドを待機させます。イベントが設定されるとすぐに、正しい色空間のフレームで CUDA メモリ ポインターを取得し、デコーダーにフィードします。
何らかの理由で、このパイプラインを並列スレッドで実行する場合、各スレッドに専用のコンテキストが必要であると想定していました。コードは遅く、いくつか読んだ後、コンテキストの切り替えは実際にはコストがかかることを理解しましたが、コンテキストではGPU全体を所有しているため、他のトランスコーダースレッドからの並列処理をロックアウトしているため、実際には意味がないという結論に達しました.
質問 1:このシナリオでは、前述のパイプラインを実行するスレッドごとに、単一のコンテキストと、このコンテキストで作成された明示的なストリームを使用しても問題ありませんか?
質問 2:誰かが CUDA デバイス コンテキストの唯一の目的について教えてもらえますか? 複数の GPU のシナリオでは意味があると思いますが、1 つの GPU に対して複数のコンテキストを作成したい場合はありますか?