KhronosGroup / KhronosGroup/Vulkan-ValidationLayers
Sync validation enhancements for NonReadable descriptor bindings
- Dominant language
- C++
- Stars
- 1k
- Forks
- 504
- Avg merge
- 11h 35m
- Merged PRs (30d)
- 224
Description
**Environment:**
- OS: Win 10 x64
- GPU: Nvidia 4090
- SDK or header version if building from repo: 1.3.250
- Options enabled (synchronization, best practices, etc.): sync validation
tagging @jzulauf-lunarg
**Describe the Issue**
As described in the [sync layer documentation](https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/4400858043f909ea86076b6f47a61b51ec8d58f9/docs/synchronization.md), it's able to detect when a writable descriptor is used in a GLSL `readonly` or SPIR-V `NonWritable` way. I believe this could be extended to handle `writeonly` / `NonReadable` annotations too.
This issue comes up in the following command pattern:
1. Create a descriptor set layout with a single binding at slot 0 - `STORAGE_BUFFER` with count 1, accessible in `COMPUTE` shader stage
2. Allocate a descriptor set from that layout and bind `buf` at slot 0
1. `vkCmdFillBuffer(cb, buf, 0, 4, 0)`
2. ```
vkCmdPipelineBarrier2(cb, {bufferMemoryBarriers: [{
buffer: buf,
srcStageMask: TRANSFER, srcAccessMask: TRANSFER_WRITE,
dstStageMask: COMPUTE_SHADER, dstAccessMask: SHADER_STORAGE_WRITE
}]})
```
1. Create a compute pipeline with the following shader:
```glsl
layout(set = 0, binding = 0) buffer writeonly TestBuf {
uint count;
} test;
void cs() { test.count = 42; }
```
3. Bind the pipeline and set
4. `vkCmdDispatch(cb, 1, 1, 1)`
This causes a `[ SYNC-HAZARD-READ-AFTER-WRITE ]` at the time of `vkCmdDispatch`. The shader does no reading however, and the barrier that was placed defines an execution barrier between appropriate stages and makes the memory operations from TRANSFER available before the shader executes.
Bonus question: when I do atomic operations on `writeonly` / `NonReadable` storage buffers, neither glslang nor standard validation flag this as an issue. This makes sense to me, since atomic operations are coherent and the memory writes from previous access were made available, so the atomic op takes care of visibility? Is this a legal usage?
**Expected behavior**
I would not expect any errors to be reported here.
Contributor guide
Assessment
This issue has not been assessed yet.