Test for _pMetalFeatures->layeredRendering before setting
MTLRenderPassDescriptor.renderTargetArrayLength.
Change NSString comparisons using isEqualTo: to isEqualToString:.
Sometimes, the `CAMetalLayer` backing a view can be replaced--for
example, when the window is moved to another screen, or the style bits
on the window are changed. In that case, we must allow the client the
opportunity to recreate the surface and swapchain.
Layer-backed views always set themselves as the layer's delegate; we use
this fact to Key-Value Observe the view's `layer` property.
Other alternatives considered:
* Registering for `NSViewGlobalFrameDidChange` notifications. Aside from
only working on macOS, this doesn't actually catch every case where we
want to report a lost surface. I'm not even sure it works at all for
Metal.
* Holding a reference to the view, and checking when its layer property
has changed.
* Holding a weak reference to the layer; that way, the reference will
become `nil` when the layer is replaced. But this requires ARC.
Some projects also link against SPIRV-Cross statically, and in order to
avoid ABI conflicts, we should use a private namespace for the
SPIRV-Cross dependency to avoid bugs. See SPIRV-Cross issue #902 for
more information. The new namespace is MVK_spirv_cross, and the code
now makes use of the SPIRV_CROSS_NAMESPACE macro rather than spirv_cross.
The resource options must match between an `MTLBuffer` and any linear
texture created from it. Further, to be writable, the
`MTLTextureDescriptor` should have the `MTLTextureUsageShaderWrite` bit
set.
Fixes#542.
graphics pipeline during a compute stage.
MVKPushConstantsCommandEncoderState test for tessellation only during graphics stages.
Guard against possible missing graphics pipeline even during graphics stages.
Enable device features based on content of pCreateDeviceInfo.
Validate requested features are available and return if not.
Support returning error from vkCreateDevice(), vkFlushMappedMemoryRanges()
and vkInvalidateMappedMemoryRanges().
Update What's New Document.
tool now validates converted MSL with a test compilation.
Project build scripts now build dylib and framework in separate build directories
to enable MoltenVKShaderConverter to link to static library instead of dynamic library.
Final Package structure remains the same.
In Debug build, copy dylib dSYM files to Package.
Package/Latest directory now links relative to local Debug or Release directory.
Add install option to Makefile.
MoltenVKShaderConverter tool now validates converted MSL with a test compilation.
Clean up various MSL conversion and compilation error logging.
MVKCommandResourceFactory wrap Metal library compile with autorelease pool.
Build ExternalDependencies with same symbol hiding as MoltenVK to suppress visibility warnings.
Update What's New document.
According to the Vulkan spec:
> * If either of `srcImage` or `dstImage` was created with a
> depth/stencil format, the other **must** have exactly the same format
So this should not happen in well-behaved clients.
Add support for VK_KHR_get_surface_capabilities2 extension.
Implement newer VK_KHR_swapchain extension functions.
Fix when the following functions return VK_INCOMPLETE:
vkGetPhysicalDeviceSurfaceFormatsKHR()
vkGetSwapchainImagesKHR()
vkEnumeratePhysicalDevices()
vkEnumerateInstanceLayerProperties()
vkGetPhysicalDeviceQueueFamilyProperties()
CTS: Pass supported *.macos.surface.* and *.macos.swapchain.* tests.
Update What's New document.
Add MVKEntryPoint struct to track entry points as
instance vs device, and core vs enabled extensions.
Add stubs for newer VK_KHR_swapchain functions.
Pass CTS dEQP-VK.api.version_check.entry_points.
Update What's New document.
This allows clients to reset query pools on the host, instead of with a
GPU command.
This updates Vulkan headers to 1.1.104... but, there's a problem. This
change has not been merged to `master` in the `Vulkan-Headers` repo yet,
because of an issue building the C++ binding headers. Luckily, we only
need the core C header.
If none of the attributes in a buffer is used but still present, then
the offset will be non-zero, leading us to set a non-zero stride for a
vertex buffer that is not used. This is invalid.
Fixes tessellation in Final Fantasy XIV.
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.
