フォローする

メモリ構成(これは高度なユーザーのためのものです。 誤った設定は、パフォーマンスの低下につながります。)

General

Redshiftは、ポイントベースのGI、柔軟なシェーダーグラフ、アウトオブコアテクスチャリングやアウトオブコアジオメトリなどの市場の他のGPUレンダラーがサポートしていない機能をサポートします。これらの機能がほとんどのCPUバイアスレンダラーでサポートされているいますが、それらを効率的かつ予測可能にGPUで動作させることは重要な課題でした。

GPUプログラムの課題の1つは、メモリ管理です。 手元には主に2つの問題があります。まず、GPUにはメモリリソースが限られています。 第2に、GPUメモリを動的に割り当てるための堅牢な方法はありません。 このため、Redshiftは、各フレームの始めに定義されている既知の制限内で動作するように、異なるモジュール間で空きGPUメモリを分割する必要があります。

多くのCPUレンダラも同様の種類のメモリパーティショニングを行います。 他のレンダラーが「ダイナミックジオメトリメモリ」や「テクスチャキャッシュ」などを参照しているのを見たことがあります。 最初のものはシーンのポリゴンを保持し、2番目のものはテクスチャを保持します。 Redshiftは、それぞれポリゴンとテクスチャに「ジオメトリメモリ」と「テクスチャキャッシュ」も使用します。

従来、Redshiftはレイのメモリを割り当てる必要がありました。 GPUは大規模並列プロセッサなので、Redshiftは常にレイリスト(「ワークロード」)を作成し、GPUにディスパッチします。 GPUに送る光線が増えるほど、性能は向上します。 たとえば、1画素あたり1024光線のbrute-force GIを使用する1920×1080のシーンでは、最低21億本の光線を放出する必要があります。 また、アンチエイリアシング、シャドウ、被写界深度などに必要な余分な光線も含まれていません。これらの光線をすべてメモリに保存することは、あまりにも多くのメモリを必要とするため不可能です。したがって、Redshiftは、 これらのパーツを個別に提出することができます。この方法では、単一のパーツでGPUに十分なメモリが必要です。

最後に、IrradianceキャッシュやIrradiance Pointクラウドなどの特定の手法では、中間点を格納するための計算ステージで余分なメモリが必要です。 これらのステージで生成されるポイント数は事前に分かっていないため、メモリの予算を確保する必要があります。 Redshiftの現在のバージョンではこれらのメモリバッファが自動的に調整されないため、これらのステージで発生するポイントが多すぎるとレンダリングが中止され、メモリオプションに移動してこれらの制限を増やす必要があります。 将来、Redshiftはこれらの状況で自動的にメモリを再構成し、そうする必要はありません。

メモリーはどのように分割されるのか

高レベルの観点から、レンダラーがメモリを割り当てるために必要なステップは次のとおりです。

  1. 利用可能な空きGPUメモリを取得
  2. irradiance キャッシュ 計算またはirradianceポイントクラウド計算を実行している場合、適切な予約メモリを引く(既定は64MB)
  3. irradiance キャッシュ、フォトンマップ、irradiance ポイント蔵独活、またはサブサーフェーススキャッタリングを使用中の場合、メモリに領域を割り当てる
  4. 単一の部分にRAMメモリを割り当てる
  5. 残っているものから、ジオメトリ(ポリゴン)のパーセンテージとテクスチャキャッシュのパーセンテージを使用

フィードバックディスプレイ

Redshiftでフレームをレンダーする時に、ウィンドウはどのくらいのメモリが各モジュールに割り当てられるのかという情報が含まれるウィンドウをポップアップすることができます。ウィンドウはMayaでこのような感じです。

feedback

下は、それぞれの数字が何を意味しているか説明します。

Free

「空き」メモリは、フレーム開始時にRedshiftがレンダリングに利用可能なGPUメモリの量をレポート。この数字はビデオカードの全利用可能なメモリに近いはずです。Redshiftは、ビデオカードの実際の空きメモリの90%を使用しようとします。したがって、この数字は、既知のVRAMサイズよりも低くなります。 また、Windowsと3Dモデリングパッケージでは、そのメモリの一部も使用しています。

Overhead

フォトンマッピングやirradianceキャッシング等各レンダリングステージのために予約されたビデオカードメモリのサイズ

Geometry

アウトオブコア ジオメトリアクセス用のPCIe転送する必要があるメモリを報告します。 角括弧内の数字はジオメトリキャッシュの合計サイズです。

Textures

アウトオブコアテクスチャクセス用のPCIe転送する必要があるメモリを報告します。 角括弧内の数字はテクスチャキャッ巣の合計サイズです。

Matrices

シーン内の各オブジェクトには、インスタンス化、モーションブラー、テクスチャ変換などのさまざまな操作に使用できる変換行列があります。この数値は、これらの行列のメモリサイズをレポートします。 シーンに非常に多数のオブジェクト(数十万または数百万)が含まれている場合や、モーションブラーの変換ステップを多数使用している場合は、この数値が大きくなる可能性があります。

Sprites

スプライトノードによって使用されるテクスチャデータは別々に格納され、コア内にあります。 この数値は、スプライトノードテクスチャに使用されるサイズを報告します。

Rays

レイトレーシングに必要なメモリ(レイキュー)。

Photons

シーンでフォトンマッピングまたはコースティクスを使用している場合、この数字はフォトンおよびその加速階層構造に使用されるメモリをレポート

IC Points

シーンでirradiance cachingを使用している場合、この数字は、irradiance cache ポイントやそのための加速階層構造に使用されたメモリをレポート

IPC Points

シーンでirradiance point cloudを使用している場合、この数字は、irradiance point cloud歩イオンととその加速階層構造に使用されたメモリをレポート

SSS Points

シーンでサブサーフェーススキャッタリングシェーダーを使用している場合、この数字はサブサーフェーススキャッタリングポイントとその加速階層構造に使用されたメモリをレポート

下の章では、このウィンドウに含まれる数字からいくつかの使用例を説明します。

メモリオプション

Redshiftレンダリングオプションには、「Memory」タブがあり、GPUメモリ関連オプションを全て含みます。

Irradiance Point Cloud Working Tree Reserved Memory

irradiance point cloud 計算中に「作業中の」メモリです。既定64MBは数十万ポイントを保持することが可能です。

Irradiance Cache Working Tree Reserved Memory

irradiance cache計算中に「作業中の」メモリです。既定64MBは数十万ポイントを保持することが可能です。

Percentage Of Free Memory Used For Texture Cache / Maximum Texture Cache Size

予約されたメモリとレイが空きメモリから差し引かれると、残りはジオメトリ(ポリゴン)とテクスチャキャッシュ(テクスチャ)に分割されます。 「Percentage」パラメータは、テクスチャリングに使用できる空きメモリの割合をレンダラに示します。

例:

2GBのビデオカードを使用していて、予約済みのバッファとレイの後に1.7GB残っているとします。

テクスチャキャッシュ用既定15%は、その1.7GBの最大で15%、すなわち、約255MBを使用可能なことを意味します。言い換えると1GBのビデオカードを使用していて、バッファとレイを予約後に700MB残っていると、テクスチャキャッシュは最大105MB(700MBの15%0)になるかも知れません。テクスチャキャッシュ用に使用できる最大MBを確認すると、「Maximum Texture Cache Siz」オプションを使用して更に数字を制限することができます。これは空きメモリの多いビデオカードで便利です。例えば、6GBのQuadroを使用していると、バッファとレイで予約されたあと、5.7GBが空きです。この15%は855MBになります。そんあ大きなテクスチャキャッシュが必要なシーンは殆どありません!「Maximum Texture Cache Size」オプションがないと、いつも使用しているビデオカードに依存している「Percentage」オプションを修正しなければいけません。

これらの2つのオプション( “Percentage”と “Maximum”)を使うと、多くの空きメモリがあるビデオカードにメモリを浪費することなく、意味のあるパーセンテージを指定できます。

どうやって/いつこのパラメータを修正すべきを後ほど説明します。

Ray Reserved Memory

この設定を0のままにする場合、Redshiftはシェーダー構成に依存した数のMBを既定で使用するかもしれません。ですが、シーンにポリゴンという点で非常に軽いか、または、空き容量が多いビデオカードを使用している場合は、レイの予算を指定してレンダリングのパフォーマンスを向上させることができます。 これについては以下のセクションで説明します。

Irradiance Point Cloudの調整、Irradiance Cache予約メモリ

これらの数値を変更する必要があるのは、次のようなメッセージが表示された場合のみです。

“Irradiance cache points don’t fit in VRAM. Frame aborted. Please either reduce Irradiance Cache quality settings or increase the irradiance cache memory budget in the memory options(IrradianceキャッシュポイントがVRAMに収まりません。フレームが中止されました。Irradiance Cacheの品質設定を減らすか、メモリオプションのirradiance cacheメモリの予算を増やしてください)”

“Irradiance point cloud doesn’t fit in VRAM. Frame aborted. Please either increase the ‘Screen Radius’ parameter or the irradiance point cloud memory budget in the memory options(Irradiance point cloud がVRAMに収まりません。フレームが中止されました。メモリオプションのメモリオプションの “Screen Radius”パラメータまたはirradiance point cloud メモリの予算を増やしてください。)”

irradiance point cloudまたはirradiance cache qualityパラメータをを変更することができない(または望ましくない)場合は、メモリを64MBから100MBに増やすことができます。すでに多くのメモリを使用していて、まだこのメッセージが表示されている場合、シーンにはディティールが多いと思われるのでBrute-Force GIを使用することをお勧めします。

テクスチャキャッシュメモリの調整

Redshiftがレンダリングすると、「Feedback Display」ウィンドウがポップアップするはずです。 このウィンドウには、個々のモジュールに割り当てられるメモリの量に関する有益な情報が含まれています。 これらのエントリの1つが「テクスチャ」です。

この数字は、テクスチャリングのためにCPUがPCIeバス経由でGPUに送信しなければならなかったMBを報告します。 はじめは、“0 KB[128MB]”のようなものかもしれません。 これは、「あなたのテクスチャキャッシュは128MBで、それまではデータをアップロードしていません」ということです。

Redshiftは、ギガバイトのテクスチャデータを含むシーンを正常にレンダリングできます。 これは、テクスチャキャッシュをリサイクルすることで達成できます(この場合128MB)。 また、テクスチャ全体の代わりに必要なテクスチャの部分だけをアップロードします。 そのため、テクスチャが遠く離れている場合は、より低い解像度のテクスチャ(これらは「MIPマップ」と呼ばれます)とそのMIPマップの特定のタイルのみが使用されます。

メモリをリサイクルするこの方法のおかげで、PCIeで転送された図形がテクスチャキャッシュのサイズよりも大きくなることがあります(大括弧で示されています)。 ほとんどの場合は大丈夫です。ここで数メガバイトを再アップロードすると、通常は問題はありません。

しかし、「アップロード済み」の数が非常に高速になり、数百メガバイトまたはギガバイトにすばやく移行する場合は、テクスチャキャッシュが小さすぎて増加する必要があるかもしれません。

そのような場合は、1つまたは2つのことをする必要があります:

  1. 最初に「最大テクスチャキャッシュサイズ」を増やしてみてください。 デフォルトは128MBです。 テストとして256MBを試してみてください。
  2. 実行して、フィードバックウィンドウに表示された数値が256MBにならない場合は、「テクスチャキャッシュに使用される空きメモリの割合」を増やす必要があります。 0.3や0.5などの数字を試してください

レイ予約メモリの増加

平均して、Redshiftは、60MBのメモリにつき約1百万の三角形に適合することができます(単一UVチャネルと頂点あたりの接線空間を含むメッシュの典型的な例)。 これは、数百万の三角形を持つシーンでさえ、いくらかのメモリを空けたままにすることができることを意味します(ジオメトリには使用されません)。

そのメモリは、前に説明したように、RedshiftがGPUに提供する作業の数を減らし、場合によってはパフォーマンスを向上させるのに役立ちます。

シーンのジオメトリがGPUメモリを十分に活用していないかどうかを判断するのは簡単です。フィードバック表示の “ジオメトリ”エントリを見るだけです。テクスチャキャッシュと同様に、ジオメトリのメモリはリサイクルされます。 シーンがシンプルであれば(フレームをレンダリングした後で)、PCIe転送されたメモリがジオメトリキャッシュサイズ(角カッコで示されている)よりも大幅に低くなることがわかります。 例えば、 “Geometry:100MB [400MB]“のようになります。 この例では、300MBを使用してRaysに割り当て直すことができます。現在使用されているレイ・メモリもフィードバック・ディスプレイの “Rays”に表示されます。 「Rays:300MB」のようなものがあります。 したがって、メモリオプションでは、約600MBの「Ray Resevered Memory(レイ予約済みメモリ)」を作ることができます。 レイが使用している300MBに対して、ジオメトリが使用していない300MBを追加してください。

翻訳元

http://docs.redshift3d.com/Default.html#I/Memory Configuration.html

0 コメント

記事コメントは受け付けていません。