Crash with vulkan when using VK_NV_framebuffer_mixed_samples + dynamic rendering

Gaming and Visualization Technologies APIs Vulkan
1

System details:
* Windows 10 Home 64 bit 10.0.19043 Build 19043
* NVIDIA GTX 1060 6GB
* Driver version: 512.95
* Geforce Experience version: 3.25.1.27
* Vulkan headers version: 1.3.211
* Not overclocked

When using Vulkan 1.3 with dynamic rendering enabled (not as an extension, but as a Vulkan 1.3 feature) the use of mixed samples (enabled via pNext chain of vk::PipelineRenderingCreateInfo linked to the vk::AttachmentSampleCountInfo[AMD/NV] struct) DOES work when using 1 color attachment and 1 depth attachment.

It also works (at least for the scenarios I tested) when all color attachments have the same sample count (only tested with the same sample count as the depth attachment, haven’t tested if having the color attachments all have the same sample count, but a lower sample count than the depth attachment works).

The crash happens (without validation layer errors) when you mix different color attachment sample counts, as in my case:

vk::SampleCountFlagBits::e8 for 1st color attachment
vk::SampleCountFlagBits::e8 for depth attachment
vk::SampleCountFlagBits::e1 for 2nd color attachment
vk::SampleCountFlagBits::e1 for 3rd color attachment
vk::SampleCountFlagBits::e1 for 4th color attachment

The crash happened with and without validation layers in the same way. It did not crash in the following configuration:

vk::SampleCountFlagBits::e8 for depth attachment
vk::SampleCountFlagBits::e1 for 1st color attachment
vk::SampleCountFlagBits::e8 for 2nd color attachment

So swapping the orders did somewhat help, but it did not render anything to the 2nd attachment (1st did render like it supposed to).

The crashes happen at vk::Queue::submit time (exception thrown by vulkan.hpp), it threw a DeviceLostError

The exact same (engine) code is tested on the latest Adrenalin drivers from AMD on a laptop (Windows 10 Home 64 bit 10.0.19044 Build 19044, Adrenalin 22.5.2), where it works without any crashes or errors. Of course, the only thing different on the laptop was using VK_AMD_mixed_attachment_samples instead of VK_NV_framebuffer_mixed_samples

Note 1: I used vkCmdDrawIndirectCount as draw call

Note 2: I’ve already submitted a bug report to the NVIDIA Developer Support Submission Form, (found that page on How to report a bug) so I do not know if this is a duplicate, or that the page (the Game Development Support Form) is not actually for bugs)

2

Still not fixed as of GeForce Game Ready Driver 516.59

3

Please provide a minimal test code with executable. We hve no enough information.

1 Like
4

Hello, sorry for the delay. Here is the solution:

NvidiaBugs.rar (7.7 MB)

The Release/Debug build executables are in x64/[Release/Debug]

This application crashes, but when you change shader.frag, it will not crash.
To change it to not crash you have to remove the writing to outColor1-outColor3, only writing to outColor0 will not crash.

I tested in my original application that if I change to second color attachment sample count to the same as the depth attachment and the first color attachment, writing to the second color attachment will not crash, but then again the third and fourth do.

It also crashes without any validation layers warning.

I think the driver may think that all other color attachments have the same sample count as the first color attachment or something? Since when i try to render to a depth attachment with sample count 8, and a single color attachment of sample count 1, it does not crash

5

Still crashes as of GeForce Game Ready Driver 526.98

6

Still crashes with GeForce Game Ready Driver 528.24 (Using RTX 3080 now)

7

Hi weteringt,
Please fix your error description:
VkDeviceWaitIdle returns VK_ERROR_DEVICE_LOST when using VK_NV_framebuffer_mixed_samples + dynamic rendering , your aplication crashes because you are using unhandled C++ exception. This corrected error descriptoin could help for nVidia driver team

image
image1920×1032 173 KB

1 Like
8

I’ll edit the description.

9

I cannot edit the title and/or the original post anymore, so I’ll just add a reply to the original post, hope that’s enough. Unless there is a different way to update the error description I’m not aware of…

1 Like
11

VkDeviceWaitIdle returns VK_ERROR_DEVICE_LOST when using VK_NV_framebuffer_mixed_samples + dynamic rendering

Aplication crashes because I’m using unhandled C++ exception, so the actual error is VK_ERROR_DEVICE_LOST, see this reply for a minimal test code with executable.

1 Like
12

Hi there and a belated welcome to the NVIDIA developer forums to @weteringt!

The change in description actually helped, thank you @AndreyOGL_D3D for pointing that out. I did some digging and it seems that there was a another issue here in the forums with similar error behavior.

Following that and potentially the bug report from weteringt there is a fix being deployed with one of the future driver updates. I don’t expect it as part of a 52x release anymore, but early on with 53x it should be there.

Hopefully that will address the problem in this post!

1 Like
13

I just downloaded the newly released driver (545.84), and it still is not fixed (the same device lost error). It also was not fixed with any 53x drivers. Did something happen in between?

14

Well, it was assumed this issue would be fixed along with a fix for the other post I linked above. And that fix was deployed with the latest r530 driver version.

If you still see the behaviour described here, I will update engineering.

15

Yes, I have tried to run the same minimal reproducible example I showed, over the course of the 53x drivers, and now the 545.84 driver, still exact same device lost behaviour with no validation errors.

Just to be sure I just tried it again with an AMD laptop (although using the AMD equivalent extension of course), and as expected, no errors or crashes.

1 Like
16

Our hardware doesn’t support the color attachments having different sample counts. I think the Vulkan spec doesn’t make this clear, so we need to fix that. With VK_NV_framebuffer_mixed_samples the depth/stencil attachment sample count can be greater than the color attachment sample count, but all color attachments have to have the same sample count. Also with VK_NV_framebuffer_mixed_samples the pipeline rasterizationSamples can be greater than the color attachment sample count.

This repro uses a mix of sample counter for the color attachments, which is causing the device lost.

17

O really? but then I do not know why VkAttachmentSampleCountInfoAMD and VkAttachmentSampleCountInfoNV are the same. Since the signature is:

typedef struct VkAttachmentSampleCountInfoAMD {
    VkStructureType                 sType;
    const void*                     pNext;
    uint32_t                        colorAttachmentCount;
    const VkSampleCountFlagBits*    pColorAttachmentSamples;
    VkSampleCountFlagBits           depthStencilAttachmentSamples;
} VkAttachmentSampleCountInfoAMD;

// Provided by VK_KHR_dynamic_rendering with VK_NV_framebuffer_mixed_samples
typedef VkAttachmentSampleCountInfoAMD VkAttachmentSampleCountInfoNV;

And the:

uint32_t                        colorAttachmentCount;
const VkSampleCountFlagBits*    pColorAttachmentSamples;

Implies that different color samples are supported, I guess that was then an oversight when the dynamic rendering extension was created. Or they forgot to add a way to check if different color sample counts are supported.

18

It turned out this was a regression in the Vulkan spec. An older version of the spec had this restriction documented, but it was lost when the VK_EXT_multisampled_render_to_single_sampled extension was added. It has now been fixed in 1.3.270 of the specification:
https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkRenderingInfo-multisampledRenderToSingleSampled-06857

1 Like