KhronosGroup / KhronosGroup/Vulkan-ValidationLayers

Sync validation enhancements for NonReadable descriptor bindings

Open
#6,096 5 comments 0 reactions 1 assignee Claimed by @spencer-lunarg View on GitHub
ShaderVal Synchronization
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

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.