In the past, MoltenVK signaled fences and semaphores immediately when
Metal reported that the batch was finished executing. But, some commands
do work in completion handlers that run concurrently with this. In
particular, in #278 I shunted copying query pool results onto a
different dispatch queue. This caused a race between this block and the
block which signals fences and semaphores.
Since some commands do work in completion handlers, the handler which
signals semaphores and fences must wait until these handlers finish
running. Also because of this, it is not adequate to submit a fence-only
request to implement `vkQueueWaitIdle()`. So, that function must now
wait for all submissions to complete. To preserve the invariant that
fence-only submissions are equivalent to `vkQueueWaitIdle()`, this
change also makes fence signaling wait for all submissions.
If the queue is continually supplied with new work, this implementation
may delay signaling fences indefinitely. Ideally, fences would only wait
for all work up to that point to complete before signaling. But I'm not
sure how to accomplish that yet.
Fixes#454.
Test for _pMetalFeatures->layeredRendering before setting
MTLRenderPassDescriptor.renderTargetArrayLength.
Change NSString comparisons using isEqualTo: to isEqualToString:.
Sometimes, the `CAMetalLayer` backing a view can be replaced--for
example, when the window is moved to another screen, or the style bits
on the window are changed. In that case, we must allow the client the
opportunity to recreate the surface and swapchain.
Layer-backed views always set themselves as the layer's delegate; we use
this fact to Key-Value Observe the view's `layer` property.
Other alternatives considered:
* Registering for `NSViewGlobalFrameDidChange` notifications. Aside from
only working on macOS, this doesn't actually catch every case where we
want to report a lost surface. I'm not even sure it works at all for
Metal.
* Holding a reference to the view, and checking when its layer property
has changed.
* Holding a weak reference to the layer; that way, the reference will
become `nil` when the layer is replaced. But this requires ARC.
Some projects also link against SPIRV-Cross statically, and in order to
avoid ABI conflicts, we should use a private namespace for the
SPIRV-Cross dependency to avoid bugs. See SPIRV-Cross issue #902 for
more information. The new namespace is MVK_spirv_cross, and the code
now makes use of the SPIRV_CROSS_NAMESPACE macro rather than spirv_cross.
The resource options must match between an `MTLBuffer` and any linear
texture created from it. Further, to be writable, the
`MTLTextureDescriptor` should have the `MTLTextureUsageShaderWrite` bit
set.
Fixes#542.
graphics pipeline during a compute stage.
MVKPushConstantsCommandEncoderState test for tessellation only during graphics stages.
Guard against possible missing graphics pipeline even during graphics stages.
Enable device features based on content of pCreateDeviceInfo.
Validate requested features are available and return if not.
Support returning error from vkCreateDevice(), vkFlushMappedMemoryRanges()
and vkInvalidateMappedMemoryRanges().
Update What's New Document.
