No validation warning for barriers with redundant access flags

[zeux]

The spec says this:

Certain access types are only performed by a subset of pipeline stages. Any synchronization command that takes both stage masks and access masks uses both to define the access scopes - only the specified access types performed by the specified stages are included in the access scope. An application must not specify an access flag in a synchronization command if it does not include a pipeline stage in the corresponding stage mask that is able to perform accesses of that type. The following table lists, for each access flag, which pipeline stages can perform that type of access.

To me this suggests that, for example, the following barrier:

dependencies[1].dstStageMask = VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT;
dependencies[1].dstAccessMask = VK_ACCESS_COLOR_ATTACHMENT_READ_BIT | VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT | VK_ACCESS_SHADER_READ_BIT | VK_ACCESS_TRANSFER_READ_BIT;

Is something an application "must not specify" since there are no stages in the mask that can issue transfer reads. It would be nice to get a validation warning/error for this.

This seems to be the case for both external pass dependencies and vkCmdPipelineBarrier.

[chrisforbes]

Can you provide a test case? We already validate access masks against stage masks, but we might be broken somewhere..

[zeux]

See the dependency in the original issue; when used as an external subpass dependency it triggers no warnings/errors

[chrisforbes]

OK, I see what's going on here now. CmdPipelineBarrier etc outside a renderpass validates these masks correctly, but the renderpass path is different and misses it.

[zeux]

Yeah - sorry, I didn't check this thoroughly; CmdPipelineBarrier does issue an error here, so the issue is only with external dependencies.