synchronization - Vulkan:WAITING栅栏后提交的工作可以读取先前提交的写入吗？

Question

在全面阅读 Vulkan 规范的同步语言后，我试图确认特定场景不会引入数据竞争。考虑下面的代码片段，第二个队列中的工作提交读取第一个提交的工作结果，主机在第一个提交之间的围栏上等待:

VkFence first_work_fence = ... (unsignaled);
VkSubmitInfo first_work_submit_info = ... (no semaphore wait / signal);
vkQueueSubmit(chosen_queue, 1, &first_work_submit_info, first_work_fence);     // (1)
...
vkWaitForFences(device, 1, &first_work_fence, VK_TRUE, UINT64_MAX);            // (2)
...
VkSubmitInfo reads_first_work_submit_info = ... (no semaphore wait / signal);
vkQueueSubmit(chosen_queue, 1, &reads_first_work_submit_info, ...);            // (3)

根据我对规范的阅读，以下三个步骤是正确的:

1. 创建一个栅栏信号操作，这是一个内存依赖，其第一个同步范围涵盖提交命令中的所有工作，第一个访问范围涵盖设备执行的所有内存访问(spec 7.3)；作为执行内存依赖性的操作，它生成可用性操作，使操作的第一个访问范围内的写入可用于设备 (spec appendix B)
2. 在栅栏上等待确保栅栏信号操作已经发生，从而使第一次提交的写入可用，但根据上述内容不一定对设备域可见
3. “vkQueueSubmit 执行...一个可见性操作，源范围为设备域，目标范围为设备上的所有代理和引用。” ( spec appendix B )

总而言之，这似乎意味着在 (3) 中提交的工作可以访问在 (1) 中提交的工作的所有副作用，而无需进一步同步或显式内存可见性操作(例如，屏障)。这是正确的吗？

Answer 1

差不多，是的。

一个好的规范应该确保人们在没有串通的情况下达成相同的解释。如果您付出了这么多努力，但仍然不确定，请在 KhronosGroup/Vulkan-Docs 报告缺陷。 .

为了避免 VK_KHR_vulkan_memory_model，我可能不得不调用 Host Write Ordering Guarantees ，它(尽管名称如此)似乎包括对主机上先前 Vulkan 命令的执行依赖性，以及设备上的可见性操作。