まず第一に、私はかなりベテランのグラフィックス プログラマーですが、よく知られているように、誰もが間違いを犯します。残念ながら、コードベースは少し大きすぎて、ここで賢明なスニペットをスローし始めることができず、分離された CPP/コードベースで状況全体を再作成するのは非常に困難です。申し訳ありませんが、時間がありません。私は説明するために最善を尽くします。
ところで、誰かが私がこれをどのように処理しているか疑問に思っている場合は、もちろん特定のコードを提供します。
D3DPOOL_DEFAULT プール内のすべてのリソースと同様に、デバイス コンテキストが取り除かれると、遅かれ早かれリソースをリセットする必要があります。私は、何年にもわたって機能してきたすべての関連リソースに対してこれを処理するメカニズムを構築しました。しかし、その事実にもかかわらず、このバグが明るみに出て以来、私はもちろん、あらゆる仮定をチェックし、主張し、疑いました。
何が起こるかは次のとおりです。正確なサイズが 18874368 バイトの、かなり大きな動的頂点バッファーがあります。このバッファーは、動的ジオメトリ (等値面関連、fyi) を生成する前に、フレームごとにロックされます (D3DLOCK_DISCARD フラグを使用して完全に破棄されます)。もちろん、リセットを開始するまで、これは正常に機能します。更新されたリソースの Lock() 操作によって返されたポインターまたは単純なクラッシュのいずれかでアクセス違反を引き起こすバグを引き起こすには、1 回、2 回、または 5 回のリセットが必要になる場合があります。同様のアドレスですが、最初のケースではそれに追加されたオフセットがありません。その場合、途中で書き込みを行っているためです-D3D9 dll Lock()呼び出しの側にあります。
これを他のハードウェアでテストし、GMA X3100 ドライバー (BootCamp を備えた MacBook を使用) を最新のものにアップグレードしましたが、他のマシンでは再現できず、何が問題なのか途方に暮れています。同様のバッファで同様の状況を再現しようとしました（クワッドで満たされた同じタイプの大きなスクラッチパッドがあります）、一定のバイト数を超えると、同様に動作し始めました。
私はここで解決策を求めているわけではありませんが、同じ敵と戦った他の開発者がここにいる場合、または洞察に満ちた方向性を教えてくれる開発者がいる場合は非常に興味があります。私が見落としているかもしれないし、見落としていないかもしれません。
ありがとうございます。修正は大歓迎です。
- ニールス
ps - 私の友人は、それがオンボード ビデオ RAM の巨大なバッファであり、動的な性質のために内部で少なくとも 2 倍または 3 倍バッファリングされているという有効な点を提起しました。一方、デバッグ出力 (D3D9 デバッグ DLL + 最大警告出力) は無音のままです。
ps 2 - より多くのマシンでテストしてもまだ動作していましたが、それはおそらく状況の問題です:巨大な動的で、内部的に 2 倍/3 倍のバッファー バッファーがあり、多くのメモリと、必要なときに文句を言わないドライバーではありません..
ps 3 - Lock と Unlock が 18MB の完全なコピーを行うことを (知っておくべきでした) 言われました - それもあまりスマートではありませんが、それでも :) IBS）。
誰かがより良い提案をしない限り。私はまだそれを聞きたいです:)