vulkan管线内存屏障是否能缓解与没有内存屏障的管线屏障相关的同步约束?

3

从与vkCmdPipelineBarrier相关的规范中:

如果未指定内存屏障,则第一个访问作用域不包括任何访问。

这适用于第一个和第二个访问作用域,所以如果我理解正确:

(1) 没有内存屏障的管线障碍会导致所有后续命令在目标阶段等待,直到所有前面的命令完成源阶段。这是适用于所有命令的硬约束条件。

(2) 带有内存屏障的管线障碍放宽了同步限制,因此只有处理该内存的后续命令会在目标阶段(在相关访问操作处)等待,直到处理该内存的前面命令在源阶段(在相关访问操作处)完成。

这是否正确?

1个回答

3

(1)
除了广泛应用的仿佛原则外,是允许驱动程序违反这个原则的,如果你仅凭输出不能发现差异(例如唯一的差异是性能)。

它适用于所有命令,如果它们属于操作命令,在同一队列中,确实在此阶段处理了某些内容,并且blah blah....

规范将其称为执行依赖关系

(2)
这被称为内存依赖关系。它是执行依赖关系的超集。它不会削弱它。它使它更加严格。这意味着除了(1)以外,由内存依赖关系参数定义的所有副作用(缓存)都必须被刷新/无效化(或者特定设备架构需要做的任何事情,以及对其进行命名的具体术语)。

PS:我不确定VK_KHR_synchronization2是否是完全相同的。有一些尝试“简化”同步的计划,但是这样做有些直觉就丢失了。我认为尽管如此,它仍然相当于走过所有内存屏障结构并将所有阶段收集在一起的情况,并且仍然像(1)一样工作。


在 CPU 内存排序术语中,“strengthen”(加强)是描述具有更多保证的屏障的正常选择(更强 vs. 更弱的排序要求),而不是“harden”(硬化)。在需要显式一致性的 Vulkan 或 GPU 中,“harden” 是否为标准?(与 CPU 不同,CPU 只需等待存储缓冲区排空即可确保稍后的加载/存储在先前存储的全局可见性之后发生。)否则,我建议使用“strengthen” :P - Peter Cordes
@PeterCordes 哪,"硬化"听起来只是很酷,而且减少了犯错的风险。:p 我不太懂 CPU 屏障,因为它们通常不重要,除非你做汇编或其他东西。虽然我想它们的工作方式类似。 - krOoze
是的,“harden”确实传达了信息。CPU屏障的工作方式类似于C++11 std::atomic_thread_fence(std::memory_order_seq_cst)的编译方式(因为当然是这样实现的:P)。https://preshing.com/20130922/acquire-and-release-fences/是一个非常好而且*简单*的解释CPU屏障获取/释放屏障的网站。 - Peter Cordes

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接