In `cgb::sync`, get rid of the `read_memory_access` restrictions for the destination parameters.

[johannesugb]

The only thing that makes no sense according to 1 is:

_READ flags are passed into srcAccessMask

However, both _READ and _WRITE accesses can be subject to incoherent caches (e.g. COLOR_OUTPUT distributed across all streaming multiprocessors ... hmm, that will be handled by the ROP somehow, probably... but anyways, it makes sense to state the memory dependency!)

Good example by 1:

Let’s say that we’re allocating a fresh image, and we’re going to use it in a compute shader as a storage image. The pipeline barrier looks like:

srcStageMask = TOP_OF_PIPE – Wait for nothing dstStageMask = COMPUTE – Unblock compute after the layout transition is done srcAccessMask = 0 – This is key, there are no pending writes to flush out. This is the only way to use TOP_OF_PIPE in a memory barrier. It’s important to note that freshly allocated memory in Vulkan is always considered available and visible to all stages and access types. You cannot have stale caches when the memory was never accessed … What about recycled/aliased memory you ask? Excellent question, we’ll cover that too later. oldLayout = UNDEFINED – Input is garbage newLayout = GENERAL – Storage image compatible layout dstAccessMask = SHADER_READ | SHADER_WRITE

Note the dstAccessMask = SHADER_READ | SHADER_WRITE after the layout transition!

Another example from 1:

vkCmdPipelineBarrier(image = image1, oldLayout = UNDEFINED, newLayout = COLOR_ATTACHMENT_OPTIMAL, srcStageMask = COLOR_ATTACHMENT_OUTPUT, srcAccessMask = COLOR_ATTACHMENT_WRITE, dstStageMask = COLOR_ATTACHMENT_OUTPUT, dstAccessMask = COLOR_ATTACHMENT_WRITE|READ)

This one is referring to aliased memory, but I think, for this issue, it can serve as a general example: WRITE accesses must be made available before caches are made coherent ("visible"!) to subsequent READs or WRITES.

[johannesugb]

New plan: Get rid of cgb::sync and replace with command/commands in terms of Auto-Vk!