Support nv12 texture format

[xiaopengli89]

Checklist

• Run cargo clippy.
• Run cargo clippy --target wasm32-unknown-unknown if applicable.
• Add change to CHANGELOG.md. See simple instructions inside file.

Description
With this pr, we can create/import nv12 textures, which helps with video rendering.

[cwfitzgerald]

There's CI failures here, but we really need some kind of tests for this new kind of texture before we land support for this. Things like texture/buffer copies, etc. Otherwise we need to make sure the usages block those. Additionally, sampling etc needs tests.

[xiaopengli89]

There's CI failures here, but we really need some kind of tests for this new kind of texture before we land support for this. Things like texture/buffer copies, etc. Otherwise we need to make sure the usages block those. Additionally, sampling etc needs tests.

Currently we can create nv12 textures, but cannot copy from/to planes other than plane0, as this requires changing many related apis. Users can use hal::Device::texture_from_raw to import external nv12 textures for rendering, which is the most common use case. So currently I can only add a test that contains creation and sampling.

[cwfitzgerald]

We should then either prevent these textures from being copied, or document that they currently can only copy from plane one (and test it to make sure it doesn't invoke ub - the main thing I'm worried about).

[cwfitzgerald]

Waiting on tests

[xiaopengli89]

I don't know why the test fails on macOS:

Validation Error: [ VUID-VkImageCreateInfo-pNext-06722 ] Object 0: handle = 0x13b83f218, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x1a04b807 | vkCreateImage(): VkImageFormatListCreateInfo::pViewFormats[0] (VK_FORMAT_R8_UNORM) and VkImageCreateInfo::format (VK_FORMAT_G8_B8R8_2PLANE_420_UNORM) are not compatible. The Vulkan spec states: 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 (https://vulkan.lunarg.com/doc/view/1.3.250.1/mac/1.3-extensions/vkspec.html#VUID-VkImageCreateInfo-pNext-06722)

[xiaopengli89]

KhronosGroup/MoltenVK#440

It seems that MoltenVK does not support multi-planar format, so I disabled the feature on macOS/iOS, also prevent copying from/to nv12 textures.

[cwfitzgerald]

Some more testing and validation needed, but looking good.

Please re-request a review from me once the changes are addressed to make sure I see it!

[cwfitzgerald]

Thanks for the work!

[teoxoy]

CI is now running into:

Validation Error: [ VUID-VkImageCreateInfo-pNext-06722 ] | MessageID = 0x1a04b807 | vkCreateImage(): pCreateInfo->pNext<VkImageFormatListCreateInfo>.pViewFormats[0] (VK_FORMAT_R8_UNORM) and VkImageCreateInfo::format (VK_FORMAT_G8_B8R8_2PLANE_420_UNORM) are not compatible. The Vulkan spec states: 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 

Looking at this table, I don't think it's valid to pass the plane formats as view_formats. The plane functionality is similar to the existing aspect functionality used for combined depth-stencil textures where the format specified for the view is the format of one of the planes/aspects.

I think it would have made sense to add variants for the planes to TextureAspect rather than the new plane param.