Use MVK_CONFIG_AUTO_GPU_CAPTURE_OUTPUT_FILE to set the destination file.
This is useful for capturing traces where the program in question cannot
be run under Xcode's control; the captured trace can then be inspected
later with Xcode.
This new feature requires Metal 3.0 (macOS 10.15, iOS 13).
Special thanks to Epic Games for contributing the underlying support to
SPIRV-Cross.
Metal does not support atomic image accesses, but we can work around
that. For buffer views, and for linear image views, we can pass the
underlying buffer to the shader and do atomic accesses on that. For now,
we only support this for `VK_FORMAT_R32_UINT` and `VK_FORMAT_R32_SINT`,
as required by the Vulkan standard; it should theoretically be possible
to extend this to any format where the size of a pixel is 32 bits. Metal
does not yet support 16-bit or 8-bit atomic access, so those formats are
out for now.
Unfortunately, we cannot yet support this for optimal-tiled images, even
though Vulkan requires it. These images do not have a buffer backing
them. Possible alternatives and their downsides:
* Pass a buffer, probably the buffer backing the device memory, for
these images. But this would defeat the purpose of atomic access--the
buffer and image would not be consistent until afterward when their
contents were sync'd. Using a heap with aliased resources would
eliminate this problem... but, optimal tiling.
* Lie and create a linear image for a format supporting atomic image
access. But that only works for 1D and 2D images with one array slice
and one mip level. Also, this would likely hurt performance, because
the GPU can no longer rely on optimal layout.
Metal viewports and scissors are twice the size of the Vulkan equivalents,
and internal caches are preallocated for 16 of each to avoid dynamic allocations.
Hold the Vulkan viewports and scissors, and convert just before sending them to Metal.
MVKCommandEncoder::clipToRenderArea() use VkRect2D instead of MTLScissorRect.
MVKCommand constructor not longer take MVKCommandTypePool.
Remove MVKCommand::returnToPool().
MVKCommandTypePool no longer track MVKCommandPool.
Remove MVKCommand.mm.
Pass MVKCommandPool to MVKCommand::returnToPool() function.
Add pure virtual MVKCommand::getTypePool() to reference correct
type pool in MVKCommandPool for a subclass instance.
Add MVKFuncionOverride_getTypePool() macro template to define
MVKCommand::getTypePool() overrides in subclasses.
Rename MVKCommandPool::_cmdPushSetWithTemplatePool to
_cmdPushDescriptorSetWithTemplatePool for consistency
with macro template support.
According to the Vulkan spec:
> * If `buffer` is a `VkBuffer` not created with the
> `VK_BUFFER_CREATE_SPARSE_BINDING_BIT` bit set[...] then the
> `memoryTypeBits` member always contains at least one bit set
> corresponding to a `VkMemoryType` with a `propertyFlags` that has
> both the `VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT` bit and the
> `VK_MEMORY_PROPERTY_HOST_COHERENT_BIT` bit set. In other words,
> mappable coherent memory **can** always be attached to these
> objects.
There is no exception for texel buffers. Even though desktop Metal
disallows textures in shared memory, even linear textures created from a
buffer, we have to advertise host-coherent memory for texel buffers.
Some applications actually depend on this behavior, so it's not just a
theoretical concern.
To support host-coherent texel buffers, we implicitly create a managed
buffer and copy data between the device memory and the managed buffer,
just like for a linear image.
Signed-off-by: Chip Davis <cdavis@codeweavers.com>
Naturally, Metal complains when a fragment shader write to a
`[[depth]]` output, but there be no depth attachment. I imagine that it
will also complain if the shader write to ``[[stencil]]`` with no
stencil attachment, or it write to a ``[[color(n)]]`` output with no
corresponding attachment.
MVKShaderConverterTool add support to output SPIR-V as header (.h) files.
Add MVKShaderConverterTool Xcode target.
Add MVKShaderConverterTool Package Xcode scheme.
fetchDependencies builds MVKShaderConverterTool and runs
it on shader files in VulkanSamples API-Samples directory.
Added MVKQueuePerformance::frameInterval performance tracker.
Added MVKPerformanceTracker::latestDuration to track duration of most recent activity.
Swapchain performance can be retrieved with other activity performance through
vkGetPerformanceStatisticsMVK().
Performance logging of all activities can be performed periodically
on a frame-count basis, or inline as the activity occurs.
Add MVK_CONFIG_PERFORMANCE_LOGGING_INLINE env var to enable/disable
logging of performance of each activity when it happens.
Removed vkGetSwapchainPerformanceMVK() and MVKSwapchainPerformance from API.
Updated VK_MVK_MOLTENVK_SPEC_VERSION to 25.
Updated MoltenVK version to 1.0.42.
Add MVKPresentableSwapchainImage and MVKPeerSwapchainImage subclasses to
MVKSwapchainImage, with MVKPresentableSwapchainImage instances created inside
swapchain, and MVKPeerSwapchainImage instances created using vkCreateImage().
MVKPeerSwapchainImage retrieve and share CAMetalDrawable from corresponding
MVKPresentableSwapchainImage.
Remove obsolete MVKSwapchainImageAvailability::waitCount member that was initializing
randomly and corrupting swapchain image acquisition ordering evaluations.
Rename several member functions to clarify purpose.
Fix the make install build command to overwrite the existing framework
in the system framework library.
Update README.md to clarify the instructions for using make install.
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.
Move call to MVKSwapchainImage::resetMetalDrawable() from immediately after
presentation until request to acquire, to preserve image content for copying
after presentation in cases such as an app screen capture operation.
Testing indicates this deferral has little or no adverse effect on the performance
of retrieving the drawable when next needed.
