This extension allows the subgroup size to vary between draw/dispatch
calls, and even allows clients to declare that full subgroups must
always be dispatched. It corresponds better to how Metal actually works.
No support for declaring a required subgroup size, unfortunately.
Define MVK_MACCAT build macro and use it to conditionally compile code to align
with build features and capabilities of Mac Catalyst platform on macOS 11.0+.
Treat Mac Catalyst as minor variation of macOS 11.0.
Update documentation.
Currently only support Mac Catalyst on macOS 11.0+, to avoid complexities of
deselecting iOS features and capabilities for Mac Catalyst on previous macOS versions.
Mac Catalyst (and Simulators) require use of XCFrameworks.
Currently unable to generate a dylib for Mac Catalyst.
Also, enable rendering caps on linear textures. This is supported on
Apple GPUs.
Conversely, disable capabilities supported by desktop GPUs that are not
supported on Apple GPUs.
Sadly, no support for 16-bit packed pixel formats on non-Apple GPUs.
VK_EXT_descriptor_indexing adds no new functions, but does add six structures to
existing pNext chains. This initial commit processes these structs, but does not
yet perform any operational functionality for this extension.
Moved to a new model for creation: create and potentially destroy the object
within MVKDevice::create..., to hide it from vulkan.mm where all other object
creation errors are handled. We could move to this slowly over time.
Passes all 49 private data CTS tests.
I've turned on the `Resolve` cap for stencil-only formats, even though
no version of the Metal Feature Set tables lists them as supporting
multisample resolve. Obviously, if they couldn't be resolve
destinations, the stencil-resolve filter that was introduced in Metal
2.1 wouldn't work. I don't know if the platforms and feature sets where
I've turned the bit on is accurate, though. Wider testing is needed.
Because Apple families 1 and 2 don't support depth/stencil resolve at
all, I've disabled the extension for those families. Since sample-zero
resolution is a required feature of Vulkan 1.2, this means we won't be
able to support 1.2 on those devices. If there's demand, we could
possibly have a compute pass which does sample-zero resolution.
This will be needed for two other Vulkan 1.2 extensions,
`VK_KHR_depth_stencil_resolve` and
`VK_KHR_separate_depth_stencil_layouts`.
Most of this is just changing MVKRenderPass to store everything
internally in `RenderPass2` format. I also added some basic handling for
a few things I left out from earlier changes, input attachment aspect
masks and dependency view offsets. The former won't become important
until Metal supports depth/stencil framebuffer fetch. The latter won't
be needed until we start using untracked resources, and therefore need
to insert explicit fences and/or barriers between subpasses. We don't
need either right now, but I've handled them regardless.
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.
- Delete fat library and framework scripts and templates.
- MoltenVK build package now only includes one XCFramework, and separate platform dylibs.
- Modify fetchDependencies and Makefile targets to not build fat libraries,
and to build simulators separately than platforms instead.
- Script package_moltenvk.sh now copies dylibs for all built platforms.
- Consolidate package_all.sh and delete package_one_os.sh.
- Swap names of copy_lib_to_staging.sh and copy_to_staging.sh scripts.
- Cube demo now uses MoltenVK as XCFramework, and support Simulator builds.
- Hologram demo now uses MoltenVK as dylibs from new packaging location.
- API-Samples demo now uses MoltenVK as XCFramework.
- Update documentation.
This extension provides weaker guarantees than `VK_EXT_robustness2` and
its `robustImageAccess2` feature. Metal easily meets those guarantees,
with no action on our part necessary.
We only support the `robustImageAccess2` feature for now. Metal's
guarantees around out-of-bounds accesses to textures give us this for
free. `nullDescriptor` should also be possible to implement, but it
needs testing. Null image descriptors will probably just work, but null
buffer pointers probably not. We may need help, either from SPIRV-Cross
or a pass in SPIRV-Tools. `robustBufferAccess2` definitely needs an
assist from SPIRV-Tools. All three are useful for Direct3D compatibility
layers (DXVK, wined3d).
The link contains a space between the right square bracket and subsequent left round bracket causing the link to display incorrectly in GitHub's markdown reader.
Declare _formatDescriptions[] in mvk_datatypes.mm as officially writable
because Clang now locates static const in non-writable memory.
Update build settings to Xcode 11.
Update MoltenVK_Runtime_UserGuide.md about embedding `libMoltenVK.dylib` in an application.
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.
This extension lets implementations report separate limits for uniform
and storage texel buffers, as well as whether or not the required
alignment is only a single texel of the buffer view's format.
This information is available in Metal, but only through an API query.
We must query the required alignment for every buffer view format we
support.
Update Vulkan-Headers to pull in support for this new extension.
Only some of the color spaces provided by this extension are supported.
macOS 10.12 supports a few more. macOS 10.14 (at least, according to the
*10.15* SDK) supports even more. (But that needs a change to the
Metal-3.0 branch.)
I've chosen to group by color space. That way, programs will find the
all the supported formats early on. Programs that are interested in
the color space can keep looking.
This is supported by Mac GPU Family 2 starting on macOS 10.14, and Apple
GPU Family 5 starting on iOS 12.
Supporting this is a bit tricky. Because only some devices support this
extension, we now have to keep track of supported device extensions per
device.
