Put the fence back on the last submission.
This mostly reverts the last of the original change, save for a few
formatting changes and deletions of unused cruft.
Add ExternalDependencies (Debug) scheme to ExternalDependencies Xcode project.
Add --debug option to fetchDependencies script.
Support Release, Debug & Latest directories in External/build directory.
Enable DEPLOYMENT_POSTPROCESSING build setting when compiling
SPIRV-Tools to avoid warning spam when building dylibs.
Disable visibility warnings when building MoltenVKShaderConverter
in Release mode from external libraries built in Debug mode.
Always use -Xlinker -w option when creating dylibs to disable visibility warnings.
Add SPIRVToMSLConverterOptions::platform to track platform. Default to build platform.
Update default SPIRVToMSLConverterOptions MSL version to 2.1.
MoltenVKShaderConverter test MSL compilation use same MSL version as conversion.
Default min perf tracking value to 0.0.
SPIRVToMSLConverter.h reference spirv.hpp via SPIRV-Cross framework.
Update What's New document.
In a tessellated draw, the vertex shader will take a `device` pointer to
the vertex count. It must be a `device` pointer, because the `constant`
AS on Mac requires 256-byte alignment, which we cannot guarantee,
particularly with an indirect draw. But, the `setVertexBytes:...` method
cannot be used with the `device` AS. So, we need yet another temporary
buffer to hold this value in the `device` AS.
Fixes#566.
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.
