Created attachment 144406 [details]
Renderdoc capture, see How to reproduce 2
In the Vulkan spec about VkCommandBufferInheritanceInfo it is stated that:
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:
- 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
- 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< ---
Author: Juan A. Suarez Romero <firstname.lastname@example.org>
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.