- Remove _unused_struct_padding from MVKConfiguration and MVKConfigMembers.def.
- Add kMVKConfigurationInternalPaddingByteCount to specify MVKConfiguration
internal padding byte count, for use in build time assertion check.
Apple's Automatic Reference Counting automatically releases
the Metal objects returned by VK_EXT_metal_objects.
The fetchDependencies script now applies
Templates/Vulkan-Headers/VK_EXT_metal_objects-unret.gitdiff
to add an __unsafe_unretained ownership qualifier to the
Metal object declarations in vulkan_metal.h.
This should be a temporary patch until the VK_EXT_metal_objects
extension can be properly modified.
After the recent change to building dynamic frameworks and dylibs as targets
built by linking to a static library dependency, incremental builds do not
correctly link the dynamic frameworks and dylibs to the rebuilt static library.
- Delete dynamic target outputs during static target builds.
- Run platform schemes sequentially in manual order.
- Build the dynamic framework before the dylib.
- Clean up Xcode Scheme organization.
It is not entirely obvious what the dependency problem is, and why
these particular changes work. A lot of trial-and-error was required.
It's possible that Xcode dependency analysis does not correctly analyze
the flow used in MoltenVK builds.
- .gitignore exclude all directories under External, to allow
temp directories to be created during dependency developments.
- .gitignore specify MoltenVK exclusions are relative to root directory.
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.
