Created attachment 144406 [details] Renderdoc capture, see How to reproduce 2 In the Vulkan spec about VkCommandBufferInheritanceInfo it is stated that: (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkCommandBufferInheritanceInfo.html) ``` 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. ``` VkCommandBufferInheritanceInfo.framebuffer is however NOT optional on Intel and AMD Mesa Vulkan drivers. Effects on various drivers I could test: - Intel HD 630 18.2.8: SEGFAULT - Intel HD 630 19.0.1: works? - AMD Vega m GL 18.2.8: blank screen - AMD Vega m GL 19.0.1: blank screen - AMD Vega 64 18.2.8: blank screen - AMD Vega 64 19.0.1: blank screen I could only reproduce this behaviour on Mesa drivers, not with Windows and AMD drivers. How to reproduce 1: - Clone Sascha Willems Vulkan Examples and Demos repo: https://github.com/SaschaWillems/Vulkan.git - open examples/multithreading/multithreading.cpp - go to line 411 and comment out: ``` // Secondary command buffer also use the currently active framebuffer inheritanceInfo.framebuffer = frameBuffer; ``` - this will cause framebuffer to be a nullptr, aka optional How to reproduce 2: - get RenderDoc https://renderdoc.org/ - open the attached file "Mesa Bug.rdc" - in the middle select the texture viewer - on the top in the timeline open up the two gray bars - on the buttom inside the timeline chart you should see two triangles. These are the draws. Selecting them will show you the expected result. - selecting the block afterwards will make the result disappear. - I'm expecting that RenderDoc draws the currently selected draw separately on top of all previous draws
Created attachment 144407 [details] vulkaninfo on Kaby lake G (Intel HD 630 + AMD Vega m GL)
AFAICT anv is handling this correctly. Anv in 18.2.8 has a bug which has been fixed later (Mesa 19) with following commit: --- 8< --- commit 1ad26f941792f07f226c054811be78b0c0ac9fce Author: Juan A. Suarez Romero <jasuarez@igalia.com> Date: Tue Feb 12 19:19:13 2019 +0100 anv/cmd_buffer: check for NULL framebuffer This can happen when we record a VkCmdDraw in a secondary buffer that was created inheriting from the primary buffer, but with the framebuffer set to NULL in the VkCommandBufferInheritanceInfo. Vulkan 1.1.81 spec says that "the application must ensure (using scissor if neccesary) that all rendering is contained in the render area [...] [which] must be contained within the framebuffer dimesions". While this should be done by the application, commit 465e5a86 added the clamp to the framebuffer size, in case of application does not do it. But this requires to know the framebuffer dimensions. If we do not have a framebuffer at that moment, the best compromise we can do is to just apply the scissor as it is, and let the application to ensure the rendering is contained in the render area. v2: do not clamp to framebuffer if there isn't a framebuffer
Thanks for the clarification on the Intel front. Let's just hope the RADV team sees this
Yeah, I will fix.
I wanted to ask whether this issue already got fixed or is still being worked on as there haven't been any updates for a while.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/862.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.