Nvidiaは、OptiX 7 APIの最新アップデート OptiX SDK 7.2 をリリースしました。
NVIDIA OptiXは、映画やビデオ制作、その他の多くのプロフェッショナル・グラフィックス・アプリケーションでも使用されているGPU上での最適なレイトレーシング性能を実現するためのAPIです。少し専門的な内容もありますが、今後個々のソフトウェアに実装されるであろう新機能を見ることができます。
新機能
この最新バージョンでは、レイヤードAOVデノイジングをサポートするためのOptiXデノイザーへのAPI変更、スパーステクスチャをデマンドロードするための新しいライブラリ、検証モードや起動パラメータのSpecializationなど、便利なコンパイル機能と安全機能が導入されています。最後に、インスタンス化またはモーションブラーを使用する際に OptiX API に大きな利便性の変更がありました。
Layered AOV Denoising(レイヤード AOV デノイジング)
OptiX AIデノイザーは、レンダリング画像を処理してモンテカルロ・ノイズを除去するように設計されたニューラル・ネットワーク・ベースのデノイザーです。OptiX デノイザーは、アーティストが最終的に良い画像を得るために、インタラクティブなプレビューで特に重要になります。
OptiX 7.2では、1回のデノイジング・パスでカラー画像とともに複数のAOVレイヤーを同時にデノイジングする機能が追加されました。すべてのレイヤーを一緒にデノイジングする利点は、デノイザーがすべての画像レイヤーをまったく同じ方法でフィルタリングし、合成されたレイヤーのセットが正しく見えるようにすることです。これは、黒い背景が多く含まれているレイヤーをノイズ除去する場合に特に重要です。
レイヤー化されたAOVノイズ除去は、OptiX 7.1に同梱されているタイル状ノイズ除去機能とシームレスに使用することができ、これらの機能を組み合わせる際に発生するトリッキーなことは何もありません。
性能的には、各余分な AOV レイヤーは、beauty画像のノイズ除去にかかる時間の 10~20 パーセントを追加するので、余分なレイヤーを追加することは比較的容易です。以下の図では、異なるGPU世代を使用して1080pフレームをAOVデノイジングする際の時間の例を示します。
Demand-loaded Sparse Textures(デマンドロードされたスパーステクスチャ)
新しい OptiX Demand Loading library(デマンド・ローディング・ライブラリ)により、ハードウェア・アクセラレーションされたスパース・テクスチャをオンデマンドでロードできるようになり、テクスチャをプリロードする場合に比べて、メモリ要件、帯域幅、ディスク I/O が大幅に削減されます。 OptiX 7.2では、最大4 TBのテクスチャを持つシーンがサポートされるようになりました。
映画品質のテクスチャアセットのサイズは、視覚効果ショットやアニメーション映画の最終フレーム画像をレンダリングする上で長年の障害となってきました。 主人公のキャラクターが 50~100 GB のテクスチャを持つことは珍しくなく、多くのセットや小道具も同じように詳細に描かれています(適切な解像度でオーサリングする方がコストがかかるということを除いては、正当な理由がないこともあります)。
映画のモデルは通常、極端なクローズアップの場合には非常に高い解像度で描かれます。 キャラクターの顔は通常、いくつかの領域(目、鼻、口など)に分割され、それぞれの領域は4Kまたは8Kの解像度で描かれます。 さらに、粗い変位や細かい変位、汚れなどの様々なマテリアルレイヤーなど、多数のレイヤーが使用されることが多く、それぞれが別々のテクスチャの集合体となっています。
映画品質のテクスチャ全体をGPUメモリにプリロードするのは現実的ではありません。 GPUメモリを無駄にするだけでなく、ディスクからテクスチャを読み込んでGPUメモリに転送するのにも時間と帯域幅が必要です。 また、必要とされるディテールのレベルはテクスチャオブジェクトのカメラからの距離に依存するため、画像をダウンスケールすることもできません。 単純に最大解像度をクランプするだけでは、映画品質のレンダラーでは受け入れられないようなディテールの損失につながります。
さらに悪いことに、プロダクションショットでは、カメラビューの外にある、または他のオブジェクトに完全に覆われた何千ものテクスチャオブジェクトがあることも珍しくありません。 一般的に、どのテクスチャが必要なのかを事前に知ることは、実際にシーンをレンダリングしない限り不可能です。
これらの要因のすべてが、レンダリング前にGPUメモリにテクスチャをロードすることを困難にしています。 最初のパスで不足しているテクスチャ・データを特定し、必要に応じてディスクからロードし、パスの間にGPUメモリに転送します。
OptiX プログラミング・ガイドでは、新しい OptiX Demand Loading ライブラリの詳細な技術的な紹介をしています。 現在はテクスチャリングに焦点を当てていますが、ライブラリの多くは汎用的であり、カラーや法線のようなバーテックスごとのデータなど、任意のデータをオンデマンドでロードするために適応させることができます。 これはスタンドアロン CUDA ライブラリとして提供され、OptiX SDK のオープンソース・コードとして配布されています。 これは OptiX SDK の一部ですが、Demand Loading ライブラリには OptiX への依存性はなく、技術的には OptiX API の一部ではありません。
Validation Mode(バリデーションモード)
OptiX 7.2 には、OptiX アプリケーションの起動時やデバッグ時に追加の安全チェックを行うための、待望の検証モードが追加されました。この機能は、素早く簡単に有効にすることができ、ワンライナーだけで、一般的なエラーを探すため、デバイス側の余分なチェックを自動的にオンにします。例えば、デバッグ例外を自動的に有効にし、APIコールごとにCUDAストリームのステータスをチェックします。バリデーションモードでは、シェーダバインディングテーブルヘッダ(shader binding table headers)の一般的な問題もチェックします。
Specialization(特殊化)
OptiX 7.2 の新しいspecialization(特殊化)機能では、実行時に機能を切り替えて、使用していない機能をすべてシェーダーにコンパイルさせる新しい方法が追加されました。例えば、シャドウをオフにした場合、シャドウイングに関連するすべてのコードを完全にスキップして、パフォーマンスに全く影響を与えないようにしたいとします。
OptiX の特殊化により、開発者は起動パラメータの一部を、あたかも一定であるかのようにコンパイルするようにマークすることができ、C++ テンプレートの特殊化の背後にあるアイデアによく似ています。起動パラメータのセットは、フレームをレンダリングする前に CPU から GPU に送信されるメモリ・ブロックで、OptiX シェーダーで必要なグローバル値に使用されます。
開発者は、#ifdef のようなコンパイラ・ディレクティブの使用を置き換えるために、あるいは、ソース・コードや PTX を実行時に変更するビルド・トリックを置き換えるために、特殊化を使用することができます。このシステムの大きな利点は、異なる機能を有効にしてコンパイルされた複数のバージョンではなく、単一のバージョンの PTX コードでアプリケーションを出荷できることです。
optixBoundValues は、特殊化を実証する新しい OptiX SDK サンプルです。このサンプルは optixPathTracer SDK サンプルをベースにしており、フレームごとに使用されるライト サンプルの数を特殊化します。このサンプルには、特殊化を有効または無効にしたり、ライト・サンプル数を変更したりするためのインタラクティブなトグルが含まれています。ライトサンプル数を1に特化することで、コンパイラはライトサンプルのループ処理に関連するコードを削除することができ、結果としてサンプルの実行速度が約2倍になります。(これは説明を目的とした不自然な例であることに注意してください)。
Automatic Bounding Boxes(自動バウンディングボックス)
Optix 7.2 より前のバージョンでは、インスタンスやモーションブラーの API では、各オブジェクトに対して事前に計算された境界をユーザーが提供する必要があり、この境界は、複雑な変換と動きのあるオブジェクトを組み合わせたものである可能性がありました。OptiX 7.2では、変形や動きを含むこのような難しいケースでも、境界ボックスを自動的に計算することで、境界計算を代行してくれるようになりました。
OptiX のダウンロード
OptiX 7.2 SDK は商用利用は無料で、すでに世界トップのコンテンツ作成・レンダリング・アプリケーションに統合されています。統合されているアプリケーションの確認はこちらから
SDK は開発者向けに提供されており、すぐに利用できます。
OptiX SDK 7.2 のダウンロードはこちらから
コメント