Error if trying to use an access mask with pipeline stages that can't perform it

[ghost]

Certain pipeline stages can only perform a subset of the memory access operations that can be specified in the src/dstAccessMask of a Vk*MemoryBarrier structure. As an obvious example, "TOP_OF_PIPE" and "BOTTOM_OF_PIPE" do not perform any memory accesses.

Specifying a type of access with a stage that can't perform it will result in a no-op. I've seen a couple of apps attempting to use TOP/BOTTOM with memory accesses, which will not work. It would be nice to warn users that this is a no-op, as there's a higher-than-zero chance they're doing something they didn't intend to (or they are doing nothing and expecting something).

All stages other than "ALL_COMMANDS" and "ALL_GRAPHICS_COMMANDS" are affected by this. For instance, "DRAW_INDIRECT_BIT" will only ever perform accesses of type "VK_ACCESS_INDIRECT_COMMAND_READ_BIT", and no other stage will perform accesses of that type.

[karl-lunarg]

Michael, can you consider implementing this, since you judged it to be a P1?

[lentinem]

Sure; I should be able to get to it in a few days.

[ghost]

@lentinem Just a heads up, this might actually be invalid behaviour (i.e. worthy of an error, rather than a warning). We're discussing this in the WG and should hopefully have an answer early next week. I'm hoping it's not hard to switch something from a warning to an error?

[lentinem]

Yes; just a different define passed into the log function.

[ghost]

The WG decided to make this invalid behaviour. Spec hasn't been updated to reflect that yet though, and it'll take at least a couple of weeks until it is. Any preference for how to handle this process-wise? I'd be fine with just making it an error now if that's easier, but we then may have to fend off some issues asking why it's now invalid in the interim...

[tobine]

Should be fine to just make it an error now on master branch as most developers run from SDK version of layers and I suspect SDK won't be updated for at least a few weeks.

[ghost]

Apparently I forgot to ever update this bug; sorry about that! The spec change to make this an error did happen a while ago now - see the paragraph before Table 6.2 "supported access types" in the "Access Types" section of the Synchronization chapter.