Vulkanの新しい拡張機能VK_KHR_vulkan_memory_modelの目的は何ですか？
Khronosが新しいメモリモデル拡張をリリースしたばかりですが、非公式の議論や実装例などはまだないため、基本的な詳細について混乱しています。
https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#memory-model
これらの新しい拡張機能は何を正確に解決しようとしますか？彼らは言語レベルで同期の問題を解決しようとしているのですか（C++コードの厄介なミューテックスを削除するなど）、それともGPUが内部で同期を処理する方法をより詳細に制御できるようにする新しい複雑な機能セットですか？
（推測的な質問）この新しいモデルを学習して一般的なケースに組み込むのは良い考えでしょうか、またはこのモデルは特定のマルチスレッドパターンにのみ適用され、オーバーヘッドを追加する可能性がありますか？
ほとんどの開発者は、メモリモデルについて詳細に理解したり、拡張機能を使用したりする必要はありません。ほとんどのC++開発者がC++メモリモデルに精通している必要がないのと同じように（これはx86が原因であるだけでなく、ほとんどのプログラムが標準ライブラリミューテックスを適切に使用する以外に何も必要ないためです）。
しかし、メモリモデルでは、Vulkanのメモリコヒーレンスと同期プリミティブを、あいまいさを大幅に抑えて指定できます。場合によっては、明確さと一貫性を追加できます。ほとんどの場合、定義は実際には変更されませんでした。以前はデータ競合がなかったコードは、引き続きデータ競合がありません。高度な同期または詳細な同期を行う少数の開発者にとって、追加の精度と明確さにより、高価な過度に強い同期を使用せずにプログラムをデータ競合なしにする方法を正確に知ることができます。
最後に、モデルを構築する際に、グループは設計が不十分だったり、以前は壊れていたりしたものをいくつか見つけました（それらの多くはOpenGLにずっと戻っています）。彼らは今、それらがまだ有用であるかどうかにかかわらず、それらのことが何をするかを正確に述べ、実際に意図されたものを実行する代替を構築することができました。
拡張機能は、これらの変更が利用可能であることを通知しますが、それ以上に、拡張機能が暫定ではなく最終的なものになると、実装が実際にメモリモデルに準拠することが検証されたことを意味します。
特に、C++ here で説明されているアトミック操作と同じ種類の細かいメモリ順序の保証を可能にします。 x86アーキテクチャーは基本的にメモリーの順序付けを不要にするため、PC C++開発者の多くは、おそらくほとんどの場合、これについてあまり知らないと言ってもいいでしょう。
ただし、GPUはx86アーキテクチャではなく、GPUシェーダーコア上で大規模に並列実行される計算操作はおそらく可能であり、場合によってはmust明示的な順序保証を使用して有効にする必要があります共有データセットに対して作業する場合。
このビデオ は、C++に適用されるアトミックと順序付けに関する優れたプレゼンテーションです。