Discrete GPUs use managed-memory textures, and these need to be synchronized
from GPU memory before being available for host-copying to memory using the CPU.
Metal automatically handles the reverse sync when copying from memory to a texture.
- 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.
- MVKResource::getHostMemoryAddress() return nullptr if
MVKDeviceMemory::getHostMemoryAddress() returns null pointer,
regardless of local offset.
- Remove unnecessary enum value kMVKVkFormatFeatureFlagsTexTransfer
to reduce redundancy between read and transfer feature flag options.
- Fix spelling of mvkVkOffset3DFromMTLOrigin() (unrelated).
- MVKResource remove unnecessary inline qualifiers (unrelated).
- MVKDevice remove some obsolete commentary (unrelated).
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.
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.
