KhronosGroup / KhronosGroup/Vulkan-ValidationLayers

Unexpected VUID-VkSubpassDescription2-externalFormatResolve-09338 in some CTS tests

Open
#11,511 1 comment 0 reactions 0 assignees View on GitHub
SpecChange
Dominant language
C++
Stars
1k
Forks
504
Avg merge
11h 35m
Merged PRs (30d)
224

Description

**Environment:**
- OS: Fedora Linux 43
- GPU and driver version: lavapipe from Mesa main
- SDK or header version if building from repo: 430c8b92c
- Options enabled (synchronization, best practices, etc.): defaults + synchronization

**Describe the Issue**

In internal CTS issue 6230, @spencer-lunarg reported that tests such as:

`dEQP-VK.pipeline.monolithic.multisample.multisampled_render_to_single_sampled.multi_subpass.r8g8b8a8_unorm_r16g16b16a16_sfloat_r32g32b32a32_uint_d16_unorm.random_64`

Make the layers report `VUID-VkSubpassDescription2-externalFormatResolve-09338`, which is true as of today as far as I can see. After analyzing the issue, I think the layers are wrong here.

`VUID-VkSubpassDescription2-externalFormatResolve-09338` reads:

> If the externalFormatResolve feature is not enabled and pResolveAttachments is not NULL, for each resolve attachment that is not VK_ATTACHMENT_UNUSED, the corresponding color attachment must not have a sample count of VK_SAMPLE_COUNT_1_BIT

Which is pretty simple: if you're resolving, the original color attachment must not be single-sample already.

The test contains a render pass with 3 subpasses, and the layers appear to be complaining about subpass 0, for example. Some info about the render pass setup:

Attachment descriptions:

| Index | Format | Samples |
| ------ | ------ | ------- |
| 0 | VK_FORMAT_R8G8B8A8_UNORM | 1 |
| 1 | VK_FORMAT_R16G16B16A16_SFLOAT | 8 |
| 2 | VK_FORMAT_R32G32B32A32_UINT | 8 |
| 3 | VK_FORMAT_D16_UNORM | 1 |
| 4 | VK_FORMAT_R16G16B16A16_SFLOAT | 1 |
| 5 | VK_FORMAT_R32G32B32A32_UINT | 1 |

Subpass 0:

* Color attachments: 2, unused, 0, 1, 3
* Resolve attachments: 5, unused, unused, unused, unused

As we can see, the only attachment that is resolved is the one at color location 0 in the subpass, which resolves attachment 2 (8 samples) into attachment 5 (1 sample, same format). Other resolve attachments are unused, so I'm not sure why the layers report the VUID.

**Expected behavior**

No validation errors.

**Valid Usage ID**

`VUID-VkSubpassDescription2-externalFormatResolve-09338`

> ERROR|VALIDATION: [VUID-VkSubpassDescription2-externalFormatResolve-09338] vkCreateRenderPass2(): pCreateInfo->pAttachments[0].samples is VK_SAMPLE_COUNT_1_BIT.
The Vulkan spec states: If the externalFormatResolve feature is not enabled and pResolveAttachments is not NULL, for each resolve attachment that is not VK_ATTACHMENT_UNUSED, the corresponding color attachment must not have a sample count of VK_SAMPLE_COUNT_1_BIT (https://docs.vulkan.org/spec/latest/chapters/renderpass.html#VUID-VkSubpassDescription2-externalFormatResolve-09338)

**Additional context**

N/A

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the named dEQP-VK.pipeline.monolithic.multisample.multisampled_rendered_to_single_sampled.multi_subpass test with the reported defaults and synchronization enabled. Trace the validation handling for VUID-VkSubpassDescription2-externalFormatResolve-09338 against the listed subpass 0 attachments; done means the test produces no erroneous validation error.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
testing-qa, tooling
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.