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

[karl-lunarg]

Issue by ghost (MIGRATED)
Monday Oct 03, 2016 at 10:25 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1006

---

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]

Comment by karl-lunarg (MIGRATED)
Thursday Oct 06, 2016 at 17:38 GMT

---

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

[karl-lunarg]

Comment by lentinem (MIGRATED)
Thursday Oct 06, 2016 at 17:42 GMT

---

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

[karl-lunarg]

Comment by ghost (MIGRATED)
Thursday Oct 13, 2016 at 10:31 GMT

---

@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?

[karl-lunarg]

Comment by lentinem (MIGRATED)
Thursday Oct 13, 2016 at 16:13 GMT

---

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

[karl-lunarg]

Comment by ghost (MIGRATED)
Tuesday Oct 18, 2016 at 10:15 GMT

---

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...

[karl-lunarg]

Comment by tobine (MIGRATED)
Tuesday Oct 18, 2016 at 14:08 GMT

---

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.

[karl-lunarg]

Comment by ghost (MIGRATED)
Tuesday Jan 24, 2017 at 19:22 GMT

---

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.

[jzulauf-lunarg]

Triage notes: The specific language in 6.1.3. Access Types (as of 1.1.95)

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.

Table 4. does not exist in a machine readable for code generation. A script that generates a map for access bit to stage mask is attached.

[jzulauf-lunarg]

legal_access_map.py.gz

[mark-lunarg]

This was implemented by @tobine in commit 6493f13.