tree e5993e92a3a4939fb5734d8506698b909b18549a
parent cadc011c671409376088e97e7ad2c81a86ab1e73
author Chip Davis <cdavis@codeweavers.com> 1599242810 -0500
committer Chip Davis <cdavis@codeweavers.com> 1600723252 -0500

Correct features and image properties of chroma subsampled formats.

Under Metal, `GBGR422` and `BGRG422` formats don't support linear
textures, mipmapping, or multisampled, arrayed, 1D, 3D, or cube
images. Many of these don't make sense for multiplanar images, either,
so I've disabled them there as well. Vulkan also forbids creating buffer
views in a chroma subsampled format, which we can't do on Metal anyway
due to linear textures not supporting this. Finally, Vulkan forbids
blitting between chroma subsampled formats.

Don't advertise GBGR/BGRG formats greater than 8 bits. Metal has no
corresponding public pixel format.

Make sure `samplerYcbcrProperties.combinedImageSamplerDescriptorCount`
is at least 1. According to the Vulkan spec:

> `combinedImageSamplerDescriptorCount` is a number between 1 and the
> number of planes in the format.

For single-plane formats, use the directly mapped `MTLPixelFormat`
instead of trying to guess the correct format. This is important for
`G8B8G8R8_422_UNORM` and `B8G8R8G8_422_UNORM`, since these shouldn't map
to `RGBA8Unorm`.

Don't adjust the extent for plane 0. Plane 0 is never subsampled, even
with GBGR/BGRG formats. The subsampled R/B components are instead
interleaved in these formats with the fully sampled G. This fixes a
validation error creating a GBGR/BGRG texture with an odd size.

Don't warn when there's no `MTLPixelFormat` for a multiplanar format.
These deliberately have no `MTLPixelFormat`, because there is no single
`MTLTexture` corresponding to the entire image.

The extra checks in `MVKImage` are to ensure that the
`dEQP-VK.api.invariance.random` test doesn't crash.