vulkan: fix subpass validation #6980
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Before, we supposed that the maximum number of input attachment should match the maximum number of color attachments. But in reality, we've only used one input attachment for the second subpass. - The problem with the above supposition is that the descriptor set layout for the input attachment descriptor set must have the exact number of input attachment specified in the shader. If the *layout* has more input attachment slots than specified in the shader, then we'd run into a validation error. - In this patch, we fix the number of max input attachment in the descriptor set layout to 1, since we ever only make use of one. Fixes #6513
poweifeng
requested review from
pixelflinger and
bejado
and removed request for
pixelflinger
pixelflinger
approved these changes
Jul 24, 2023
Comment on lines
+62
to
+65
| // We assume only one possible input attachment between two subpasses. See also the subpasses | ||
| // definition in VulkanFboCache. | ||
| static constexpr uint32_t INPUT_ATTACHMENT_COUNT = 1; | ||
|
|
There was a problem hiding this comment.
what would need to change so that we break that assumption? I suppose the material knows how many inputs it has, so that should be passed to the renderpass or something like that?
There was a problem hiding this comment.
In the really general case, we'd need to know how many subpasses, and the attachment -> input mapping between consecutive subpasses at the start of the renderpass.
right now we assume we have at most one additional subpass, and the sole input attachment to the second subpass is always the first color attachment.
plepers
pushed a commit
to plepers/filament
that referenced
this pull request
Dec 9, 2023
- Before, we supposed that the maximum number of input attachment should match the maximum number of color attachments. But in reality, we've only used one input attachment for the second subpass. - The problem with the above supposition is that the descriptor set layout for the input attachment descriptor set must have the exact number of input attachment specified in the shader. If the *layout* has more input attachment slots than specified in the shader, then we'd run into a validation error. - In this patch, we fix the number of max input attachment in the descriptor set layout to 1, since we ever only make use of one. Fixes google#6513
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #6513