[Bug 98198] Crash when framebuffer is VK_NULL_HANDLE in VkCommandBufferInheritanceInfo

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98198

            Bug ID: 98198
           Summary: Crash when framebuffer is VK_NULL_HANDLE in
                    VkCommandBufferInheritanceInfo
           Product: Mesa
           Version: git
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: blocker
          Priority: medium
         Component: Drivers/Vulkan/intel
          Assignee: intel-3d-bugs at lists.freedesktop.org
          Reporter: jsr184 at gmail.com
        QA Contact: intel-3d-bugs at lists.freedesktop.org
                CC: jason at jlekstrand.net

When recording the secondary command buffer with the inheritance of the
VkRenderPass but without known VkFramebuffer, the driver crashes. For example,
setting the VkCommandBufferInheritanceInfo to:

inheritance.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_INFO;
inheritance.renderPass = validRenderPass;
inheritance.subpass = 0;
inheritance.framebuffer = VK_NULL_HANDLE; // not known yet VkFramebuffer object
inheritance.flags = VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT;

It will result in the crash in the vkCmdDraw() as the driver expects the
framebuffer is not NULL. However, the specification says:

"framebuffer optionally refers to the VkFramebuffer object that the
VkCommandBuffer will be rendering to if it is executed within a render pass
instance. It can be VK_NULL_HANDLE if the framebuffer is not known, or if the
VkCommandBuffer will not be executed within a render pass instance."

Which means, using VK_NULL_HANDLE is absolutely valid from the application
point of view and driver should not crash.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20161010/0f4a2e72/attachment.html>