This has caused us nothing but trouble. The code to build up the vertex
descriptor is fragile; we can rip that out now.
Also, make sure to positively identify per-patch blocks as per-patch.
For those, the individual members have the `Patch` decoration.
Update SPIRV-Cross to pull in the changes needed for this.
Fixes 66 tests in the CTS.
MSL: Handle descriptor aliasing of raw buffer descriptors.
MSL: Do not attempt to alias push constants.
MSL: Report unsupported 64-bit atomics.
MSL: Add more keywords to reserved set.
It is always legal in Vulkan to read a builtin, particularly
`BuiltInPosition`, even if it weren't written by the previous stage. The
CTS tests that this scenario works in the driver.
Update SPIRV-Cross to pull in a change required for this.
Fixes 8 CTS tests under `dEQP-VK.pipeline.*.no_position`. (Eight other
tests worked solely by accident without this change.)
- Update to latest SPIRV-Cross to support `SPV_KHR_physical_storage_buffer`
for `VK_KHR_buffer_device_address` and `VK_EXT_buffer_device_address`
- Add support for `VK_EXT_buffer_device_address` extension.
- Advertise support for `VK_KHR_buffer_device_address`
and `VK_EXT_buffer_device_address` on macOS 12.5.
- Add appropriate extension reporting and enablement for
`VkPhysicalDeviceBufferDeviceAddressFeatures`,
`VkPhysicalDeviceBufferDeviceAddressFeaturesEXT`, and
`VkPhysicalDeviceFragmentShaderBarycentricFeaturesKHR`.
- Support reading `VkMemoryAllocateFlagsInfo` to identify memory allocations that
need to support buffer pointer access (in case needed in future on non-shared memory).
- Update `Whats_New.md` and `MoltenVK_Runtime_UserGuide` documents.
mvk::getShaderOutputs() in SPRIVReflection.h support flattening nested structures.
MoltenVKShaderConverter tool support loading tessellation shader files.
MoltenVKShaderConverter tool update to MSL 2.4 by default.
Remove use of deprecated MTLCreateSystemDefaultDevice().
Update to latest version of SPIRV-Cross.
Do not use MTLEvent for VkSemaphore under Rosetta2.
Remove compile test for MVK_MACOS_APPLE_SILICON and MVK_APPLE_SILICON when testing
for Apple GPU families, to allow x86 builds to test for Apple GPU under Rosetta2.
Simplify identifying M1 GPU. All M1 SoCs currently support the A14 (Apple7) GPU.
Support compiling MSL 2.4 in runtime pipelines and MoltenVKShaderConverterTool.
Fix issue where MSL 2.3 only available on Apple Silicon, even on macOS.
Update to latest SPIRV-Cross (unrelated to Rosetta2).
Support maximum point primitive size of 511.
Update to latest SPIRV-Cross version to add support
for OpSpecConstantOp ops OpQuantizeToF16 and OpSRem.
Update MoltenVK version to 1.1.6.
MSL: Support row-major transpose when storing matrix from constant RHS matrix.
MSL: Fix casting in constant expressions with different sizes.
MSL: Fix duplicate gl_Position outputs when gl_Position defined but unused.
On systems not supporting this, the subgroup size is set to 1.
Make sure the subgroup size is fixed in the shader, at least until we
implement `VK_EXT_subgroup_size_control`.
According to the Metal feature set tables, SIMD-group reduction is only
supported on Mac family 2 GPUs and Apple family 7 GPUs. Previously, we
were exposing these on all Mac GPUs.
Quadgroup permutation is supported on all Apple GPUs starting from
family 4. We use them for regular group non-uniform ops as well, so
these are considered to have a subgroup size of 4. On Mac, it's a bit
more complicated. The 2.1 tables say that all Mac GPUs support this, but
the 3.0 and 4.0 tables say that only family 2 supports quadgroup ops.
I've allowed quad ops on family 1 for now.
Unfortunately, my testing shows that SIMD-group functions don't work in
fragment shaders on Mojave, so no fragment shader support until Metal 3.
Update SPIRV-Cross to pull in changes needed for all this.
This was actually added in iOS 13, but it wasn't present in the betas.
Since the betas also didn't support family 6, this leads me to suspect
that `min_lod_clamp()` requires family 6. So to be safe, only enable the
feature on family 6.
Update SPIRV-Cross to pull in the changes needed for this.
This is now supported in MSL 2.3. Support varies by device; devices that
support this return `YES` from `supportsPullModelInterpolation`. Based
on my testing, AMD devices do not yet support this, and Intel devices
do. Apple GPUs probably also support this, in order to support OpenGL on
top.
Update SPIRV-Cross to pull in the changes needed for this.
MVKDevice track enabled VkPhysicalDeviceInlineUniformBlockFeaturesEXT features.
Disable prefilled MTLCommandBuffers if update after binding enabled.
Update to latest SPIRV-Cross that includes support for unsized arrays.
Originally, Metal did not support this directly, and still largely
doesn't on GPUs other than Apple family 6. Therefore, this
implementation uses vertex instancing to draw the needed views. To
support the Vulkan requirement that only the layers for the enabled
views are loaded and stored in a multiview render pass, this
implementation uses multiple Metal render passes for multiple "clumps"
of enabled views.
For indirect draws, as with tessellation, we must adjust the draw
parameters at execution time to account for the extra views, so we need
to use deferred store actions here. Without them, tracking the state
becomes too involved.
If the implementation doesn't support either layered rendering or
deferred store actions, multiview render passes are instead unrolled and
rendered one view at a time. This will enable us to support the
extension even on older devices and OSes, but at the cost of additional
command buffer memory and (possibly) worse performance.
Eventually, we should consider using vertex amplification to accelerate
this, particularly since indirect multiview draws are terrible and
currently require a compute pass to adjust the instance count. Also,
instanced drawing in itself is terrible due to its subpar performance.
But, since vertex amplification on family 6 only supports two views,
when `VK_KHR_multiview` mandates a minimum of 6, we'll still need to use
instancing to support more than two views.
I have tested this extensively against the CTS. I'm very confident in
its correctness. The only failing tests are
`dEQP-VK.multiview.queries.*`, due to our inadequate implementation of
timestamp queries; and `dEQP-VK.multiview.depth.*`, due to what I assume
is a bug in the way Metal handles arrayed packed depth/stencil textures,
and which may only be a problem on Mojave. I need to test this on
Catalina and Big Sur.
Update SPIRV-Cross to pull in some fixes necessary for this to work.
Fixes#347.
SPIRV-Cross can now AND the `gl_SampleMask` output with an additional
fixed mask, presumably from the pipeline. Use this new functionality to
implement pipeline sample mask handling.
Special thanks to Tomek Pontika and Corentin Wallez of Google for
graciously contributing their implementation to SPIRV-Cross.
Update SPIRV-Cross to pull in the change necessary for this.
Metal is picky about interface matching. If the types of a vertex output
and its corresponding fragment input don't match, down to the number of
vector components, it fails pipeline compilation. To support cases where
the number of components in the fragment input is less than the
corresponding vertex output, we need to fix up the fragment shader to
accept the extra components.
Add Scripts/packagePregenSpirvToolsHeaders script to automate packaging Spirv-Tools
headers in support of the fetchDependencies --skip-spirv-tools-build option.
Update Docs/Whats_New.md.
Update Cereal archive structs to match latest MoltenVK and SPIRV-Cross structs.
Fix recent error that caused pipeline cache data to be ignored during loading.
Update to Vulkan-Headers version 1.2.135.
Update to latest SPIRV-Cross version.
Update Whats_New.md document.
Add SPIRVShaderOutput::isUsed retrieved from shader reflection.
mvk::sizeOfOutput() returns zero if output var is not used.
Update to latest SPIRV-Cross version.
Add `MVK_CONFIG_TEXTURE_1D_AS_2D` environment variable, enabled by default.
Modify 1D warning messages to recommend use of `MVK_CONFIG_TEXTURE_1D_AS_2D`.
Update to latest version of SPIRV-Cross.
Align pipeline cache contents to latest CompilerMSL::Options structure.
Clean up code signing on demo Xcode projects.
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.
