Direct3D 10 のよく寄せられる質問

UpdateSubresource と Map with Discard は、約同じ速度にする必要があります。 メモリの最小量をコピーするコピーに応じて、いずれかを選択します。 データが 1 つの連続したブロック内のメモリに既に格納されている場合は、UpdateSubresource を使用します。 他の場所からデータを蓄積する必要がある場合は、破棄でマップを使用します。

特定のシェーダーのすべての定数を 1 つの定数バッファーに入れることで、最悪のパフォーマンスが実現されます。 多くの場合、これは D3D9 から D3D10 に移植する最も簡単な方法ですが、パフォーマンスが低下する可能性があります。 たとえば、次の定数バッファーを使用するシナリオを考えてみましょう。

cbuffer VSGlobalsCB
{
    matrix  ViewProj;
    matrix  Bones[100];
    matrix  World;
    float   SpecPower;
    float4  BDRFCoefficients;
    float   AppTime;
    uint2   RenderTargetSize;
};

バッファーは 6560 バイトです。 レンダリングするオブジェクトが 1000 個あり、そのうちの 100 個がスキンメッシュで、そのうちの 900 個が静的メッシュであるとします。 また、このアプリケーションが 1 つの光源とのシャドウ マッピングを使用しているとします。 つまり、2 つのパスがあります。1 つはライトからレンダリングされた深度マップ用、もう 1 つは前方レンダリング パス用です。 これにより、2000 の描画呼び出しが行われます。 各描画呼び出しで定数バッファーのすべての部分を更新する必要はありませんが、定数バッファー全体は引き続き更新され、カードに送信されます。 これにより、フレームごとに 13 MB のデータが更新されます (2000 回の描画呼び出し回数 6560 KB)。

最良の方法は、更新の頻度で定数バッファーを整理することです。 同様の頻度で更新される定数は、同じバッファー内に存在する必要があります。 たとえば、"定数バッファーを整理する最も悪い方法は何ですか?" で示されているシナリオについて考えてみますが、定数レイアウトが優れています。

cbuffer VSGlobalPerFrameCB
  { 
    float   AppTime; 
  };
cbuffer VSPerSkinnedCB
  { 
    matrix  Bones[100]; 
  };
cbuffer VSPerStaticCB
  {
    matrix  World;
  };
cbuffer VSPerPassCB
  {
    matrix  ViewProj;
    uint2   RenderTargetSize;
  };
cbuffer VSPerMaterialCB
  {
    float   SpecPower;
    float4  BDRFCoefficients;
  };    

定数バッファーは更新頻度によって分割されますが、これはソリューションの半分にすぎません。 分割を最大限に活用するには、アプリケーションで定数バッファーを正しく更新する必要があります。 上記と同じシーン (900 個の静的メッシュ、100 個のスキンメッシュ、1 つのライト パス、1 つの前方パス) を想定します。 また、オブジェクトごとに一部の定数バッファーが格納されることを前提としています。 これは、各オブジェクトに VSPerSkinnedCB または VSPerStaticCB が含まれていることを意味します。これは、スキン化されているか静的であるかに応じて異なります。 これは、パイプラインを介して送信されるマトリックスの量が 2 倍にならないようにするために行います。

フレームを 3 つのフェーズに分割します。 最初のフェーズはフレームの始まりであり、レンダリングは必要なく、一定の更新のみを含みます。

開始フレーム

• アプリケーション時刻の VSGlobalPerFrameCB を更新します (4 バイト)
• 100 個のスキンオブジェクトの 100 VSPerSkinnedCB を更新します (64,0000 バイト)
• 900 個の静的オブジェクトの VSPerStaticCB を更新します (57600 バイト)

次に、シャドウ マップ パスを指定します。 実際に更新される定数バッファーは VSPerPassCB のみです。 他のすべての定数バッファーは、開始フレーム パス中に更新されました。 これらの定数バッファーをバインドする必要はありますが、バッファーは既に更新されているため、ビデオ カードに渡される情報の量は最小限です。

シャドウ パス

• VSPerPassCB の更新 (72 バイト)
• 100 個のスキン メッシュを描画する (100 バインド、更新なし)
• 900 個の静的メッシュを描画する (100 バインド、更新なし)

同様に、前方レンダリング パスは、メッシュごとに格納されていないため、マテリアルごとのデータのみを更新する必要があります。 シーンで 500 個のマテリアルが使用されていると仮定した場合:

前方パス

• VSPerPassCB の更新 (72 バイト)
• 500 VSPerMaterialCBs (10000 バイト) を更新します

その結果、合計はわずか 707 KB になります。 これは非常に工夫されたシナリオですが、更新の頻度で定数を並べ替えることで、一定の更新オーバーヘッドをどれだけ削減できるかを示しています。

常に、定数バッファーの階層化されたシステムを使用できます。 必要な最大の定数バッファー サイズまで、可変サイズの定数バッファー (16 バイト、32 バイト、64 バイトなど) を作成します。 定数バッファーをシェーダーにバインドするときは、シェーダーに必要なデータを保持できる最小の定数バッファーを選択します。 この方法は効率は若干低くなりますが、中間ステップとして適しています。

1 つの方法は、定数バッファーをさらに分割することです。 ただし、バインドされている定数バッファーが多すぎるという点があります。 この場合、複数のシェーダーで使用されていない可能性が高い定数を定数バッファーの末尾に移動します。 シェーダーから変数データを取得するときは、D3D10_SHADER_VARIABLE_DESCから D3D10_SVF_USED フラグを使用して、変数が使用されているかどうかを判断します。 定数バッファーの末尾に未使用の変数を配置することで、これらの変数を使用しないシェーダーに小さなバッファーをバインドできるため、更新コストを節約できます。

冗長データの量に応じて、フレーム レートを 8% から 50% に向上させることができます。 最悪の場合、パフォーマンスは低下しません。

すべてのデータをシェーダーに取得するために必要な定数バッファーの最小数をバインドします。 現実的なシナリオでは、使用する定数バッファーの推奨数は 5 です。 シェーダー間で定数バッファーを共有する (同じ CB を VS と PS にバインドする) ことも、パフォーマンスを向上させることができます。

はい。実際にバッファーを使用しない場合は、VSSetConsantBuffer または PSSetConstantBuffer を呼び出さないでください。 この追加の API オーバーヘッドは、複数の描画呼び出しの過程で増加する可能性があります。

最善の解決策は、すべての状態を前もって把握し、状態オブジェクトを前もって作成することです。 つまり、レンダリング時に、状態バインディングが発生する必要がある唯一の操作です。 D3D10 では重複も除外されます。

ここには 2 つの解決策があります。 1 つ目は、状態オブジェクトをその場で作成し、D3D10 で重複を除外できるようにすることです。 ただし、これは、フレームごとに多くの状態オブジェクトの変更があるシナリオでは推奨されません。 より良い解決策は、状態オブジェクトを自分でハッシュし、要件に適合するオブジェクトがハッシュ テーブルに見つからない場合にのみ状態オブジェクトを作成することです。 カスタム ハッシュ テーブルを使用する理由は、アプリケーションが、そのアプリケーションに特有の使用シナリオに基づいて高速ハッシュを選択できることです。 たとえば、アプリケーションが BlendState の rendertargetwritemask のみを変更し、他のすべての値を同じに保つ場合、アプリケーションは構造体全体ではなく rendertargetwritemask からハッシュを生成できます。

AlphaTest がシェーダーのパフォーマンスになります。 FixedFuncEMU サンプルを参照してください。

ユーザー クリップ プレーンがシェーダーに移動しました。 これを処理する方法は 2 つあります。 1 つ目は、頂点シェーダーまたはジオメトリ シェーダーからSV_ClipDistanceを出力することです。 もう 1 つのオプションは、頂点シェーダーまたはジオメトリ シェーダーによって渡される値に基づいて、ピクセル シェーダーで破棄を使用することです。 両方を試して、特定のシナリオでどちらが高速であるかを確認します。 SV_ClipDistanceを使用すると、ジオメトリ に基づくクリッピング ルーチンがハードウェアで使用され、ジオメトリ バインド描画呼び出しの実行速度が低下する可能性があります。 同様に、破棄を使用すると、処理がピクセル シェーダーにシフトされ、ピクセル バインド描画呼び出しの実行速度が低下する可能性があります。

クリアはパイプラインの状態から分離されています。 D3D9 スタイルの動作を取得するには、全画面表示の四角形を描画してクリアをエミュレートします。

状態を既定値 (NULL) に戻す場合は、OMSetBlendState の呼び出しで SampleMask がゼロにならないようにします。 SampleMask が 0 に設定されている場合、すべてのサンプルは論理的に AND で 0 になります。 このシナリオでは、サンプルはブレンド テストに合格しません。

SRGB はサンプラーの状態の一部として削除され、テクスチャ形式に関連付けられています。 SRGB テクスチャをバインドすると、Direct3D 9 でD3DSAMP_SRGBTEXTUREを指定した場合と同じサンプリングが行われます。

詳細については、「 Direct3D 9 to Direct3D 10 の考慮事項」を参照してください。

D3D10 では非推奨になりました。 テクスチャをR8G8B8A8としてソースを変更したり、ロード時にスウィズルしたり、シェーダーでスウィズルしたりできます。

カラー パレットをテクスチャまたは定数バッファーに配置し、パイプラインにバインドします。 ピクセル シェーダーで、淡色テクスチャのインデックスを使用して間接参照を行います。

SRGB はサンプラーの状態の一部として削除され、テクスチャ形式に関連付けられています。 SRGB テクスチャをバインドすると、Direct3D 9 でD3DSAMP_SRGBTEXTUREを指定した場合と同じサンプリングが行われます。

D3D10 では、三角形ファンは非推奨になりました。 三角形のファンは、コンテンツ パイプラインまたは読み込み時に変換する必要があります。

D3D10 ではシェーダーリンケージがはるかに厳しくなります。 後続のステージの要素は、前のステージから出力される順序で読み取る必要があります。 次に例を示します。

頂点シェーダーは次のように出力します。

    float4 Pos  : SV_POSITION;
    float3 Norm : NORMAL;
    float2 Tex  : TEXCOORD0;

ピクセル シェーダーは次のように読み取ります。

        float3 Norm : NORMAL;
        float2 Tex  : TEXCOORD0;

ピクセル シェーダーでは位置は必要ありませんが、位置は頂点シェーダーから出力されますが、ピクセル シェーダーでは読み取られないため、リンケージ エラーが発生します。 より正しいバージョンは次のようになります。

頂点シェーダーは次のように出力します。

        float3 Norm : NORMAL;
        float2 Tex  : TEXCOORD0;
        float4 Pos  : SV_POSITION;

ピクセル シェーダーは次のように読み取ります。

        float3 Norm : NORMAL;
        float2 Tex  : TEXCOORD0;

この場合、頂点シェーダーは同じ情報を出力しますが、現在、ピクセル シェーダーは順序出力で物事を読み取ります。 ピクセル シェーダーは Tex の後に何も読み取らないので、VS が PS が読み取っているよりも多くの情報を出力していることを心配する必要はありません。

1 つの解決策は、メッシュを読み込む前にシェーダーの順序を切り替え、シェーダーを読み込む方法です。 しかし、これは言うまでも簡単です。 アプリケーションで必要な場合は、いつでもオンデマンドで入力レイアウトを作成できます。 シェーダーシグネチャのバージョンを維持する必要があります。 シェーダーとバッファー レイアウトに基づいてハッシュを作成し、一致するものがまだ存在しない場合にのみ入力レイアウトを作成する必要があります。

Direct3D 9 では、描画呼び出しあたりの CPU コストが原因で、描画呼び出しの数に制限がありました。 Direct3D 10 では、各描画呼び出しのコストが削減されました。 ただし、描画呼び出しとフレーム レートの間に明確な相関関係がなくなりました。 描画呼び出しでは多くのサポート呼び出し (定数バッファーの更新、テクスチャ バインド、状態設定など) が必要になることが多いため、API のフレーム レートの影響は、単に呼び出し数を描画するのではなく、API の全体的な使用状況により依存するようになりました。

次のチートシートを使用します。

• CPU は、フレームごとにリソースを複数回更新します:D3D10_USAGE_DYNAMIC
• CPU によって、リソースがフレームごとに 1 回未満更新されます:D3D10_USAGE_DEFAULT
• CPU によってリソースが更新されない: D3D10_USAGE_IMMUTABLE
• CPU はリソースを読み取る必要があります: D3D10_USAGE_STAGING

定数バッファーは常に頻繁に更新されるように意図されているため、"チート シート" に準拠していません。定数バッファーに使用するリソースの種類については、「 定数バッファー 」セクションを参照してください。

D3D10 では使用されません。 動的ジオメトリの場合は、大きなD3D10_USAGE_DYNAMIC バッファーを使用します。 フレームの先頭で、D3D10_MAP_WRITE_DISCARDにマップします。 後続の描画呼び出しごとに、前に描画した頂点の位置を超えて書き込みポインターを進め、バッファーをD3D10_MAP_WRITE_NO_OVERWRITEにマップします。 フレームの末尾の前のバッファーの末尾付近にある場合は、書き込みポインターを先頭にラップし、D3D10_MAP_WRITE_DISCARDでマップします。

はい、可能ですが、特定のハードウェアでパフォーマンスが低下する可能性があります。 動的な 16 ビット インデックス データと 32 ビット インデックス データ用に個別のバッファーを作成する方が安全です。

ステージング リソースを使用する必要があります。 CopyResource を使用して、GPU リソースからステージング リソースにデータをコピーします。 ステージング リソースをマップしてデータを読み取る。

これは基本的に Direct3D の基本的な機能のラッパーであるため、API から削除されました。 StretchRect 機能の一部が D3DX10LoadTextureFromTexture に移動されました。 フォーマット変換とテクスチャのコピーでは、D3DX10LoadTextureFromTexture がジョブを実行できます。 ただし、あるサイズから別のサイズに変換するなどの操作では、アプリケーションでレンダリングからテクスチャへの操作が必要になる可能性があります。

Direct3D 9 のロック呼び出しのオフセットとサイズは、基本的に API の乱雑で、ドライバーによって無視されることがよくあります。 オフセットは、Map 呼び出しで返されるポインターからアプリケーションによって計算される必要があります。

これは、アプリケーションとハードウェア固有です。 帯域幅が最も大きい方を使用します。 既に複数のレンダー ターゲットを使用していて、追加のチャネルがある場合は、シェーダーから深度を書き込む方が適切なソリューションになる場合があります。 また、アルファまたは別のレンダー ターゲットに深度を書き込む場合、深度バッファーにアクセスする必要がある計算を高速化できる線形深度値を書き込むこともできます。

D3D10 には含まれません。

D3D10 には含まれません。 ただし、MSAA テクスチャから個々のサンプルをサンプリングできます。 詳細については、 HLSL セクションを参照してください。

ドライバーによって実際に列挙される MSAA サンプル数と品質番号を有効にしていることを確認します。

最初の手順では、デバッグ ランタイム (D3D10CreateDevice に渡されるD3D10_CREATE_DEVICE_DEBUG フラグ) を有効にします。 これにより、最も一般的なエラーがデバッグ出力として公開されます。

最初の手順では、デバッグ ランタイム (D3D10CreateDevice に渡されるD3D10_CREATE_DEVICE_DEBUG フラグ) を有効にします。 デバッグ出力がクリーンされていない場合、PIX はクラッシュする可能性がはるかに高くなります。

D3D10 と仮想アドレス空間にはいくつかの問題がありました。 これは、KB940105で修正されました。 これで問題が解決しない場合は、D3D10 でマップ (ロック) できるリソースが、D3D9 で作成したリソースよりも多く作成されていないことを確認してください。 また、将来的にこれがより普及するため、64 ビットへの移植についても考えてください。

まず、スキップするレンダリングが実際にはアプリケーションのボトルネックであることを確認します。 ボトルネックでない場合は、レンダリングをスキップしてもフレーム レートは役に立たなくなります。

次に、クエリの問題と述語を設定するレンダリングの間に十分な時間が経過していることを確認します。 レンダリング呼び出しが GPU にヒットするまでにクエリが完了していない場合は、レンダリングが発生します。

3 つ目は、特定の呼び出しのみをスキップします。 スキップされる呼び出しは、Draw、Clear、Copy、Update、ResolveSubresource、GenerateMips です。 状態の設定、IA のセットアップ、マップ、および作成の呼び出しでは、割り当ては考慮されません。 描画呼び出しの周囲に述語を設定する状態設定呼び出しが多数ある場合でも、これらの状態は設定されます。

いいえ。 テセレーションにはジオメトリ シェーダーを使用しないでください。

はい。非常に限られたシナリオです。 現在の D3D10 (2008) パーツのジオメトリ シェーダーは、多くの拡張を処理するために装備されていません。 これは、今後変更される可能性があります。 ビデオ カード ベンダーは、既存のポイント スプライト ハードウェアのために、1 から 4 つの展開に対して特別なパスを持つことができます。 その他の拡張は非常に制限される必要があります。 ParticlesGS サンプルと PipesGS サンプルは、限られた拡張のみを行うことで高いフレーム レートを実現します。 フレームごとに展開されるポイントは数点のみです。

シルエット検出、バリセントリック座標など、プリミティブ全体に対する操作を必要とするもの。 また、プリミティブを送信するレンダー ターゲット配列のスライスを選択する場合にも使用します。

はい。ただし、これによりパフォーマンスの問題が発生する可能性があります。 1 つの呼び出しに 1 ポイント、別の呼び出しに 4 ポイントを出力する例を見てみましょう。 拡張ガイドライン内で適合している間に、ジオメトリ シェーダー スレッドが順次実行される可能性があります。

隣接情報は D3D10 ではなく、アプリケーションによって作成されます。 隣接性インデックスはアプリケーションによって生成され、プリミティブごとに 6 つのインデックスを含める必要があります。6 個のうち奇数個のインデックスは、隣接するエッジの頂点です。 ID3DX10Mesh::GenerateAdjacencyAndPointsReps を使用して、このデータを生成できます。

これらは 可能です。 さまざまな D3D10 カードでは、使用可能な ALU ユニットのサブセットに対してのみ整数演算を発行できます。 これはハードウェアに大きく依存します。 その特定のハードウェアでの整数操作に対処する方法に関する推奨事項については、個々のハードウェア ベンダーに関するページを参照してください。 また、型間のキャストには十分注意してください。

ピクセル シェーダーへの入力を SV_POSITION として宣言すると、VPOS として宣言した場合と同じ動作が得られます。

シェーダーで、テクスチャを Texture2DMS として宣言します。 次に、Texture2DMS オブジェクトから Sample メソッドを使用して個々のサンプルをフェッチできます。

その変数の反映されたD3D10_SHADER_VARIABLE_DESC構造体を見てください。 uFlags には、D3D10_SVF_USED フラグが設定されている必要があります。

現在、FX10 を使用することはできません。

FX10 で管理されるすべての定数バッファーは、D3D10_USAGE_DEFAULT リソースとして作成され、UpdateSubresource を使用して更新されます。 FX10 ではすべての定数データのバッキング ストアが保持されるため、UpdateSubresource はこれらを更新するための最適な方法です。

「FixedFuncEMU サンプル」を参照してください。

通常はできません。 コンパイラは多くの場合、両方の方法を試し、最速のものを選択します。 ループ内のテクスチャフェッチがグラデーションにアクセスする必要がある場合など、場合によっては[unroll]を使用する必要があります。

すべての D3D10 操作は、32 ビット浮動小数点の有効桁数で実行するように指定されます。 したがって、部分精度では D3D10 に違いはありません。

比較サンプラーの状態を使用し、SampleCmp 命令を使用する必要があります。

D3D10 のレジスタ キーワード (keyword)が、特定のリソースがバインドされているスロットに適用されるようになりました。 この場合、リソースには Buffer (定数またはそれ以外の場合)、Texture、または Sampler を指定できます。

• 定数バッファーの場合は、register(bN) という構文を使用します。N は入力スロット (0 から 15) です。
• テクスチャの場合は、register(tN) という構文を使用します。N は入力スロット (0 から 127) です。
• サンプラーの場合は、register(sN) という構文を使用します。N は入力スロット (0 から 127) です。

packoffset キーワード (keyword)を使用します。 packoffset の引数は c[0-4095] の形式です。[x,y,z,w]. 次に例を示します。

        cbuffer cbLotsOfEmptySpace
        {
        float   IWaste2Floats   : packoffset(c0.z);
        float4  IWasteMore  : packoffset(c13);
        };

この定数バッファーでは、IWaste2Floats は定数バッファーの 3 番目の float (12 バイト目) に配置されます。 IWasteMore は、定数バッファー内の 13 番目の float4 または 52 番目の float に配置されます。