Instead of rolling back the whole MR, can we just fix the failure? It's just some validation that's acting up

cc @xiaopengli89

Or more specifically, I don't quite understand why this is failing now but didn't fail inside the PR

Most likely due to updated validation layers. Interesting timing though.

Validation layers haven't updated since mid october

Indeed, CI logs show the same versions being installed.

Setting up vulkan-validationlayers (1.3.268.0~rc2-1lunarg22.04-1) ...
Setting up lunarg-vulkan-layers (1.3.268.0~rc1-1lunarg22.04-1) ...

Idk why the error didn't show up previously then, odd. But I think it's correct nonetheless.

Heh, it was a mesa update. We went from 23.2.1 to 23.3.0 and lavapipe learned how to make NV12 textures 😆

Ah, that explains it :)

I'm going to close this, I don't want to revert the whole PR.

We should either:

• Fix it (by moving into image aspect)
• Mark the test as failing on vulkan, quoting NV12 Vulkan CI Errors #4825 as the reason

@teoxoy I can successfully create nv12 texture and r8/rg8 views on windows with vulkan backend. I think this is an implementation issue with llvmpipe. In addition, we must add the plane view formats to the format list, otherwise the corresponding view cannot be created. I consider disabling the nv12 feature for llvmpipe.

In addition, we must add the plane view formats to the format list, otherwise the corresponding view cannot be created.

I don't think this is the case, we don't have to add the individual aspect formats for combined depth-stencil formats either. I added references to the Vulkan spec in #4573 (comment). If things work on one Vulkan implementation despite the Vulkan spec saying otherwise that doesn't mean it's correct.

We have to set VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT for plane selection to work but don't have to pass additional view formats.

References:

VUID-VkImageViewCreateInfo-image-01586
If image was created with the VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT flag, if the format of the image is a multi-planar format, and if subresourceRange.aspectMask is one of the multi-planar aspect mask bits, then format must be compatible with the VkFormat for the plane of the image format indicated by subresourceRange.aspectMask, as defined in https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#formats-compatible-planes

VUID-VkImageViewCreateInfo-image-01762
If image was not created with the VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT flag, or if the format of the image is a multi-planar format and if subresourceRange.aspectMask is VK_IMAGE_ASPECT_COLOR_BIT, format must be identical to the format used to create image

from https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkImageViewCreateInfo.html

VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT specifies that the image can be used to create a VkImageView with a different format from the image. For multi-planar formats, VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT specifies that a VkImageView can be created of a plane of the image.

from https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkImageCreateFlagBits.html

VUID-VkImageCreateInfo-pNext-06722
If a VkImageFormatListCreateInfo structure was included in the pNext chain and VkImageFormatListCreateInfo::viewFormatCount is not zero, then each format in VkImageFormatListCreateInfo::pViewFormats must either be compatible with the format as described in the compatibility table or, if flags contains VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT, be an uncompressed format that is size-compatible with format

from https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkImageCreateInfo.html

We can't add image format list at all, including the original format:

[2023-12-05T11:32:40Z ERROR wgpu_test::expectations] Unexpected failure due to: ValidationError(Some("Validation Error: [ VUID-VkImageViewCreateInfo-pNext-01585 ] Object 0: handle = 0x967dd1000000000e, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0xdd1d0240 | vkCreateImageView(): pCreateInfo->pNext<VkImageFormatListCreateInfo>.pViewFormats has no formats that match the VkImageViewCreateInfo::format (VK_FORMAT_R8G8_UNORM). The Vulkan spec states: If a VkImageFormatListCreateInfo structure was included in the pNext chain of the VkImageCreateInfo structure used when creating image and VkImageFormatListCreateInfo::viewFormatCount is not zero then format must be one of the formats in VkImageFormatListCreateInfo::pViewFormats (https://vulkan.lunarg.com/doc/view/1.3.268.0/linux/1.3-extensions/vkspec.html#VUID-VkImageViewCreateInfo-pNext-01585)"))

Yeah, that shouldn't be necessary for the NV12 format; wgpu users shouldn't have to pass the r8 and rg8 formats into view_formats.

wgpu users shouldn't have to pass the r8 and rg8 formats into view_formats.

I don't think this is reasonable, because view_formats should limit which views the texture supports at the abstraction level. I think it is more appropriate to handle it internally in wgpu (#4832).

That's not consistent with combined depth-stencil formats, users of the API don't have to pass the aspect formats to view_formats. view_formats is only currently used to create srgb views from non-srgb textures and vice versa.

which views the texture supports at the abstraction level

We can enforce this without users having to pass the plane formats to view_formats in the same way we do for combined depth-stencil formats (especially that Vulkan doesn't need us to pass the view formats to pViewFormats).

Okay, it seems better to have plane as an aspect.