Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Image layout conflicts within a single command are not caught #2217

Open
Rua opened this issue May 31, 2023 · 0 comments
Open

Image layout conflicts within a single command are not caught #2217

Rua opened this issue May 31, 2023 · 0 comments

Comments

@Rua
Copy link
Contributor

Rua commented May 31, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant