検索はキーワードに基づいています。
例:「手順」
自然言語で検索しないでください
例:「新しいプロシージャを作成するにはどうすればよいですか?」
ノードグラフの改善
できるだけ早く場所を整理する
のPruneノードは、シーンからオブジェクトを削除するために使用されます。Geolib3-MTで使用される処理モデルを考えると、不要なシーングラフの場所/オブジェクトがシーンからより早く除去されるため、ダウンストリームOpsとGeolib3-MT自体の両方で必要な作業が少なくなります。この点で、プルーンはフィルタリング操作を提供し、ダウンストリームOpsで処理する必要があるシーングラフのサイズを縮小するものと考えることができます。
次の例では、アセットはAssetsIn 100箇所のシーングラフを生成するノード。境界ボックスはProcessBounds 100のすべての場所での操作と、このショットの不要なシーングラフの場所は、シーンからプルーニングされます。ただし、プルーンノードがより近くに配置されている場合AssetsInノード、によって処理されるシーングラフProcessBoundsサイズの半分です。これは、メモリと処理コストの両方の節約に直接つながります。
シーングラフオブジェクト/場所をできるだけ早く整理します。そうすることで、下流のOpsが処理する必要がある場所の数が減ります。これは、メモリとシーンの両方の処理時間の短縮に相当します。 |
並列シーン処理のディメンションを理解する
Geolib3-MTのシーングラフ処理システムは、並行して評価できる計算的に独立したタスクを検索します。大まかに言えば、Geolib3-MTが活用しようとしている並列性には2つの側面があります。
- Scene Graph Parallelism -遅延/遅延評価されたシーングラフなどKatana、シーングラフには潜在的な作業が含まれます。シーングラフの位置とその子が展開によって認識されるようになると計算されるため、潜在的な可能性があります。
シーングラフの場所の各子は、親の場所にのみ依存する計算的に独立したタスクを表します。シーングラフの位置が計算されると、そのすべての子を並行して計算できます。 -
Op Tree Parallelism -Opツリーのサブセクションは並行して処理できます。そうすることで、Geolib3-MTは、処理中のOpツリーのサブセクションのシーンを完全に展開します。ソースOpsなど、一部のopは自然に並列化可能です(つまり、入力のないOps)。Merge Opsなど、一部の構造は自然に並列化可能であり、各Opツリーブランチは独立して計算可能です。
Geolib3-MTが処理する既知の計算に依存しないタスクの最大バックログを提供するために、両方の次元で並列処理を活用します。
計算的に独立したシーングラフにマージブランチを使用する
の各枝Katanaノードグラフは、独立したシーングラフを生成するものと考えることができます。これらは、マージノードを使用して結合されます。
Mergeノードの各ブランチは計算的に独立したシーングラフを表すため、Geolib3-MTはこの事実を利用して各ブランチを並行して展開します。この動作が望ましくない場合は、で無効にすることができますRenderSettingsノード。Opツリーブランチのこの並列展開の恩恵を受けるには、考慮すべきことがいくつかあります。
- シーングラフは、1つの大きなシーングラフではなく、それぞれが1つ以上の接続されたOpによって生成される複数の小さなシーングラフとして考えてください。
- シーングラフに存在するデータの依存関係と、それらを生成するOpsのノードを考慮してください。ノードグラフをリファクタリングして、複数の独立したブランチから利用可能な並列処理を利用する機会はありますか?
- 複数の場所で動作する必要のあるCPUバウンド操作を特定します。Geolib3-MTは(独立した場所を並列処理することにより)シーングラフ自体で利用可能な並列処理を活用しますが、CPUにバインドされたノードとopを複製することにより、CPUにバインドされた操作を並列で評価することもできます。
|
この例では、3つのシーングラフがAlembic_Inノードは並列で生成され、並列処理はCPUBoundOperationノードはシーングラフのみに制限されます。 |
リファクタリングされたノードグラフバージョンの例CPUBoundOperationは、各ブランチ内に配置されます。つまり、両方の次元(シーングラフとOpツリー)で並列処理を利用できます。 |
折りたたみ可能なノード/操作のチェーンを一緒に配置する
特定のOpでシーングラフの場所を処理するには、Geolib3-MTは次のような多くの手順を実行する必要があります。
- 場所の依存関係(親の場所および属性を継承する場所)の確認も評価されています。
- シーングラフの位置を処理した結果を保存するためにメモリが割り当てられています。
- 場所をクックする前に、継承されたシーングラフ属性が適用されています。
- Opのクック機能を使用して実際の場所を評価します。
このプロセスは効率的ですが、無料ではありません。依存関係をチェックするには、中央のクック結果ストアをチェックする必要があり、メモリ割り当てには(潜在的な)システムコールが必要であり、クックコールには関数を呼び出すための小さなオーバーヘッドが発生します(たとえcook()呼び出しはシーングラフを変更しません)。
これを念頭に置いて、料理人の数を減らすためにできることは、シーングラフの処理時間を改善し、メモリ使用量を減らす可能性があります。
Geolib3-MTの新しいOpツリー最適化機能は、前処理ステップを実行してOpツリーのトポロジを分析します。そのような最適化の1つは、同じタイプのOpのチェーンの崩壊です。たとえば、4つのシリーズAttributeSet同じ場所のセットで動作するOpsは、単一のAttributeSetその場所のセットに作用します。これにより、キャッシュサブシステムのクック結果の数が減り、シーントラバーサルのメモリフットプリントが削減されます。
申し訳ありませんが、これは役に立ちませんでした
なぜこれが役に立たなかったのですか? (当てはまるもの全てをご確認ください)
ご意見をいただきありがとうございます。
探しているものが見つからない場合、またはワークフローに関する質問がある場合は、お試しくださいファウンドリサポート。
学習コンテンツを改善する方法についてご意見がある場合は、下のボタンを使用してドキュメントチームにメールしてください。
フィードバックをお寄せいただきありがとうございます。