Khronos刚刚发布了他们的新内存模型扩展，但还没有非正式的讨论，示例实现等，所以我对基本细节感到困惑。
https://www.khronos.org/blog/vulkan-has-just-become-the-worlds-first-graphics-api-with-a-formal-memory-model.-so-what-is-a-memory-model-and-why-should-i-care
https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#memory-model
这些新扩展究竟试图解决什么问题？他们是在尝试解决语言级别的同步问题(比如说删除C++代码中的繁琐互斥体(，还是一组新的复杂功能，让您更好地控制 GPU 在内部处理同步的方式？
(推测性问题(在一般情况下学习并合并此新模型是一个好主意，还是此模型仅适用于某些多线程模式并可能增加开销？
大多数开发人员不需要详细了解内存模型，也不需要使用这些扩展。就像大多数C++开发人员不需要非常熟悉C++内存模型一样(这不仅仅是因为 x86，还因为大多数程序除了适当地使用标准库互斥体之外不需要任何东西(。
但是内存模型允许指定 Vulkan 的内存一致性和同步原语，歧义要少得多——在某些情况下，还可以增加清晰度和一致性。在大多数情况下，定义实际上并没有改变：以前没有数据竞争的代码仍然是无数据竞争的代码。对于一些进行高级或细粒度同步的开发人员来说，额外的精度和清晰度使他们能够确切地知道如何使他们的程序无数据竞争，而无需使用昂贵的过于强的同步。
最后，在构建模型时，该小组发现了一些以前设计不佳或损坏的东西(其中许多可以追溯到OpenGL(。他们现在已经能够准确地说出这些东西的作用，无论它们是否仍然有用，并构建出能够达到实际意图的替代品。
扩展宣传这些更改是可用的，但更重要的是，一旦扩展是最终的而不是临时的，这将意味着实现已经过验证，实际上符合内存模型。
除此之外，它还为原子操作提供了与此处C++描述的相同类型的细粒度内存排序保证。 我冒昧地说，许多，甚至大多数PC C++开发人员对此知之甚少，因为x86架构基本上使内存排序变得多余。
但是，GPU 不是 x86 架构，在 GPU 着色器内核上大规模并行执行的计算操作可能可以，并且在某些情况下，在处理共享数据集时必须使用显式排序保证才能有效。
该视频很好地介绍了适用于C++的原子和排序。