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.
Support runtime shader compilation from GLSL.
Return VK_ERROR_INVALID_SHADER_NV on shader and pipeline compilation errors.
Add MVKShaderCompilationPerformance::glslToSPRIV to track GLSL conversion performance.
Rename MoltenVKGLSLToSPIRVConverter MVKShaderStage enum to MVKGLSLConversionShaderStage
to avoid naming conflicts with MoltenVK MVKShaderStage enum.
Hologram demo load SPIR-V directly instead of using GLSL through either
MoltenVKGLSLToSPIRVConverter or VK_NV_glsl_shader extension.
Update to latest version of VulkanSamples that supports MVKGLSLConversionShaderStage.
Add MVKDebugReportCallback class.
Add MVKVulkanAPIObject class as base class of classes exposed in Vulkan API.
Remove MVKRefCountedDeviceObject class and move ref-counting to MVKVulkanAPIObject.
Rename MVKDispatchableObject class to MVKDispatchableVulkanAPIObject.
Introduce multiple inheritance mixin classes into class hierarchy.
Add MVKBaseObject::getVulkanAPIObject() function to find Vulkan API object
controlling any subobject that needs to report something.
MVKCommandResourceFactory functions pass in calling object for reporting.
Add MVKBaseObject::reportMessage() & reportError() functions.
Replace mvkNotifyErrorWithText() static function with reportError()
instance function to allow access to debug reporting.
Redefine MVKLog*() functions to call reportError() instance method.
Delete MVKLogging.cpp.
Remove MVKLogging.h from MoltenVKShaderConverter project.
Add mvk_datatypes.hpp to redirect errors in mvk_datatypes.h functions to debug
reporting. Use mvk_datatypes.hpp internally for all references to these functions.
Convert several static methods to instance methods.
Refactor platform defines in MVKSurface.h.
Explicitly count MVKExtensionList extension count to avoid relying on struct size.
Remove MVKCommandBuffer::recordResult() and use setConfigurationResult().
Change log indication of error in logs from [***MoltenVK ERROR***] to [mvk-error],
for consistency with other log level indications.
Update MoltenVK version to 1.0.35.
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.
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.
Refactor build scripts.
Update paths to MoltenVKGLSLToSPIRVConverter framework in demos.
Fix rare build race condition on MoltenVKShaderConverter link to MoltenVK.
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.
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.
