We really don't want to use the `VkFormat` for the whole image. That has
a block size set on it, which causes the size to be reduced by a factor
of two or even four, in the case of a 420 format whose pitch exceeds the
required alignment. If instead we use the plane `MTLPixelFormat`, we can
sidestep that.
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.
If this bit is set, add `MTLTextureUsage` bits for features supported by
all possible view formats, not just the image format. Happily, Metal's
API validator layer is OK with this.
This is needed for the mutable format tests, which use this bit with a
format that doesn't support writing, then casts the image to a format
which does.
I've turned on the `Resolve` cap for stencil-only formats, even though
no version of the Metal Feature Set tables lists them as supporting
multisample resolve. Obviously, if they couldn't be resolve
destinations, the stencil-resolve filter that was introduced in Metal
2.1 wouldn't work. I don't know if the platforms and feature sets where
I've turned the bit on is accurate, though. Wider testing is needed.
Because Apple families 1 and 2 don't support depth/stencil resolve at
all, I've disabled the extension for those families. Since sample-zero
resolution is a required feature of Vulkan 1.2, this means we won't be
able to support 1.2 on those devices. If there's demand, we could
possibly have a compute pass which does sample-zero resolution.
We were looking in the wrong chain for the
`VkImagePlaneMemoryRequirementsInfo` struct. We were also failing to
call through to the `MVKImageMemoryBinding` to get dedicated
requirements, which broke dedicated memory.
Clearly, I failed to properly review the patch which refactored
`MVKImage` for `VK_KHR_sampler_ycbcr_conversion`.
Apple assured me that, starting in 10.15.5, linear textures and texture
buffers can be created from buffers with `Shared` storage. I have tested
this and can confirm that it works at least on Big Sur, and probably on
Catalina as well.
In an indirect draw, we wouldn't set the pipeline for the vertex stage
to the command encoder, because we had already switched encoders. This
caused havoc down the line, as we wound up running the "convert indirect
buffers" pipeline again, which smashed memory randomly--possibly causing
the GPU to crash, and bringing down the `WindowServer` with it!
Why is it so easy to bring down the `WindowServer` like this?
Use the Vulkan binding index to check that the binding is used.
Previously, we were erroneously using the Metal binding index. This
allows vertex binding divisor info to actually be used, and fixes some
tests in the CTS.
Fixes#1041.
We actually can't support this. Metal's validation layer complains if
a pipeline has a different raster sample count from that of the
framebuffer, even in the no-attachment case. This means that the
`defaultRasterSampleCount` property must be set correctly if Metal
supports no-attachment rendering, and the sample count of the dummy
texture must be set properly otherwise.
For these, we must use the `depthPlane` property to set the layer to
clear, and we must iterate over the image's depth, since the layer count
will be 1 in this case.
Some tests intentionally pass an invalid address mode here when
unnormalized coordinates are in use, ostensibly to test that it is
ignored. Metal's validation layer, however, complains if you set
`rAddressMode` to an invalid value, even if `normalizedCoordinates` is
`false`. To avoid this, don't set the `rAddressMode`, since it can't be
used with unnormalized coordinates anyway.
This is needed to get us past the 3D blit tests that were recently added
to the CTS. It *almost* passes all these new tests; the 3D format tests
fail for some reason.
Fixes a use-after-free bug when the pipeline layout is destroyed after
recording--e.g. in the
`dEQP-VK.api.pipeline_layout.lifetime.destroy_after_end` test.
This can be done by copying between each slice of the 2D image and each
plane of the 3D image individually.
This was actually quite simple to implement. I don't know why I punted
on this.
Prior to this, we were leaking objects after failing to configure them.
The sole exception was `VkDescriptorSet`; failed descriptor sets are
automatically returned to the pool. Now all objects are destroyed or
freed when creation fails.
Linear textures on Mac family GPUs aren't renderable, so we cannot use
a `Clear`/`Store` `MTLRenderPass` to clear them. Instead, use a compute
shader to clear them.
I haven't expanded this to all color images, because the
`MTLTextureUsageShaderWrite` usage disables lossless compression on
Apple GPUs, but `RenderTarget` usage does not. Also, multisample
textures do not yet support writing.
When doing multisample resolution in Metal, the dimensions of the MSAA
RT and the resolve destination must be the same. Therefore, if the
resolve region does not cover the entire destination, we must use a
temporary transfer image. This fixes a validation error in the differing
image size tests from the CTS
(`dEQP-VK.api.copy_and_blit.*.resolve_image.diff_image_size.*`).
Because the temporary transfer image has the same dimensions as the
destination and is intended to be resolved to it, copies from the source
should use the destination's parameters for the temp image. That way,
the regions show up in the correct place in the destination. This fixes
the remaining resolve tests.
Don't do expansion blits if the resolve region covers the entire
destination. This should reduce the amount of needless work we do in
that case.
