KhronosGroup / KhronosGroup/Vulkan-Docs

[Memory Model] Contradiction with vanilla spec regarding data race

Open
#2,792 1 comment 0 reactions 1 assignee Claimed by @jeffbolznv View on GitHub
Memory Model TSG
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`):

Image

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):

Image

### Vanilla spec

Vanilla Spec [states](https://docs.vulkan.org/spec/latest/chapters/synchronization.html#synchronization-dependencies):

Image

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:

Image

### 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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.