This implementation uses `MTLSharedEvent` where possible, and emulates
it on the host otherwise. Unlike binary semaphores, `MTLSharedEvent`s
map well to timeline semaphores; there should be no problems using them
when they're available.
I'm extremely confident in the `MTLSharedEvent`-based implementation. It
passes nearly all the synchronization tests. I'm less confident in the
emulated implementation.
Both Intel and NV Vulkan drivers enable `strictLines`. My testing shows
in fact that AMD and Apple Silicon exhibit the non-strict-line behavior,
while Intel shows the strict-line behavior.
Metal currently does not support overlapping attribute loads and asserts on
them. Prevent it by shortening format's vector length to fit within the stride,
but print a cautionary message.
An example of affected program is Kingdom Come: Deliverance, which sets
attribute format to RGBA32 in IA and binding stride to 12, while the shader
input is just a float3.
Even if we used a texture view. We can't constrain the depth planes in a
3D texture using a texture view, so we need to set the render depth
plane in that case.
Bind descriptors based on binding number within pipeline layout, not order within
layout, and descriptor set looks up descriptor using binding layout it was created with.
If the texture is not properly aligned, creation will fail. Make sure
we ask for enough memory to hold all planes with alignment, or a plane
could wind up beyond the bounds of the heap.
The Metal Feature Set Tables lied. The maximum point size supported by a
device varies; values higher than the true maximum are clamped. For
example, my AMD Radeon Pro 460 clamps point sizes above 64, and my Intel
HD Graphics 530 clamps them above 256. 64 is the minimum maximum
mandated by Vulkan, so that's what we'll report.
The minimum number of samplers is the lesser of 96 or *n* times the
per-stage maximum, where *n* is the number of stages supported. So we
need to account for compute shaders as well as graphics pipeline
shaders.
For some reason, when we create the `MTLCaptureScope` with capture
enabled, in addition to the reference from object creation, Metal
retains the object for no apparent reason in the base `MTLCaptureScope`
initializer. This causes us to leak the capture scope--and with it, the
queue. Let's hope Apple isn't doing anything with that extra reference.
Starting in iOS/tvOS 13, Apple family 4 and up support 124 fragment
input components, matching macOS. Reduce Mac max to 124 to prevent Metal
from complaining when using more than 124 components.
Tessellation control shaders must support at least 120 per-patch output
components, so make sure the limit is that value.
The `MTLCaptureManager`--at least, the one in the capture layer--uniques
capture scopes created for queues. The two scopes we created--for
command buffer submission and surface presentation, respectively--wound
up referring to the same scope. So don't even bother creating a second
one. Use one scope for everything on the queue.
Since there's no need for the 'purpose' parameter anymore, remove it.
Honestly, I think this is a shame. It's useful to be able to create
distinct scopes for command buffer submission and swapchain
presentation. I've filed FB8791712 to get Apple to let us create
multiple scopes for a single queue. Unfortunately, until that's
resolved, because the objects are uniqued, this will interfere with a
forthcoming workaround for a retain bug in Metal relating to capture
scopes.
In #1093 it was reported that `MTLStorageModeShared` textures don't
actually work on 10.15.5, but do work on 10.15.7. I've increased the
minimum to 10.15.6 for now. If someone else reports that it doesn't work
on 10.15.6 either, I'll bump it to 10.15.7.
Moved to a new model for creation: create and potentially destroy the object
within MVKDevice::create..., to hide it from vulkan.mm where all other object
creation errors are handled. We could move to this slowly over time.
Passes all 49 private data CTS tests.
Prior to this, we weren't even setting the `BLIT_DST` bit for
depth/stencil formats. Conforming apps would thus never pass DS images
at all to `vkCmdBlitImage()`. It is now possible to do that, and even
get scaling and inversion to boot.
Stencil blits require the use of stencil feedback. If this feature isn't
available, both stencil and packed depth/stencil formats have their
`BLIT_SRC` and `BLIT_DST` features turned off, to prevent apps from
attempting to blit the stencil aspect.
There's only a couple of failing tests, involving a 1D stencil blit
(really a 2D stencil with height 1). For some reason, the fragments
produced during a scaled blit get spread out over the rendering surface.
I think this is a bug in Metal; we can't do anything about it.
I've noticed that in some tests, the clear values seem to be off by
about one ULP, and the tests subsequently fail. This should cause Metal
to round up instead of down and fix those tests.
Move setting of limits from MVKPhysicalDevice::initProperties() into separate
initLimits() function. Call initProperties() before initMetalFeatures() and
initLimits() after initMetalFeatures().
Retrieve MTLDrawable when requested, not in MTLCommandBuffer scheduled
handler, in case a different drawable is established by then.
Call timed present after adding presented handler, to avoid race
condition if presentation happens before handler is added.
Update MVKPresentableSwapchainImage::presentCAMetalDrawable() to create a
MTLCommandBuffer scheduled-handler and present the MTLDrawable from there.
According to Apple, it is more performant to call MTLDrawable present from within a
MTLCommandBuffer scheduled-handler than it is to call MTLCommandBuffer presentDrawable:.
Pass presentation timing info as a struct to simplify calls.
useIOSurface() sets the plane information in IOSurface only if
the image format has chroma subsampling. And when we import an
IOSurface, we should only check count of planes when the format
has chroma subsampling.
This resolves a crash in the following case to let two VkImages
share the same IOSurface:
```
VkImage image1, image2;
// the format in |info| is a non-chroma-subsampling format,
// e.g. R8G8B8A8_UNORM.
vkCreateImage(info, &image1);
vkCreateImage(info, &image2);
IOSurfaceRef ioSurface;
vkUseIOSurfaceMVK(image1, nil);
vkGetIOSurfaceMVK(image1, &ioSurface);
vkUseIOSurfaceMVK(image2, ioSurface);
```
For an MVKImage, when we call vkUseIOSurfaceMVK(),
the MTLTexture of each plane will be released but not
reset. And later when we destroy the MVKImage, the
destructor of MVKImagePlane calls releaseMTLTexture()
again, which will cause a crash because of double releasing
of an object.
To solve this we need to reset _mtlTexture to nil after
it is successfully released.
