Vulkan的新扩展VK_KHR_vulkan_memory_model的目的是什么?

RWi*_*co8 15 vulkan

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 - 模型 - 和 - 为什么 - 应该-I护理

https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#memory-model

这些新扩展试图准确解决什么?他们是在尝试解决语言级别的同步问题(比如在C++代码中删除繁琐的互斥体),还是一组新的复杂功能,让您可以更好地控制GPU如何在内部处理同步?

(推测性问题)在一般情况下学习和合并这个新模型是不是一个好主意,或者这个模型是否只适用于某些多线程模式并可能增加开销?

Jes*_*all 16

大多数开发人员不需要详细了解内存模型,也不需要使用扩展.就像大多数C++开发人员不需要非常熟悉C++内存模型一样(这不仅仅是因为x86,这是因为大多数程序除了适当地使用标准库互斥体之外不需要任何东西).

但是内存模型允许指定Vulkan的内存一致性和同步原语,而且模糊性要低得多 - 在某些情况下,还需要额外的清晰度和一致性.在大多数情况下,定义实际上并没有改变:在继续数据竞争之前,数据无竞争的代码.对于少数进行高级或细粒度同步的开发人员而言,额外的精度和清晰度使他们能够确切地知道如何使他们的程序无数据竞争,而无需使用昂贵的过度强大的同步.

最后,在构建模型时,该小组发现了一些之前设计不当或破坏的东西(其中许多东西一直回到OpenGL中).他们现在已经能够确切地说出这些事情的作用,无论它们是否仍然有用,并建立可以实现预期目标的替代品.

扩展程序宣称这些更改是可用的,但更重要的是,一旦扩展是最终的而不是临时的,它将意味着实现已经过验证,实际上符合内存模型.

  • 不,唯一的API更改是物理设备功能查询结构,它告诉您是否支持内存模型,如果支持,是否支持"设备"范围(vs"队列"范围作为最广泛的范围).除非之前不正确,否则您的主机代码中不需要更改任何重要内容. (2认同)

Jhe*_*ico 5

除其他事项外,它为原子操作提供了相同种类的细粒度内存排序保证,此处针对C ++进行了描述。我敢说很多甚至大多数PC C ++开发人员对此并不真正了解,因为x86体系结构基本上使内存排序变得多余。

但是,GPU不是x86架构,在GPU着色器内核上大规模并行执行的计算操作可能可以,并且在某些情况下,当处理共享数据集时,必须使用显式排序保证才有效。

该视频很好地介绍了原子和顺序,因为它适用于C ++。