Skip to content

Sample fragment_shading_rate_dynamic fails validation on swapchain resize #1582

Description

@marius-pelegrin-arm

Description of the bug

When resizing the window of the sample fragment_shading_rate_dynamic, validation errors occurs that can lead to crash/instability on some drivers.

Here are some of the validation errors:

Validation Error: [ VUID-VkFramebufferCreateInfo-flags-04533 ] | MessageID = 0xfe6b2428
vkCreateFramebuffer(): pCreateInfo->pAttachments[0] mip level 0 has width (1578) smaller than the corresponding framebuffer width (1581).
The Vulkan spec states: If flags does not include VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT, each element of pAttachments that is used as an input, color, resolve, or depth/stencil attachment by renderPass must have been created with a VkImageCreateInfo::extent.width greater than or equal to width (https://vulkan.lunarg.com/doc/view/1.4.341.0/linux/antora/spec/latest/chapters/renderpass.html#VUID-VkFramebufferCreateInfo-flags-04533)
Objects: 3
    [0] VkRenderPass 0x1f000000001f
    [1] VkImageView 0x11490000001149
    [2] VkImage 0x113a000000113a
Validation Error: [ VUID-vkQueueSubmit-pWaitSemaphores-03238 ] | MessageID = 0xb50452b0
vkQueueSubmit(): pSubmits[0].pWaitSemaphores[0] queue (VkQueue 0x5fb5df68e310) is waiting on semaphore (VkSemaphore 0x130000000013) that has no way to be signaled.
The Vulkan spec states: All elements of the pWaitSemaphores member of all elements of pSubmits created with a VkSemaphoreType of VK_SEMAPHORE_TYPE_BINARY must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends must have also been submitted for execution (https://vulkan.lunarg.com/doc/view/1.4.341.0/linux/antora/spec/latest/chapters/cmdbuffers.html#VUID-vkQueueSubmit-pWaitSemaphores-03238)
Objects: 2
    [0] VkSemaphore 0x130000000013
    [1] VkQueue 0x5fb5df68e310

Plausible causes of the bugs

I have not investigated the semaphore error, but the framebuffer error is due to compute_buffers[i].frequency_content_image_view not being correctly resized. I have seen that a resize mechanism exists, but it definitely doesn't handle some cases.
The error was detected using GFXReconstruct by capturing the sample and seeing that a framebuffer attachment had a different size (1280x720) than the framebuffer (2322x1080) in the JSON convert.

Platforms affected

This was discovered on Android (because windows on Android are resized very early by the system) but happens as well on Linux/Windows if you resize the window manually.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions