Metal Best Practices Guideには、最高のパフォーマンスのために、「動的バッファデータを更新するためのトリプルバッファモデルを実装する」こと、および「動的バッファデータはバッファに格納された頻繁に更新されるデータを参照する」ことが記載されています。メタルベストプラクティス：トリプルバッファリング - テクスチャも？
フレームごとに更新する必要がある場合は、MTLTextureは「バッファに格納された頻繁に更新されるデータ」となりますか？上のガイドのすべての例は、MTLBufferに焦点を当てています。
私はAppleKitの実装がnextDrawableのコンセプトを持っていることに気づいています。ここには何が起きているのでしょうか？
CPUが同じテクスチャを変更している間にコマンドが飛行している可能性があり（たとえば、-replaceRegion:...のいずれかの方法を使用している場合や、バッキングIOSurface ）、マルチバッファリング技術が必要です。
レンダリング、シェーダ関数からの書き込み、またはblitコマンドエンコーダメソッドを使用してGPUのテクスチャを変更するだけの場合は、マルチバッファリングは必要ありません。シェーダ関数内でテクスチャフェンスを使う必要があるかもしれませんし、正確に何をしているかに応じてdrawコマンドとdrawコマンドの間でレンダリングコマンドエンコーダで-textureBarrierを呼び出す必要があるかもしれません。
はい、nextDrawableは、マルチバッファリングの形式を提供します。この場合、それはCPUアクセスによるものではありません。以前レンダリングされたテクスチャがまだ画面に表示されている間に、1つのテクスチャにレンダリングします。新しいレンダリングが画面上に置かれる直前にテクスチャをオーバードローする可能性があり、結果が壊れてしまうため、両方のテクスチャを同じにする必要はありません。
面白い、ありがとう。したがって、マルチパスレンダリングの場合、つまり1回のパスで背景がテクスチャにレンダリングされ、次のレイヤが別のテクスチャにオーバーレイをレンダリングし、前の2つのテクスチャを合成する最終パスが同じリスクを受けることになります最後のパスに加えて、最初の2つのパスのターゲットテクスチャをマルチバッファリングすることなく破損していますか？ – Tricky
あなたが説明しているシナリオを理解すれば、それはマルチバッファリングを必要としません。 1つのフレームの2つのテクスチャの合成は、次のフレームのために上書きされる前に完了します（間違った順序でコマンドをエンキューしない限り）。 –