You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When executing a command, each image subresource is expected to be in a particular layout. But there are situations where the same command can require different layouts for the same subresource by accident. This is the most likely with images bound in descriptor sets: if the same image is bound multiple times, then it could be assigned a different image layout in each of those cases. It could also happen with render passes.
Vulkano currently doesn't catch this, but instead creates a nonsensical pipeline barrier that transitions the layout twice. The command buffer needs to have some mechanism to detect conflicts like this. As far as I can tell, this problem would still exist with a hypothetical future task graph implementation, it's not just an artefact of the current less-than-ideal command buffer sync code.
Also note one particular hazard for depth/stencil images: pipeline barriers can only apply to both the depth and stencil aspects together, and therefore those two aspects should be treated as a single resource with a single layout. However, if the separate_depth_stencil_layouts feature is enabled, this requirement is relaxed and they can be treated independently.
The text was updated successfully, but these errors were encountered:
When executing a command, each image subresource is expected to be in a particular layout. But there are situations where the same command can require different layouts for the same subresource by accident. This is the most likely with images bound in descriptor sets: if the same image is bound multiple times, then it could be assigned a different image layout in each of those cases. It could also happen with render passes.
Vulkano currently doesn't catch this, but instead creates a nonsensical pipeline barrier that transitions the layout twice. The command buffer needs to have some mechanism to detect conflicts like this. As far as I can tell, this problem would still exist with a hypothetical future task graph implementation, it's not just an artefact of the current less-than-ideal command buffer sync code.
Also note one particular hazard for depth/stencil images: pipeline barriers can only apply to both the depth and stencil aspects together, and therefore those two aspects should be treated as a single resource with a single layout. However, if the
separate_depth_stencil_layouts
feature is enabled, this requirement is relaxed and they can be treated independently.The text was updated successfully, but these errors were encountered: