memory - 为什么VkAccessFlagBits同时包含读位和写位？

Question

在 vulkan.h 中，VkAccessFlagBits 的每个实例都出现在包含 srcAccessMask 和 dstAccessMask 的对中:

VkAccessFlags      srcAccessMask;
VkAccessFlags      dstAccessMask;

在每种情况下，根据我的理解，这些掩码的目的是帮助指定两组操作，使得第一组中的操作结果对第二组中的操作可见。例如，在屏障之前发生的写入操作不应卡在缓存中，而应一直传播到可以在屏障之后读取它们的位置。或者类似的东西。

访问标志有读和写两种形式:

/* ... */
VK_ACCESS_SHADER_READ_BIT = 0x00000020,
VK_ACCESS_SHADER_WRITE_BIT = 0x00000040,
VK_ACCESS_COLOR_ATTACHMENT_READ_BIT = 0x00000080,
VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT = 0x00000100,
/* ... */

但在我看来，srcAccessMask可能应该始终是某种VK_ACCESS_*_WRITE_BIT组合，而dstAccessMask应该始终是某种组合VK_ACCESS_*_READ_BIT 值。如果这是真的，那么 READ/WRITE 区别与 src/dst 区别相同并且隐含在 src/dst 区别中，因此只要有 VK_ACCESS_SHADER_BIT 等就足够了，没有 READ_ 或 WRITE_ 变体。

那么为什么会有 READ_ 和 WRITE_ 变体呢？指定某些读取操作必须在其他操作开始之前完全完成是否有用？请注意，所有使用 VkAccessFlagBits 的操作都会产生(我认为)执行依赖性和内存依赖性。在我看来，执行依赖性应该足够好，以防止早期读取接收稍后写入写入的值。

Answer 1

在写这个问题时，我遇到了 Vulkan 规范中的一个声明，它至少提供了部分答案:

Memory dependencies are used to solve data hazards, e.g. to ensure that write operations are visible to subsequent read operations (read-after-write hazard), as well as write-after-write hazards. Write-after-read and read-after-read hazards only require execution dependencies to synchronize.

这来自 6.4 节。执行和内存依赖性。另外，该部分前面的内容:

The application must use memory dependencies to make writes visible before subsequent reads can rely on them, and before subsequent writes can overwrite them. Failure to do so causes the result of the reads to be undefined, and the order of writes to be undefined.

据此我推测，是的，涉及这些访问标志的 Vulkan 命令产生的执行依赖关系可能使您不必将 VK_ACCESS_*_READ_BIT 放入 srcAccessMask 字段 - 但实际上您可能希望在某些 dstAccessMask 字段中具有 READ_ 标志、WRITE_ 标志或两者，因为显然可以使用显式依赖项来防止读取- 写入后危险的方式不会防止写入后危险。 (也许反之亦然？)

就像，也许您的 Vulkan 有时会决定，为了后续的读取操作，写入实际上不需要一直通过特定缓存传播到其最终指定的目的地，如果 Vulkan 碰巧知道该读取操作将简单地从同一个缓存中读取，从而节省一些时间？但随后可能会发生第二次写入，并写入不同的缓存，并且在竞争中将剩下两个缓存(获胜者的选择未定义)以将它们的两个值发送到同一位置。或者其他的东西？也许我对这些缓存的思维模型是完全错误的。

至少，已经相当确定的是，内存屏障是令人困惑的。