At long last, tessellation comes to MoltenVK! With this change, clients
will now be able to specify tessellation shaders when creating
pipelines, and then draw tessellated patches with them.
Unfortunately, there seem to be a few gotchas with tessellation in
Metal. For one thing, tessellation pipelines in Metal are structured
very differently from Vulkan. There is no tessellation control or even
vertex stage. Instead, the tessellation evaluation shader takes the
place of the vertex function as a "post-tessellation vertex function."
The tessellation levels are supplied in a buffer to the tessellator,
which you are expected to populate. The most common way to do this is by
running a compute shader. MoltenVK thus runs the vertex shader and
tessellation control shader by themselves; a single `VkPipeline` object
then requires at least *three* `MTLPipelineState` objects.
But wait, there's more! The tessellation-control-as-compute stage uses
Metal's support for vertex-style stage input to a compute shader. But,
this support requires one to declare indexing *ahead of time*, when the
pipeline state is created. So a single `VkPipeline` object could have as
many as *five* `MTLPipelineState` objects.
Further, if there are more output than input control points for the
tessellation control stage, then later invocations may end up fetching
the wrong attributes! To get around this, this change uses index buffers
to ensure that all tessellation control shaders see the correct input.
Unfortunately, in the indexed draw case, this means that the incoming
index buffer needs to be munged.
Instancing is another pain point here. In Vulkan, as in OpenGL and
Direct3D, instancing is done in the vertex shader; but in Metal, it is
done at the tessellation evaluation stage. For this reason, only the
vertex stage of a tessellated draw supports instancing. Additional
memory is required to hold data for the extra vertices generated by
instancing. This also requires still more munging of index buffers for
indexed draws.
Indirect draws are even more painful. Because the number of vertices and
instances is unknown, storage for the maximum possible number of
vertices must be allocated. This change imposes a totally arbitrary
limit of 131072 vertices from a single draw, including all vertices
generated by instancing. On a Mac, this requires about 194-256 MB of
VRAM for all the temporary buffers.
There are some possible optimizations here. If we could prove that the
vertex shader's output doesn't depend on the instance ID, either
directly or through a per-instance attribute, then we could avoid
running the vertex and tess. control stages per instance, and take
advantage of Metal's support for tess. eval instancing. If we could
also prove that the vertex shader simply passes instance attributes
through (similarly with the tess. control shader), we could do this for
many more instanced draws as well. It should also be possible to cache
the output from the tess. control stage; if the draw comes up again, we
can then skip the vertex and tess. control stages entirely!
Fixes#56 and #501.
Add MVKPhysicalDeviceMetalFeatures::mslVersionEnum and set from Metal feature sets.
Derive MVKPhysicalDeviceMetalFeatures:: mslVersion from mslVersionEnum.
MVKDevice::getMTLCompileOptions() sets MTLCompileOptions::languageVersion
from MVKPhysicalDeviceMetalFeatures::mslVersionEnum.
MVKAssert logs error even when assertions disabled.
Update VK_MVK_MOLTENVK_SPEC_VERSION to 18.
While Metal *does* allow read access to multisampled textures, it does
*not* allow write access. In Vulkan, storage images are always writable.
Therefore, we can't fully support this feature.
Refactor build scripts.
Update paths to MoltenVKGLSLToSPIRVConverter framework in demos.
Fix rare build race condition on MoltenVKShaderConverter link to MoltenVK.
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.
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.
