Multiview support for vulkan #7892
Conversation
| @@ -73,7 +73,7 @@ VkImageSubresourceRange VulkanAttachment::getSubresourceRange() const { | |||
| .baseMipLevel = uint32_t(level), | |||
| .levelCount = 1, | |||
| .baseArrayLayer = uint32_t(layer), | |||
| .layerCount = 1, | |||
| .layerCount = uint32_t(viewCount) > 0 ? uint32_t(viewCount) : texture->getLayerCount() > 1 ? texture->getLayerCount() : 1, | |||
There was a problem hiding this comment.
It's a neat pick but I don't think the first cast is necessary viewCount > 0 ?. I also think that it would be cleaner and more readable if we just moved the whole logic for layerCount comewhere else and then here just do .layerCount = layerCount
GrantComm
force-pushed
the
multiview
branch
2 times, most recently
from
5745c4e
to
2a899a3
Compare
| if (info.texture) { | ||
| rpkey.viewCount = info.texture->getLayerCount(); |
There was a problem hiding this comment.
I don't think this is necessary, you already set the viewCount above
There was a problem hiding this comment.
This is needed because there are times when the renderTarget's layer count is 2. But the underlying vulkan texture's layer count is 1. If there is a vulkan texture, then the viewcount needs to be set to the value from the texture. Without it validation layers errors occur:
VULKAN ERROR: (Validation) Validation Error: [ VUID-VkFramebufferCreateInfo-renderPass-04536 ] | MessageID = 0x5e2eb360 | vkCreateFramebuffer(): pCreateInfo->pAttachments[1] has a layer count (1) less than or equal to the highest bit in the view mask (1) of subpass 0. The Vulkan spec states: If renderPass was specified with non-zero view masks, each element of pAttachments that is used as an input, color, resolve, or depth/stencil attachment by renderPass must have a layerCount greater than the index of the most significant bit set in any of those view masks (https://vulkan.lunarg.com/doc/view/1.3.268.0/linux/1.3-extensions/vkspec.html#VUID-VkFramebufferCreateInfo-renderPass-04536)
and a segmentation fault crashes the program.
One caveat: If there were ever a case when there is a texture of samplerType::SAMPLER_2D_ARRAY that is not being used in a multiview configuration, it would trigger the multiview structure being added to the renderpass. To get around that. I could pass the value of mContext.isMultiviewEnabled() as part of the RenderPassKey to add an additional check before chaining multiviewCreateInfo to the renderpass.
There was a problem hiding this comment.
the texture should not have a layer count. But, for now, I propose both RenderTarget and Attachment will both have layerCounts. You can do an assert here to verify that the render target and attachment counts are the same.
There was a problem hiding this comment.
Sorry, not vulkan texture, but underlying vulkan image in the texture. When the gtlf_viewer application is not in stereo mode, the layercount of the underlying vulkan image is 1 but the layercount for the vulkan attachment and vulkan rendertarget are both 2. All three (vulkan texture's vkimage, vulkan attachment, and vulkan rendertarget) are all 2, only when the application is in stereo mode.
Without the current use of the layercount from the vulkan texture's vkImage, the validation error listed above is raised and a crash occurs
There was a problem hiding this comment.
I think there might be a bug here. If the rendertarget has 2 layers, then the backing image of the attachments should also have at least 2 layers. If you see the rendertarget somehow has greater number of layers than any of the attachments, then it's a bug IIUC.
There was a problem hiding this comment.
Yes, bug fix is in this pr: #7987
Please add more detail to the "commit message". You can modify your commit message with |
… and attachment layer count are equal for textures
FIXES=[332425392]
Adds multiview support for vulkan. This is done by adding a layerCount to the renderTarget, which is used to determine if multiview is available and being used in the current renderpass.