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.
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.
Dual-source blending is supported on all devices starting with iOS 11.
Cube arrays are supported on A11. Layered rendering and multiple
viewports are supported on A12.
There is nothing in the Vulkan spec to suggest that
`VK_ATTACHMENT_STORE_OP_STORE` and a resolve attachment cannot both be
specified, nor that one or the other has no effect. So, if the app
supplies a color attachment with both `VK_ATTACHMENT_STORE_OP_STORE` and
a resolve attachment, that means it wants the output to be both stored
to the color attachment and resolved to the resolve attachment. In that
case, we should respect the application's wishes and do both. We can
only do that if the device supports this, though. All devices on Mac
starting with macOS 10.12 support this. On iOS, only the A9 and above
support combined store-resolve actions.
of textures or array of samplers requested but not supported.
Add MVKPhysicalDeviceMetalFeatures::arrayOfTextures & arrayOfSamplers flags.
MVKDescriptorSetLayoutBinding log and return appropriate error.
Add MVKPhysicalDevice::getName() and MVKDevice::getName() functions.
Add MVKConfiguration::defaultGPUCaptureScopeQueueFamilyIndex and corresponding
MVK_CONFIG_DEFAULT_GPU_CAPTURE_SCOPE_QUEUE_FAMILY_INDEX env var/build setting.
Add MVKConfiguration::defaultGPUCaptureScopeQueueIndex and corresponding
MVK_CONFIG_DEFAULT_GPU_CAPTURE_SCOPE_QUEUE_INDEX env var/build setting.
Ensure VkDeviceQueueCreateInfo::queueCount is limited to VkQueueFamilyProperties::queueCount.
Update MoltenVK version to 1.0.32.
Update VK_MVK_MOLTENVK_SPEC_VERSION to 17.
MVKConfiguration::fullTextureSwizzle renamed to fullImageViewSwizzle.
Env var MVK_CONFIG_FULL_TEXTURE_SWIZZLE renamed to MVK_CONFIG_FULL_IMAGE_VIEW_SWIZZLE.
Refactor MVKResourcesCommandEncoderState swizzle updates.
Add mvkPackSwizzle(), mvkUnpackSwizzle() & mvkVkComponentSwizzleName() and remove from MVKImage.
Refactor mvkVkResultName() to use literal strings.
Add MVKConfiguration::fullTextureSwizzle and corresponding MVK_CONFIG_FULL_TEXTURE_SWIZZLE
env var & build setting, and set to false, to disable texture swizzling by default.
Add SPIRVToMSLConverterOptions::shouldSwizzleTextureSamples.
Lazily init queue families to allow time for specializedQueueFamilies config change.
Fix consistency of pipeline encoding state auxiliary buffer binding.
Improve documentation of MVKConfiguration environment variables and build settings.
and enable sync queue submits as default.
MVKConfiguration values can be set via runtime environment variables
or compile time build settings.
Enable GPU switching control via MVKConfiguration::switchSystemGPU
and MVK_CONFIG_SWITCH_SYSTEM_GPU env var & build setting.
Enable MVKConfiguration::synchronousQueueSubmits by default.
Set MVKConfiguration::performanceTracking via
MVK_CONFIG_PERFORMANCE_TRACKING env var & build setting.
Set MVKConfiguration::performanceLoggingFrameCount via
MVK_CONFIG_PERFORMANCE_LOGGING_FRAME_COUNT env var & build setting.
Add mvkGetEnvVar(), mvkGetEnvVarInt64() & mvkGetEnvVarBool() functions.
Add MVK_SET_FROM_ENV_OR_BUILD_BOOL(), MVK_SET_FROM_ENV_OR_BUILD_INT32()
& MVK_SET_FROM_ENV_OR_BUILD_INT64() macros.
Rename MVK_CONFIG_MAX_ACTIVE_METAL_COMMAND_BUFFERS_PER_POOL macro
to MVK_CONFIG_MAX_ACTIVE_METAL_COMMAND_BUFFERS_PER_QUEUE.
Add config setting to determine if queue families are general or specialized.
Update to latest SPIRV-Cross version.
Update VK_MVK_MOLTENVK_SPEC_VERSION to 16.
Update MoltenVK version to 1.0.31.
This allows clients to initialize 3D image objects with data in a BC1,
BC2, or BC3 (aka DXTn, aka S3TC) format. Since Metal doesn't support
this natively, DXTn-compressed image data are manually decompressed
prior to upload or copying. This particular algorithm was derived from
Wine, from code originally authored by Connor McAdams. It's somewhat
primitive, and could probably stand some vectorization, but it's a good
first start.
The meat of the algorithm is pulled into a header, "MVKDXTnCodec.def",
intended to be used by both CPU and shader code. CPU uploads, which in
MoltenVK happen when binding a `VkDeviceMemory` object to an image, run
the code normally. GPU uploads, i.e. copying from a buffer to a texture,
run the algorithm as a compute shader, possibly storing the results to
an intermediate buffer to then copy directly to the texture.
Intermediate buffers are used when uploading to mip levels higher than
0, since desktop Metal doesn't support directly writing to higher mip
levels from a shader.
Only uploads are supported. Downloads are not implemented yet.
Theoretically, this could be extended to other compressed formats as
well, allowing MoltenVK to support all texture compression formats on
all platforms.
Decrease minimum swapchain images to 2.
Add MVKPhysicalDeviceMetalFeatures::minSwapchainImageCount & maxSwapchainImageCount.
Minor refactoring of mvkClamp() & MVKPhysicalDevice::getSurfacePresentModes().
Update VK_MVK_MOLTENVK_SPEC_VERSION to 15.
Update MoltenVK version to 1.0.30.
