从与vkCmdPipelineBarrier相关的规范中:
如果未指定内存屏障,则第一个访问作用域不包括任何访问。
这适用于第一个和第二个访问作用域,所以如果我理解正确:
(1) 没有内存屏障的管线障碍会导致所有后续命令在目标阶段等待,直到所有前面的命令完成源阶段。这是适用于所有命令的硬约束条件。
(2) 带有内存屏障的管线障碍放宽了同步限制,因此只有处理该内存的后续命令会在目标阶段(在相关访问操作处)等待,直到处理该内存的前面命令在源阶段(在相关访问操作处)完成。
这是否正确?
从与vkCmdPipelineBarrier相关的规范中:
如果未指定内存屏障,则第一个访问作用域不包括任何访问。
这适用于第一个和第二个访问作用域,所以如果我理解正确:
(1) 没有内存屏障的管线障碍会导致所有后续命令在目标阶段等待,直到所有前面的命令完成源阶段。这是适用于所有命令的硬约束条件。
(2) 带有内存屏障的管线障碍放宽了同步限制,因此只有处理该内存的后续命令会在目标阶段(在相关访问操作处)等待,直到处理该内存的前面命令在源阶段(在相关访问操作处)完成。
这是否正确?
(1)
除了广泛应用的仿佛原则外,是允许驱动程序违反这个原则的,如果你仅凭输出不能发现差异(例如唯一的差异是性能)。
它适用于所有命令,如果它们属于操作命令,在同一队列中,确实在此阶段处理了某些内容,并且blah blah....
规范将其称为执行依赖关系。
(2)
这被称为内存依赖关系。它是执行依赖关系的超集。它不会削弱它。它使它更加严格。这意味着除了(1)以外,由内存依赖关系参数定义的所有副作用(缓存)都必须被刷新/无效化(或者特定设备架构需要做的任何事情,以及对其进行命名的具体术语)。
PS:我不确定VK_KHR_synchronization2
是否是完全相同的。有一些尝试“简化”同步的计划,但是这样做有些直觉就丢失了。我认为尽管如此,它仍然相当于走过所有内存屏障结构并将所有阶段收集在一起的情况,并且仍然像(1)一样工作。
std::atomic_thread_fence(std::memory_order_seq_cst)
的编译方式(因为当然是这样实现的:P)。https://preshing.com/20130922/acquire-and-release-fences/是一个非常好而且*简单*的解释CPU屏障获取/释放屏障的网站。 - Peter Cordes