Xcode validates project build settings with each new Xcode release and
issues warnings to apply recommendations. We ignore these. This patch
sets the validated Xcode version to the maximum so that Xcode will
not longer issue these warnings.
Previously, libMoltenVK.dylib was created by copying and renaming
the binary from MoltenVK.framework, but this resulted in an unsigned
dylib that was not loadable.
- Create signed macOS libMoltenVK.dylib directly from Xcode.
- Refactor package_moltenvk.sh into package_dylibs.sh & package_headers.sh.
- Remove unused non-packaging Xcode schemes (unrelated).
Apple's iOS App Store does not permit an app to link to naked dylibs.
Instead, these must be placed in frameworks, which are embedded in a
dynamic version of MoltenVK.xcframework.
- Use Xcode to directly generate a MoltenVK.framework for each platform,
and remove create_dylib*.sh scripts.
- Move static XCFramework, containing libMoltenVK.a static libraries,
to Package/Latest/MoltenVK/static/MoltenVK.xcframework.
- Generate dynamic XCFramework, containing MoltenVK.framework dynamic
libraries, in Package/Latest/MoltenVK/dynamic/MoltenVK.xcframework.
- Add macro MVK_VERSION_STRING to create version string at compile time,
use it to validate the CURRENT_PROJECT_VERSION build setting at compile time,
and use it at runtime instead of mvkGetMoltenVKVersionString() function.
- Add -w to OTHER_LDFLAGS to dynamic framework builds to suppress
spurious linker warnings of the type
"ld: warning: no platform load command found in '...', assuming: iOS"
issued from the new linker introduced in Xcode 15.
- Add MoltenVK-MacCat Xcode target and MoltenVK Package (MacCat only)
Xcode scheme to avoid building dynamic MoltenVK.framework for the
Mac Catalyst platform, because Xcode does not support doing so.
- Always run MoltenVK build scripts, to ensure all components are
added to the XCFrameworks, and MoltenVK/Package is always refreshed,
even if code compilation is not required.
- Cube demo link to dynamic MoltenVK.framework through
dynamic/MoltenVK.xcframework, instead of to naked libMoltenVK.dylib.
- Update the version of Volk used by the Cube demo, to support
loading MoltenVK from dynamic frameworks inside Volk.
- Update README.md and MoltenVK_Runtime_UserGuide.md documents.
- Update MVK_PRIVATE_API_VERSION to 40.
- Fix make install to install /usr/local/lib/libMoltenVK.dylib on macOS (unrelated).
- Remove unused MTLAttributeStrideStatic declaration prior to Xcode 15 (unrelated).
This commit conditionally skips the emulated image atomics paths if native
texture atomics are available and a configuration option is set.
Apart from unlocking some potential performance benefits from not having to
force some textures to be linear, it also makes texture atomics work with
argument buffers.
- Expose MTLRenderPipelineDescriptor.sampleMaskMVK and
MTLSamplerDescriptor.lodBiasMVK properties when
MVK_USE_METAL_PRIVATE_API build setting is disabled.
- MVKCmdSetDepthBias & MVKCmdSetDepthBounds subclass from MVKSingleValueCommand.
- MVKRenderingCommandEncoderState simplify calls to set depth bias
and depth bounds, and make consistent with other settings.
- Refactor MVKRenderingCommandEncoderState::setContent() and
setMTLContent() to remove need for intermediate value copies.
- MVKPipeline remove test for depth bounds support since
it's checked before GPU encoding.
- MVKDepthBias member order same as in Vulkan calls.
- Whats_New.md consolidate notes about MVK_USE_METAL_PRIVATE_API.
This isn't even a regular SPI. It's not even present in the Metal
framework. It's exposed by the driver. Only AMD drivers support the
method we need for now.
Metal actually supports this, but this is a hidden property of the
`MTLSamplerDescriptor`. It's not part of the public API. Guard our use
of it appropriately.
This support was always there in Metal. It was just hidden from public
view--but not from prying eyes on the Objective-C metadata.
I had initially thought they were using OpenGL/Vulkan values for the
logic operation. When that didn't work, I then tried D3D11 values. I
guess D3D11 makes sense, because the Intel GPU drivers were the first to
support this in Metal.
Move the definition of `MVK_USE_METAL_PRIVATE_API` into
`"MVKCommonEnvironment.h"` so we can use it from non-C++ code.
With the new `MVK_CONFIG_USE_METAL_PRIVATE_API`, the user can prevent their
use at run time without recompiling MoltenVK. This may be useful for
troubleshooting purposes.
The extra member is because the compiler adds tail padding to make the
struct aligned on an 8-byte boundary, so the `static_assert()` fails
without it.
There are many MVKCommand subclasses that simply encode a single value,
resulting in loads of repetitive copy-pasted code.
- Add abstract template superclass MVKSingleValueCommand
for these concrete command classes.
- Modify MVKCmdSetBlendConstants to hold an MVKColor32 so it can
subclass from MVKSingleValueCommand, and modify MVKGraphicsPipeline
and MVKRenderingCommandEncoderState to use MVKColor32.
- Remove trivial comments for simple concrete Vulkan command classes.
- Add MVK_USE_METAL_PRIVATE_API build setting to allow MoltenVK
to be built with access to Metal private API calls.
- Add support for VkPhysicalDeviceFeatures::wideLines feature
when MVK_USE_METAL_PRIVATE_API is enabled in a MoltenVK build.
- Set lineWidthRange and lineWidthGranularity to reasonable arbitrary values.
Implementation did not correctly handle array textures when resolving
unresolvable textures like r8uint formats. Add kernel modules to
correctly resolve through the compute pass.
Fixes CTS failures in test families:
dEQP-VK.api.image_clearing.core.clear_color_attachment.*
dEQP-VK.renderpass.suballocation.multisample_resolve.*
- Xcode now supports building dylib for iOS Simulator
(but unfortunately not yet tvOS Simulator).
- Restore support for iOS Simulator destination in recent update to
Cube demo that uses dynamic-linking, by using script build phase
to overwrite the iOS build of MoltenVK with the iOS Simulator build.
