On Intel devices, Metal reports different values for max threadgroup width
between the pipeline state and device, so conservatively use the minimum of
these two reported values.
Remove obsolescence log message for vkCreateMacOSSurfaceMVK()
and vkCreateIOSSurfaceMVK() functions.
Fix test for alignment of invalid pixel formats.
Update dependency libraries to match Vulkan SDK 1.1.121.
Update to renaming of VK_INTEL_shader_integer_functions2
enums and structs in latest Vulkan headers.
Update Whats_New.md document.
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.
This limitation appears to be have been present all along (cf. Metal
Feature Set Tables, under "Maximum function memory allocation for a
buffer in the constant address space"). I guess we never ran into it
before.
Prompted by #730.
MVK_ALLOW_METAL_FENCES environment variable.
Refactor MVKSemaphore class into separate MVKSemaphoreMTLFence,
MVKSemaphoreMTLEvent, and MVKSemaphoreEmulated subclasses.
Add MVK_ALLOW_METAL_FENCES environment variable to optionally
enable using MTLFence for Vulkan semaphores.
Add MVKPhysicalDeviceMetalFeatures::fences to track MTLFence availability.
Update VK_MVK_MOLTENVK_SPEC_VERSION to version 22.
Use parallelism more effectively to massively cover buffer with
multiple full threadgroups, instead of serial looping in shader.
Performance improvement measured at 150x (yes...x not %) on macOS.
MVKCmdFillBuffer move validation test to setContent() instead of encode().
One set of MVKSemaphore::encodeWait() & encodeSignal() functions either use MTLEvent
or not, and are called twice with and without MTLCommandBuffer to handle both cases
of encoded and inline waits and signals.
Always submit surface presentations using MTLCommandBuffer.
MVKConfiguration::presentWithCommandBuffer is now obsolete.
Fix memory leak of MVKQueueCommandBufferSubmissions with no content.
MVKExtensionList add support for identifying and enabling instance or device extensions.
Rename MVKLayer::getExtensionProperties() to getInstanceExtensionProperties() and
MVKLayer::getSupportedExtensions() to getSupportedInstanceExtensions().
This is the heap representing system memory. The memory type
corresponding to `MTLStorageModeShared` is reported as belonging to this
heap.
I've tried to correct the reported size of the heaps as well while I'm
at it. UMA GPUs and the system heap for NUMA GPUs use the system memory
size as the heap size, and the amount of available memory as the budget.
iOS 13 uses the new `os_proc_available_memory()` API for this purpose.
NUMA GPUs additionally use the memory used by the process as a crude
measure of system heap usage.
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.
All Apple GPUs support this, as does Mac GPU family 2. With this, we can
avoid expensive copies between buffers and textures allocated from the
same memory, and reduce memory usage to boot.
macOS is, unfortunately, constrained by the fact that `MTLHeap` objects
do not support any storage mode other than `MTLStorageModePrivate`--not
even `MTLStorageModeManaged`. This won't help for managed textures
there. Perhaps Apple will fix this in a later version.
The old `DCI_P3_LINEAR` enum is deprecated. Use
`VK_COLOR_SPACE_DISPLAY_P3_LINEAR_EXT` instead. This is a closer match
for the Core Graphics name anyhow.
