Add mvkGetRegistryID() function to check OS support for registry ID.
Rename build setting MVK_FORCE_LOW_POWER_GPU to MVK_CONFIG_FORCE_LOW_POWER_GPU
and make it an env var / build setting combo.
Rename env var MVK_LOG_LEVEL to MVK_CONFIG_LOG_LEVEL.
Rename MVKLogging.mm to MVKLogging.cpp.
Track version of spvAux buffer struct in SPRIV-Cross and
fail build if different than version expected by MoltenVK.
Update MoltenVK version to 1.0.33.
Update What's New document.
This could happen, for example, if image views with a non-default
swizzle are used with shaders that don't sample those images. In this
case, MoltenVK will warn, because the pipeline said not to set up the
aux buffer.
This requires macOS 10.13 or iOS 11, for the `currentAllocatedSize`
property of `MTLDevice`. Ideally, we'd check for that method instead of
keying on the version.
Actually turn on the `layeredRendering` feature for A12 on iOS. This
should actually allow clients to take advantage of that on A12 devices.
Turn on the `variableMultisampleRate` and `inheritedQueries` features.
`variableMultisampleRate` means that pipelines with no attachments may
have different sample counts. Since no-attachment pipelines are
emulated, we don't have that limitation anyway. If and when Metal gains
real support for no-attachment pipelines, we may have to revisit this.
`inheritedQueries` means that queries may apply to secondary command
buffers as well as primary commands. Secondary command buffers are also
emulated, and should by virtue of being inlined into the primary's
`MTLCommandBuffer` inherit any query-related state.
Use the `maxBufferLength` property of `MTLDevice` when available to get
the true maximum buffer size. (This is one of the "secret" properties in
earlier versions of Metal. It finally became a public, supported API in
Metal 2.1.)
Limit the number of dual-source blending color attachments to 1. This is
a documented limitation of Metal 1.2. I don't know if Metal 2 or 2.1
have lifted this restriction.
Indicate that this implementation uses the standard sample locations.
For Metal, these are actually documented in "Using Programmable Sample
Positions," which discusses setting custom sample locations. The default
sample locations given there are all consistent with the standard
locations documented in the Vulkan spec.
Add KhronosGroup/Vulkan-Portability as external dependency repo.
Add ExternalRevisions/Vulkan-Portability_repo_revision.
Add vk_extx_portability_subset.h header file to mvk_vulkan.h.
MVKImageView allow constructor with no image or device.
Add mvkVkComponentMappingsMatch() & mvkVkComponentSwizzlesMatch() functions.
Cleanup some local var init warnings.
Glslang does not build SPIRV-Tools when including it.
The `fetchDependencies` script does this when cloning
the repo on its own, but neglects to do this when a path
to a pre-built glslang is provided.
This commit adds the SPIRV-Tools build step when given
a path to a pre-built glslang.
According to the Vulkan spec:
> `sampleCounts` will be set to `VK_SAMPLE_COUNT_1_BIT` if at least one
> of the following conditions is true:
>
> * `tiling` is `VK_IMAGE_TILING_LINEAR` [we already handled this]
> * `type` is not `VK_IMAGE_TYPE_2D`
> * `flags` contains `VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT`
> * Neither the `VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT` nor the
> `VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT` flag in
> `VkFormatProperties::optimalTilingFeatures` returned by
> `vkGetPhysicalDeviceFormatProperties` is set
Use the maximum cube dimensions for cube-compatible images. It makes no
difference in practice, since the maximum dimensions of a cube and a 2D
image are the same on all platforms and devices, but this seems more
correct to me.
We don't support this on any format--not even `VK_FORMAT_R32_UINT`,
which is the only format the spec requires support for. I'm still
waiting for Apple to add support for this to Metal. Until then, stop
telling applications they can use this.
