私たちのゲームの一部のエンド ユーザーからのエラー レポートでは、次のような動作を頻繁に見てきました:IDirect3DVertexBuffer9::Lock失敗し、返されたエラー コードはD3DERR_NOTAVAILABLE.
これが発生すると、非常に頻繁に (常にではありませんが)、CreateTextureorのCreateVertexBuffer呼び出しがエラーで失敗しますD3DERR_OUTOFVIDEOMEMORY。
頂点バッファ ロックの失敗の原因として考えられるものは何ですか? 仮想メモリのアドレス空間が使い果たされている可能性がありますか?
Microsoft の Chuck Walbourn による DIRECTXDEV の応答に基づいて、「アドレス空間の不足」に加えて、別の原因として「ページ プールの不足」が考えられます。
または、Windows XP では、ページ プール カーネル メモリの制限に達したことを示している可能性があります。通常、これは多くの Direct3D リソース (テクスチャなど) を作成するときに発生します。
多くの Direct3D リソースを作成しています。
メモリ不足に関する提起された問題は有効です。Lock() 呼び出しの詳細を確認する必要がありますが、たとえば、それが DEFAULT プールにあり、動的 (D3DLOCK_DISCARD フラグが渡された) である場合、ドライバーが未使用のメモリを見つけようとする可能性が非常に高くなります。 (内部でバッファが 2 倍または 3 倍になるため) 戻りますが失敗します。
これは私が DirectXDev に投稿したものです: ;)
アプリケーションが使用しているメモリ量を確認しましたか? (タスク マネージャーで [仮想メモリ] 列を必ず選択してください!)。私の推測では、メモリの断片化に基づく問題が原因で、アドレス空間が不足する可能性があります。
ただし、ドライバーのバグである可能性があります...
デバッグ ランタイムは有用な情報を提供しますか?
編集：私が考えることができる唯一の他のことは、絞りのメモリが不足していることです. これが PCIExpress でどのように機能するかはわかりませんが、AGP ではアパーチャ サイズを設定できます。ただし、満杯かどうかを確認する方法がわかりません。表示されているエラーは、満杯であると報告していると思われます。Discard フラグを使用して多くのロックを行っていますか? もしそうなら、これらがアパーチャに大量の新しい割り当てを作成し、そこでメモリ不足を引き起こしている可能性があります。ただし、これは純粋な推測作業です。
これが一部のユーザーのみで発生している場合、それはローエンド マシンのユーザーであると思います。物事の実行が遅い場合、コマンド バッファーに大量のデータがバッファリングされてしまう可能性があります。これにより、制御が遅くなり、おそらく、あなたが見ている問題につながる可能性があります。コマンド バッファが長くなりすぎないようにすることをお勧めします。すべてのフレームの最初のロックが破棄フラグなしで行われていることを確認すると (つまり、フラグが 0 に設定されている場合)、頂点バッファーがレンダリングされるまでパイプラインが停止し、コマンド バッファーが同期されます。これにより、コマンドのバッファリングがフレームレートのスパイクを簡単に滑らかにできなくなるため、速度が低下します...
とにかく...それは単なる推測です！