NVIDIA OptiX ToolkitでGPUレイトレーシングを診断

NVIDIAは、OptiXとCUDAのエラー確認と、対象を絞ったGPU側の診断出力を支援するNVIDIA OptiX Toolkitの使い方を紹介しました。

要点

• OptiX、CUDA実行時API、CUDAドライバーAPIのエラー処理を同じ形式へそろえます。
• 診断には式、ソースファイル、行番号、シンボル名、人が読める説明を含めます。
• 多数のGPUスレッドから必要な場所だけを選び、一度限りの診断出力や画面上の印を使えます。

今回のブログ記事で語られていること

OptiXを使うレイトレーシングアプリでは、不正なAPI引数、黒い画面、数千のGPUスレッドに埋もれた不具合など、原因を絞りにくい失敗が起きます。記事は、BSD 3-Clause形式で利用できるNVIDIA OptiX Toolkitから、APIエラーの一貫した確認と、デバイス側の対象限定デバッグ出力という二つの機能を取り上げています。

最初に、OptiXの機器文脈を作る際のログ通知と検証モードを説明します。検証を有効にすると入力の誤りを読みやすいログで確認できますが、追加費用があるため、デバッグ・試験用の構成では全面的に有効化し、公開用の構成では外すことを推奨しています。後続の失敗が最初の原因を隠す前に、API呼び出しの直後でエラーを止めることが重要です。

OptiX、CUDA実行時API、CUDAドライバーAPIはいずれも状態コードを返しますが、エラー名や説明を得る関数の形が少しずつ異なります。OptiX Toolkitは、薄いマクロと型別のインライン関数を組み合わせ、呼び出した式、ファイル、行、数値コード、シンボル名、説明を同じ形式で出します。エラーで例外を投げる方針と、記録して続ける方針を選べ、インライン関数へ停止点を置くこともできます。

GPU側では、通常のprintfを広く置くと同時実行スレッドの出力に埋もれます。DebugLocationは、画素や処理位置など対象を限定し、一度限りの詳細出力、視覚的な診断印、ImGuiなどの画面部品との連携を可能にします。DemandPbrtSceneの例で利用方法を示しています。導入時は試験構成だけで有効にし、診断コードが公開構成の性能や出力へ残っていないことを確認する必要があります。

今回のブログ記事が関係する人

OptiXやCUDAで描画処理を開発する人、GPU側の不具合を調査するチーム、デバッグ構成を管理する基盤担当に関係します。

結局、今回のブログ記事をどう読むべきか

黒い画面を勘で追うのではなく、API境界で最初の失敗を止め、GPU側の対象を狭めて診断する実践記事です。既存プロジェクトでは、共通エラー処理とデバッグ・公開構成の分離から取り入れやすいです。