WAR hazard question

The specification states:

> Write-after-read hazards can be solved with just an execution dependency

Suppose there is a sequence of memory accesses:

`color_attachment_write -> fragment_shader_read -> compute_shader_read_write`

Would it be sufficient to set a memory dependency between **color_attachment_write -> fragment_shader_read** and then just an execution dependency between **fragment_shader_read -> compute_shader_read_write** to ensure that the memory writes made by the color attachment output stage are visible to the compute shader?

```
// in the example, the image is always in VK_IMAGE_LAYOUT_GENERAL, so a global memory barrier will be used
to set the image memory dependency.

... // write to the image in a render pass

VkMemoryBarrier memoryBarrier = {
...
.srcAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT,
.dstAccessMask = VK_ACCESS_SHADER_READ_BIT };

vkCmdPipelineBarrier(
...
VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT, // srcStageMask
VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT, // dstStageMask
1, // memoryBarrierCount
&memoryBarrier, // pMemoryBarriers
...);

... // read the image in a fragment shader

vkCmdPipelineBarrier(
...
VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT, // srcStageMask
VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT, // dstStageMask
...);

... // write to the image in a compute shader
```

Start by reviewing the quoted specification statement and the Vulkan memory-barrier example in the issue, then trace the relevant synchronization rules for the three shader and attachment stages. Done means resolving whether the described dependency sequence is sufficient and updating or clarifying the specification accordingly.

Written by the indexing model from the issue text.