Remove SPIRV-Cross/ qualifier from include references to SPIRV-Cross header files.
Remove glslang/ qualifier from include references to glslang header files.
This change allows easier integration with app build scripts.
When mvkGetMVKConfiguration()->advertiseExtensions is disabled, and MoltenVK
artificially advertises that all extensions are not supported, allow the functions
of those extensions to be called anyway.
Some CTS tests are structured to assume one or more basic extensions are supported,
and do not bother checking for those extensions and provide alternate code paths
based on the extension not being supported. Permitting the calls to be made anyway
allows those tests to proceed and avoid crashing.
Fixes to MVKQueueCommandBufferSubmission:
- Consolidate MTLCommandBuffer completion callbacks, and ensure all other activities,
including logging, which references the object, occurs before finish() is called.
- Remove separate flag that indicates whether to track MTLCommandBuffer completion times.
- Localize Vulkan error reporting to the queue instead of the device.
If we're on macOS 11 or iOS/tvOS 14, and debug mode (`MVK_DEBUG=1`) were
enabled, then we'll enable enhanced command buffer errors, which give us
more information about which encoder triggered the error. We'll also
print log messages from shader validation.
Always advertise VK_KHR_portability_subset. Advertise other extensions only if
MVKConfiguration::advertiseExtensions enabled and extension available on platform.
Reorganize and simplify checking extension platform availability.
Add MVKConfiguration::apiVersionToAdvertise and MVK_CONFIG_API_VERSION_TO_ADVERTISE
env var to configure MoltenVK to advertise a particular Vulkan version.
Advertise MVKConfiguration::apiVersionToAdvertise in:
vkEnumerateInstanceVersion()
vkGetPhysicalDeviceProperties()
vkEnumerateInstanceLayerProperties()
vkEnumerateDeviceLayerProperties()
Add MVKConfiguration::advertiseExtensions and MVK_CONFIG_ADVERTISE_EXTENSIONS
env var to configure MoltenVK to not advertise support for any Vulkan extensions.
Refactor population of MVKConfiguration from environment variables to better
support validating and baking config values set by app.
Update MoltenVK version to 1.1.3.
Update VK_MVK_MOLTENVK_SPEC_VERSION to 31.
Some buffers, particularly those used by tessellation, indirect
multiview, or occlusion queries, are never written or read from the
host. Keeping the relevant data in VRAM should improve performance by
reducing the need for the GPU to make expensive accesses over the PCI
bus.
VRAM is a scarce resource on discrete GPUs, but this is part of why we
marked the buffers volatile.
Derive MVK_APPLE_SILICON from target CPU.
Derive MVK_MACOS_APPLE_SILICON from target CPU and macOS platform.
Derive MVK_XCODE_12 from macOS and iOS SDK versions.
Test for simulator on non-Apple GPU using MVK_OS_SIMULATOR && !MVK_APPLE_SILICON.
MTLDevice retains an internal object web that is used during the creation of
new objects, such as pipeline states, libraries, functions, and samplers.
Simultaneously creating and destroying objects of these types can trigger
race conditions on the internal MTLDevice content.
Wrap the following in @synchronized (mtlDevice) {...}:
- MTLRenderPipelineState creation and destruction
- MTLComputePipelineState creation and destruction
- MTLLibrary creation
- MTLFunction creation and specialization
- MTLSampler creation and destruction
MVKCommandEncoderState has numerous subclasses, and the polymorphic
MVKCommandEncoderState::resetImpl() requires significant maintenance
across these subclasses. It's only use was in disabling depth-stencil state.
Remove MVKCommandEncoderState::reset() and all implementations of resetImpl()
across all MVKCommandEncoderState subclasses.
Remove MVKPipeline::__hasDepthStencilInfo and disable depth-stencil state
automatically via cleared Vulkan struct in MVKPipeline.
Don't reset MVKOcclusionQueryCommandEncoderState::_mtlVisibilityResultOffset
when ending occlusion query, as subsequent queries need different offsets.
Also, remove MVKOcclusionQueryCommandEncoderState::_needsVisibilityResultMTLBuffer,
as it is always set once from MVKCommandBuffer::_needsVisibilityResultMTLBuffer.
When app setting MVKConfiguration it with a partial copy, start with existing.
It is possible for the maximum buffer size to be 4 binary gigabytes or
greater. In that case, the upper 32 bits will be lost, and the value of
the `maxUniformBufferRange` and `maxStorageBufferRange` limits would be
too small or even zero. Clamp it to 4 GiB - 1 in that case, since that
is the maximum value of a 32-bit integer.
For #1240.
Refactor auto GPU capture code to support both device and frame capture.
Add ability to automatically capture first GPU frame by setting
`MVK_CONFIG_AUTO_GPU_CAPTURE_SCOPE` to `2`.
Wrap GPU capture in autorelease pool to handle both cases of capture call
being made in run loop as in an app GUI, or in one-shot app like CTS.
They are not expected to be useful beyond the commands that use them,
but they take up memory nonetheless. This is exactly the use case
purgeability was designed for. Tell the system that it's OK to reclaim
their memory if necessary.
Doing this every time the buffer is used will cause the purgeable state
to be reset from `MTLPurgeableStateEmpty`, in case the system really did
reclaim their memory.
In accordance with Apple's advice, lock the pages for the buffer when
loading it, so the memory isn't pulled out from under us.
Add support for "dedicated" temp buffers, where instead of allocating a
big buffer and carving regions out of it, a unique buffer is returned
for each allocation request. This is necessary for visibility buffers,
because the offset passed to `-[MTLRenderCommandEncoder
setVisibilityResultMode:offset:]` cannot exceed an
implementation-defined value, currently 256k less 8 bytes for Mac family
2 on Catalina and up, and on Apple family 7; and 64k less 8 bytes
otherwise.
According to the Metal Feature Set Tables, only family 2 supports
quad-scope permutation. We've been seeing issues with SIMD-group
functions on family 1 hardware, so for now I'm moving quad-group
permutation to family 2.
Instead of having Metal directly write to the query pool's internal
storage, we'll have it write to a temp buffer whose lifetime is tied to
the command buffer. The temp buffer's contents are then accumulated to
all queries that were activated.
This last step is particularly important for queries that span multiple
render passes. Since Metal resets the query counter at a render pass
boundary, this means that, up until now, only the last draw counted
toward the query. Data from the others were lost. By using this temp
buffer and accumulating the results to the query storage, the counter
will correctly count draws from all render passes inside the query
bounds.
This will also fix problems using multiple query pools, particularly
with large query pool support on, in a single render pass. Because Metal
requires us to set the visibility results buffer at render pass start
time, we couldn't use multiple query pools inside a single render pass.
Using a single temp buffer bypasses this problem.
Also, don't make queries available to the host unless they became
available to the device first. That way, a query that is immediately
reset during command buffer execution will properly report that the
query is unavailable. This fixes the remaining dEQP-VK.query_pool.*
tests. Fix some bugs that shook out of this.
Add SPIRVToMSLConversionResults::isPositionInvariant to query
position invariance from SPIR-V.
MVKDevice::getMTLCompileOptions() takes into consideration need to preserve invariance.
MVKShaderModule compile MSL to preserve invariance if required by shader.
Support querying SignedZeroInfNanPreserve execution mode
from SPIR-V to disable fast-math for individual shaders.
Clean up namespace references in SPIRVToMSLConverter.cpp.
MVKConfiguration access is now global, and the VkInstance provided in the
vkGet/Set/MoltenVKConfigurationMVK() functions is ignored. This allows these
functions to be provided with a VkInstance object that originates from a
different Vulkan layer than MoltenVK, without risking breaking the API.
MVKConfiguration extended to cover all MoltenVK environment variables.
Move all environment variable declarations to MVKEnvironment.h.
Add MVKEnvironment.cpp to define config functions.
Cleanup .m files to use MVKCommonEnvironment.h instead of MVKEnvironment.h.
