This extension allows fragment shaders to delineate critical sections
where pairs of invocations may not execute simultaneously. In Metal, the
nearest equivalent functionality is raster order groups. This
implementation is thus implemented on top of them.
Update SPIRV-Cross to pull in SPIR-V support for this new extension.
Largely minimal for now. Much of it, particularly most of the
interactions with `VK_KHR_swapchain`, was already implemented
previously. The only interesting bits are the `vkCmdDispatchBase()`
command, and the ability to create arbitrary swapchain images and bind
them to swapchain memory, which requires the use of the previously
implemented `VK_KHR_bind_memory2` extension. Most everything else can be
safely ignored for now.
Non-zero dispatch bases use the compute stage-input region to pass the
dispatch base group to the shader, which must manually adjust the
`WorkgroupId` and `GlobalInvocationId` builtins, since Metal does not do
this for us. I have tested that this approach works well--at least, well
enough to pass the CTS.
Because of the ability to bind arbitrary images to swapchain memory,
I've sucked the guts out of `MVKSwapchainImage` and into `MVKSwapchain`
itself. Availability and drawable management is now performed by the
swapchain object. `MVKSwapchainImage` is now just a specialized kind of
image, created when requested with a `VkImageCreateSwapchainInfoKHR`
structure.
Update SPIRV-Cross so we can support the `vkCmdDispatchBase()` command.
One more step towards Vulkan 1.1.
Refactor SPIRVToMSLConverterContext into distinct SPIRVToMSLConversionConfiguration
and SPIRVToMSLConversionResults for conversion input and output, respectively.
Update to latest SPIRV-Cross version.
Update What's New document.
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.
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.
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.
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.
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.
For each GPU, log MSL version and updated list of feature sets.
Add SPIRVToMSLConverterOptions::printMSLVersion() function.
Update to latest SPIRV-Cross version.
Update MoltenVK version to 1.0.29.
Based on a patch by Stefan Dösinger.
Metal cannot do signedness conversion on vertex attributes, and for good
reason. Putting a `uint4` into an `int4`, or a `char4` into a `uint4`,
would lose those values that are outside the range of the target type.
But putting a `uchar4` into a `short4` or an `int4`, or a `ushort4` into
an `int4`, should work. In that case, force the signedness in the shader
to match the declared type of the host.
Update SPIRV-Cross to pull in the corresponding change. Bump MoltenVK
version.
Update to latest dependency libraries for Vulkan SDK 1.1.92.
Generate Hologram demo dispatch files in fetchDependencies and remove them from git.
Update MoltenVK version to 1.0.27.
Update What's New document.
Fixes to create_dylib.sh to cleanup bitcode and architecture support.
Update to latest SPIRV-Cross version.
Update MoltenVK version to 1.0.26.
Update Xcode projects to Xcode 10.1.
Update What's New document.
The swizzles are passed to shaders that need them using an "auxiliary
buffer", for which there must be room in the function argument table.
Code is inserted into the shaders to swizzle reads from sampled
textures--per the Vulkan spec, component mappings must only be applied
to sampled images.
Update SPIRV-Cross to pull in some fixes for handling swizzled image
data. Bump MoltenVK version.
Update SPIRV-Cross to support dynamic indexing on iOS 10... and to
actually support arrays of input buffers (which should've been present
before I flipped the `shader{Uniform,Storage}BufferArrayDynamicIndexing`
switch).
Bump patch version.
Fixes#96.
This is for fragment shaders that run per-sample instead of
per-fragment. It implies that the `SampleId`, `SampleMask`, and
`SamplePosition` builtins, as well as per-sample interpolation, are all
available--using any of these causes the frag shader to run once per
sample. (In Metal, reading the color buffers may also cause a frag
shader to run per-sample.)
Update SPIRV-Cross to pull in a change that properly translates the
`SamplePosition` builtin to a form that Metal can understand.
Remove linking MoltenVKSPIRVToMSLConverter from Build Phase in favour of PreLink.
Update to Vulkan header 1.1.83.
Update to latest version of library dependencies.
Add SPIRVToMSLConverterOptions::isRasterizationDisabled to allow pipeline
and vertex shader to communicate rasterization status.
Update to latest SPIRV-Cross version.
Update MoltenVK version to 1.0.17.
MVKCmdClearAttachments support clearing multiple attachment layers.
MVKCmdClearImage use renderpass clear, and support clearning multiple image layers.
Rename mvkCmdClearImage() to mvkCmdClearColorImage().
MVKDevice add getFormatIsSupported() to allow devices to test for format support.
MVKFramebuffer support multiple layers.
mvk_datatypes.h support both 2D and 3D mipmap calculations and allow
mvkMTLPrimitiveTopologyClassFromVkPrimitiveTopology() in iOS.
Remove support for VK_FORMAT_B10G11R11_UFLOAT_PACK32 & VK_FORMAT_E5B9G9R9_UFLOAT_PACK32
since format components are reversed on Metal.
Move OS extension source files to new OS directory.
Update to latest SPIRV-Cross version.
Update MoltenVK version to 1.0.16.
On iOS, only compile IOSurface support, and link IOSurface framework to
libMoltenVK.dylib, if IPHONEOS_DEPLOYMENT_TARGET is at least iOS 11.0.
Update to latest version of SPIRV-Cross.
Update MoltenVK version to 1.0.15.
Support separate specialization for each workgroup dimension.
Support zero as a specialization ID value.
Cleanup MoltenVKShaderConverterTool.
Update to latest SPIRV-Cross version.
Update MoltenVK version to 1.0.14.
Map 1D buffer view contents to 2D Metal texture.
Add MVKPhysicalDeviceMetalFeatures::maxTextureDimension element.
Set VkPhysicalDeviceLimits::maxTexelBufferElements to maxTextureDimension ^ 2.
Shaders accessing buffer view use special function to map 1D buffer view coordinates
to 2D Metal texture coordinates.
Pass maxTextureDimension to shader.
Update to latest SPIRV-Cross version for appropriate shaders.
Update MoltenVK version to 1.0.13.
Add MVKDeviceConfiguration::synchronousQueueSubmits configuration setting.
Update to latest SPRIV-Cross version to fix atomic_compare issue.
Update MoltenVK version to 1.0.8.
