KhronosGroup / KhronosGroup/Vulkan-Docs
[Memory Model] Contradiction with vanilla spec regarding data race
- Dominant language
- JavaScript
- Stars
- 3.3k
- Forks
- 549
- Avg merge
- 5d 5h
- Merged PRs (30d)
- 2
Description
### Memory Model
The Memory Model provides one of the definitions of [location-ordered](https://docs.vulkan.org/spec/latest/appendices/memorymodel.html#memory-model-location-ordered), which refers to synchronization using Vulkan API functions (for example, via `vkCmdPipelineBarrier`):
As you can see, if another write follows the write, then only the availability operation needs to be performed (I omit the memory domain operation).
The location-ordered relation is necessary to avoid [data races](https://docs.vulkan.org/spec/latest/appendices/memorymodel.html#memory-model-access-data-race):
### Vanilla spec
Vanilla Spec [states](https://docs.vulkan.org/spec/latest/chapters/synchronization.html#synchronization-dependencies):
This means that a visibility operation must be used after an availability operation in the case of write-after-write.
If you don't use the correct memory dependencies, it will lead to a data race:
### Question
The Memory Model and Vanilla Spec give slightly different instructions on how to avoid data races. What is true in this case?
P.S. Some other issues also highlight this contradiction, but since it still hasn't been resolved, I decided to open a new issue.
Contributor guide
Assessment
This issue has not been assessed yet.