Combine MoltenVKSPIRVToMSLConverter and MoltenVKGLSLToSPIRVConverter
frameworks into a single MoltenVKShaderConverter framework.
Update corresponding directory structures, symlinks, scripts, and build paths.
Update MoltenVK code to use new framework name for headers.
Add symlinks in API-Samples demo to support legacy
MoltenVKGLSLToSPIRVConverter header paths.
In addition to simplifying shader converter code and build management, the
use of only one shader converter framework fixes a race condition within Xcode,
prior to Xcode 12, when multiple targets use the same dependency XCFramework.
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.
Update remaining documents to reference Vulkan 1.1 instead of 1.0.
Per Vulkan 1.1 spec, remove now-obsolete MVKInstance code
that emits error if app requests higher Vulkan version.
Upgrade MoltenVK version to 1.1.0.
This will be needed for two other Vulkan 1.2 extensions,
`VK_KHR_depth_stencil_resolve` and
`VK_KHR_separate_depth_stencil_layouts`.
Most of this is just changing MVKRenderPass to store everything
internally in `RenderPass2` format. I also added some basic handling for
a few things I left out from earlier changes, input attachment aspect
masks and dependency view offsets. The former won't become important
until Metal supports depth/stencil framebuffer fetch. The latter won't
be needed until we start using untracked resources, and therefore need
to insert explicit fences and/or barriers between subpasses. We don't
need either right now, but I've handled them regardless.
Also a non-functional base for future extensions. We can't implement it
anyway until all remaining bugs in `MTLEvent`-based semaphores are
fixed.
This is the last of the extensions that was promoted to core for Vulkan
1.1. We're almost there!
Like with `VK_KHR_device_group` and `VK_KHR_external_memory`, this just
adds the groundwork needed to support future extensions; it provides no
actual support for external fences.
We should be able to easily support `VK_KHR_external_fence_fd`, by using
a POSIX semaphore. Since the fence FDs produced by that extension are
opaque, only supporting `close(2)` and `dup(2)`, we shouldn't have to
worry about portable programs poking the FD in weird ways. Hopefully.
Other types of external fences we might support include GCD semaphores
(`dispatch_semaphore_t`) and Mach semaphores (`semaphore_t`). I really
think we want support for GCD semaphores, because that's the most likely
object we're going to see passed between processes on Darwin given GCD's
built-in support for XPC.
I have deliberately omitted mention of these extensions from the user
guide. `VK_KHR_external_memory` was not mentioned in there, presumably
because no actual external memory types are actually supported.
Also, add missing `vkGetInstanceProcAddr()` entry for
`vkGetPhysicalDeviceExternalBufferPropertiesKHR()`. We have the
function, and we export the extension's name string. We might as well
make it available via `vkGetInstanceProcAddr()`.
Originally, Metal did not support this directly, and still largely
doesn't on GPUs other than Apple family 6. Therefore, this
implementation uses vertex instancing to draw the needed views. To
support the Vulkan requirement that only the layers for the enabled
views are loaded and stored in a multiview render pass, this
implementation uses multiple Metal render passes for multiple "clumps"
of enabled views.
For indirect draws, as with tessellation, we must adjust the draw
parameters at execution time to account for the extra views, so we need
to use deferred store actions here. Without them, tracking the state
becomes too involved.
If the implementation doesn't support either layered rendering or
deferred store actions, multiview render passes are instead unrolled and
rendered one view at a time. This will enable us to support the
extension even on older devices and OSes, but at the cost of additional
command buffer memory and (possibly) worse performance.
Eventually, we should consider using vertex amplification to accelerate
this, particularly since indirect multiview draws are terrible and
currently require a compute pass to adjust the instance count. Also,
instanced drawing in itself is terrible due to its subpar performance.
But, since vertex amplification on family 6 only supports two views,
when `VK_KHR_multiview` mandates a minimum of 6, we'll still need to use
instancing to support more than two views.
I have tested this extensively against the CTS. I'm very confident in
its correctness. The only failing tests are
`dEQP-VK.multiview.queries.*`, due to our inadequate implementation of
timestamp queries; and `dEQP-VK.multiview.depth.*`, due to what I assume
is a bug in the way Metal handles arrayed packed depth/stencil textures,
and which may only be a problem on Mojave. I need to test this on
Catalina and Big Sur.
Update SPIRV-Cross to pull in some fixes necessary for this to work.
Fixes#347.
fetchDependencies support option to skip all library builds.
fetchDependencies avoid sync locks if not building in parallel.
fetchDependencies build glslang headers.
Update ExternalRevisions/README.md glslang build integration section.
Update What's New.
SPIRV-Cross can now AND the `gl_SampleMask` output with an additional
fixed mask, presumably from the pipeline. Use this new functionality to
implement pipeline sample mask handling.
Special thanks to Tomek Pontika and Corentin Wallez of Google for
graciously contributing their implementation to SPIRV-Cross.
Update SPIRV-Cross to pull in the change necessary for this.
This extension provides weaker guarantees than `VK_EXT_robustness2` and
its `robustImageAccess2` feature. Metal easily meets those guarantees,
with no action on our part necessary.
MVKShaderLibrary::getMTLFunction() synchronize and refactor release of Metal objects.
Make use of existing autorelease pool instead of discrete retain/release.
Wrap entire specialization operation in @synchronized() to guard against
Metal internals not coping with multiple simultaneous specializations.
Log ext lib build steps to provide user feedback.
Add package_ext_libs_finish.sh script to separate packaging
libraries from building them, to avoid build database conflicts.
Travis only build macOS ext libs.
We only support the `robustImageAccess2` feature for now. Metal's
guarantees around out-of-bounds accesses to textures give us this for
free. `nullDescriptor` should also be possible to implement, but it
needs testing. Null image descriptors will probably just work, but null
buffer pointers probably not. We may need help, either from SPIRV-Cross
or a pass in SPIRV-Tools. `robustBufferAccess2` definitely needs an
assist from SPIRV-Tools. All three are useful for Direct3D compatibility
layers (DXVK, wined3d).
Currently, when a mapping is initiated for host-coherent device memory, existing
image contents are copied from the MTLTexture to host memory. However, if
host-coherent device memory is already mapped in a long-standing memory mapping,
changes to MTLTexture content are not reflected to the host memory.
This change adds that capability to open memory mappings. When the image pipeline
barrier is applied to an image that is attached to a host-coherent device memory
that currently has an open memory mapping, the MTLTexture contents are copied to
the open host memory binding.
Add MVKMappedMemoryRange to retrieve the currently mapped range in an MVKDeviceMemory.
MVKImage cleanup use of isHostCoherent(). Let it be same as MVKDeviceMemory
and don't test for it from macOS because it is unnecessary.
Mark MVKResource::bindDeviceMemory() as virtual.
Remove use of !! from mvkIsAnyFlagEnabled().
Update What's New document for VK_KHR_sampler_ycbcr_conversion.
Report format properties only based on the primary MTLPixelFormat
of a VkFormat, not any possible substitution MTLPixelFormat.
Update MoltenVK version to 1.0.43 and VK_MVK_MOLTENVK_SPEC_VERSION to 26.
Add MVKTranslatedVertexBinding to describe a translated vertex binding, track these in
MVKGraphicsPipeline, and add a Metal vertex layout for each additional translated binding.
MVKGraphicsResourcesCommandEncoderState query MVKGraphicsPipeline for translated bindings
associated with existing bindings and binds the same MTLBuffer multiple times with
different offsets.
Crash happened because MVKPhysicalDevices created inline in MVKSmallVector<, 2>
using emplace_back(). Crash occurred when attempting to reallocate memory in
MVKSmallVector, and move inline MVKPhysicalDevice instances. Revert to tracking
MVKPhysicalDevice as pointers, which are easy to move after memory reallocation.
Review and optimize all uses of MVKSmallVector::emplace_back().
Set VkPhysicalDeviceLimits::maxSamplerLodBias to zero since it's unsupported.
Return error and use VK_POLYGON_MODE_LINE for unsupported VK_POLYGON_MODE_POINT.
Functions and functionality supported, but don't currently do anything
until Metal-friendly enumerations added to VkExternalMemoryHandleTypeFlagBits.
Updated What's New document.
Capability functions and functionality supported, but don't currently do anything
until Metal-friendly enumerations added to VkExternalMemoryHandleTypeFlagBits.
Rename MVKPhysicalDevice::getPhysicalDeviceMemoryProperties() to
getMemoryProperties() for consistency.
Updated What's New document.
