search

Overv / VulkanTutorial

Tutorial for the Vulkan graphics and compute API
https://vulkan-tutorial.com
Creative Commons Attribution Share Alike 4.0 International
3.18k stars 524 forks source link

Multisampling: Best practice validation: Transient attachment and storeOp != DONT_CARE... #274

Open davidbien opened 2 years ago

davidbien commented 2 years ago

For the multisampling chapter I am getting these 2 best practices validation performance warnings:

T[Performance]: id[UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory]: Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x1d1f69af4b0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 0 in the VkRenderPass is a multisampled image with 8 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively. and T[Performance]: id[UNASSIGNED-BestPractices-vkCreateFramebuffer-attachment-should-not-be-transient]: Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateFramebuffer-attachment-should-not-be-transient ] Object 0: handle = 0x1d1f69af4b0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0xc80d9cbd | Attachment 0 in VkFramebuffer uses loadOp/storeOps which need to access physical memory, but the image backing the image view has VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT set. Physical memory will need to be backed lazily to this image, potentially causing stalls.

The fixes that rid the problems are setting: colorAttachment.storeOp = VK_ATTACHMENT_STORE_OP_DONT_CARE; and ridding the VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT bit from this line:

createImage(swapChainExtent.width, swapChainExtent.height, 1, msaaSamples, colorFormat, VK_IMAGE_TILING_OPTIMAL, VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT | VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT, VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT, colorImage, colorImageMemory);

I looked for existing issues that point out these validation problems but I didn't see any - please excuse if I somehow missed them.

davidbien commented 2 years ago

If the change is made to: colorAttachment.storeOp = VK_ATTACHMENT_STORE_OP_DONT_CARE is changed then the validator doesn't complain about VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT anymore. I changed VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT first so I didn't notice this until a bit further experimentation.