Bug 110810

Summary:	Vulkan spec break: VkCommandBufferInheritanceInfo.framebuffer is NOT optional
Product:	Mesa	Reporter:	Sebastian Sydow <sebastian>
Component:	Drivers/Vulkan/radeon	Assignee:	mesa-dev
Status:	RESOLVED MOVED	QA Contact:	mesa-dev
Severity:	critical
Priority:	medium
Version:	19.1
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	Renderdoc capture, see How to reproduce 2 vulkaninfo on Kaby lake G (Intel HD 630 + AMD Vega m GL)

Description Sebastian Sydow 2019-06-02 07:46:16 UTC

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

Comment 1 Sebastian Sydow 2019-06-02 07:56:01 UTC

Created attachment 144407 [details]
vulkaninfo on Kaby lake G (Intel HD 630 + AMD Vega m GL)

Comment 2 Tapani Pälli 2019-06-03 05:11:36 UTC

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

Comment 3 Sebastian Sydow 2019-06-08 20:41:51 UTC

Thanks for the clarification on the Intel front. Let's just hope the RADV team sees this

Comment 4 Samuel Pitoiset 2019-06-11 21:14:06 UTC

Yeah, I will fix.

Comment 5 Sebastian Sydow 2019-08-14 22:32:35 UTC

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.

Comment 6 GitLab Migration User 2019-09-18 20:07:06 UTC

-- 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.