Convert MVKCmdBindVertexBuffers to template class.
Add MVKAddCmdFromTwoThresholds() macro in vulkan.mm.
Add MVK_CMD_TYPE_POOLS_FROM_TWO_THRESHOLDS() macro in MVKCommandTypePools.def.
Add second threshold to MVKCmdBeginRenderPass.
MVKCmdBeginRenderPass don't hold VkRenderPassBeginInfo.
Convert MVKCmdBeginRenderPass and MVKCmdExecuteCommands to template classes.
MVKCommandBuffer::recordBeginRenderPass() pass MVKLoadStoreOverrideMixin
instead of MVKCmdBeginRenderPass.
MVKCommandBuffer::recordEndRenderPass() pass nothing.
Add MVKAddCmdFromThreshold() macro in vulkan.mm.
Add MVK_CMD_TYPE_POOLS_FROM_THRESHOLD() macro in MVKCommandTypePools.def.
Move null tests on destroy calls from vulkan.mm to MVKDevice and MVKInstance.
Don't bother testing for null when spec says a param must not be null.
Invert remaining null tests so they don't abort.
Remove MVKResource::bindDeviceMemory2() and MVKBindDeviceMemoryInfo struct.
Add separate MVKBuffer::bindDeviceMemory2() and MVKImage::bindDeviceMemory2()
functions with distinct params, and delegate to MVKResource::bindDeviceMemory().
Functions and functionality supported, but don't currently do anything
until Metal-friendly enumerations added to VkExternalMemoryHandleTypeFlagBits.
Updated What's New document.
Capability functions and functionality supported, but don't currently do anything
until Metal-friendly enumerations added to VkExternalMemoryHandleTypeFlagBits.
Rename MVKPhysicalDevice::getPhysicalDeviceMemoryProperties() to
getMemoryProperties() for consistency.
Updated What's New document.
To allow these classes to contain reasonably-sized pre-allocated vectors,
make MVKCmdSetViewport & MVKCmdSetScissor template classes based on quantities.
Create two concrete implementations of each for 1 and 16 viewports or scissors.
vkCmdSetViewport() and vkCmdSetScissor() choose which concrete template class
implementation to use based on the number of viewports or scissors, respectively.
Update auto-generation of getTypePool() to support template classes when needed.
Many of the names of the MVKPixelFormats member functions where inherited from
function names in mvk_datatypes.h, which is a C API, therefore must have unique
function names, and uses parameter types as part of the names to distinguish.
Since MVKPixelFormats is a C++ class, we can do away with that and make use
of function overloading to simplify the function names.
I forgot to to this when creating MVKPixelFormats in the first place.
Start with no Vulkan atomic feature bits and add VK_FORMAT_FEATURE_STORAGE_IMAGE_ATOMIC_BIT
and VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT if Metal format supports it.
Currently only applies to formats MTLPixelFormatR32Uint and MTLPixelFormatR32Sint.
Enable for linear tiling only. Previously optimal was enabled too.
Add kMVKMTLFmtCapsAtomic.
Add kMVKVkFormatFeatureFlagsTexAtomic.
Add kMVKVkFormatFeatureFlagsBufAtomic.
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.
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.
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.
