So, is it safe to assume that raytracing pipelines and some other advanced features (like buffer pointers) that are present in Metal will not be available in MoltenVK for foreseeable future?

Afraid not. The problem is that Metal doesn't support writing raw GPU VAs to a buffer, then loading them in a shader, so we can't support VK_KHR_buffer_device_address; and because the ray tracing extensions need BDAs, we can't yet support ray tracing, either.

Thank you for this.

So, is it safe to assume that raytracing pipelines and some other advanced features (like buffer pointers) that are present in Metal will not be available in MoltenVK for foreseeable future?

That's because nobody has submitted anything to the Vulkan HW DB for it yet. It needs to be run on a Mac with an M1 chip; AFAIK, at least one enterprising dev is working on reverse engineering the M1 GPU so a Linux driver can be produced for it, but that's still in the early stages.

Here is a list of all known Vulkan features that MoltenVK supports on the M1:

• 1.0 Core
  • robustBufferAccess (not really)
  • fullDrawIndexUint32
  • imageCubeArray
  • independentBlend
  • tessellationShader
  • sampleRateShading
  • dualSrcBlend
  • multiDrawIndirect
  • drawIndirectFirstInstance
  • depthClamp
  • depthBiasClamp
  • fillModeNonSolid (n.b. points mode is unsupported)
  • largePoints
  • alphaToOne
  • multiViewport
  • samplerAnisotropy
  • textureCompressionETC2
  • textureCompressionASTC_LDR
  • textureCompressionBC (yes, all of them)
  • occlusionQueryPrecise
  • fragmentStoresAndAtomics
  • shaderImageGatherExtended (n.b. ConstOffsets doesn't work)
  • shaderStorageImageExtendedFormats
  • shaderStorageImageReadWithoutFormat
  • shaderStorageImageWriteWithoutFormat
  • shaderUniformBufferArrayDynamicIndexing
  • shaderSampledImageArrayDynamicIndexing
  • shaderStorageBufferArrayDynamicIndexing
  • shaderClipDistance
  • shaderInt16
  • shaderResourceMinLod
  • inheritedQueries
• VK_KHR_16bit_storage (1.1 Core)
  • storageBuffer16BitAccess
  • uniformAndStorageBuffer16BitAccess
  • storagePushConstant16
  • storageInputOutput16
• VK_KHR_8bit_storage (1.2 Core)
  • storageBuffer8BitAccess
  • uniformAndStorageBuffer8BitAccess
  • storagePushConstant8
• VK_KHR_float16_int8 (1.2 Core)
  • shaderFloat16
  • shaderInt8
• VK_KHR_multiview (1.1 Core)
  • multiview
• VK_KHR_portability_subset
  • constantAlphaColorBlendFactor
  • events
  • imageViewFormatReinterpretation
  • imageViewFormatSwizzle
  • multisampleArrayImage
  • mutableComparisonSamplers
  • separateStencilMaskRef
  • shaderSampleRateInterpolation (n.b. The functions actually worked at one point, but they seem to be broken now.)
  • vertexAttributeAcccessBeyondStride
• VK_KHR_sampler_ycbcr_conversion (1.1 Core)
  • samplerYcbcrConversion
• VK_KHR_shader_draw_parameters (1.1 Core)
  • shaderDrawParaameters
• VK_KHR_shader_subgroup_extended_types (1.2 Core)
  • shaderSubgroupExtendedTypes
• VK_KHR_timeline_semaphore (1.2 Core)
  • timelineSemaphore
• VK_KHR_uniform_buffer_standard_layout (1.2 Core)
  • uniformBufferStandardLayout
• VK_KHR_variable_pointers (1.1 Core)
  • variablePointersStorageBuffer
  • variablePointers
• VK_EXT_fragment_shader_interlock
  • fragmentShaderSampleInterlock
  • fragmentShaderPixelInterlock
• VK_EXT_host_query_reset (1.2 Core)
  • hostQueryReset
• VK_EXT_image_robustness
  • robustImageAccess
• VK_EXT_inline_uniform_block
  • inlineUniformBlock
• VK_EXT_private_data
  • privateData
• VK_EXT_robustness2
  • robustImageAccess2
• VK_EXT_scalar_block_layout (1.2 Core)
  • scalarBlockLayout
• VK_EXT_subgroup_size_control
  • subgroupSizeControl (n.b. the subgroup size cannot actually be set; this just confirms support for variable subgroup sizes)
  • computeFullSubgroups
• VK_EXT_texel_buffer_alignment
  • texelBufferAlignment
• VK_EXT_texture_compression_astc_hdr
  • textureCompressionASTC_HDR
• VK_EXT_vertex_attribute_divisor
  • vertexAttributeInstanceRateDivisor
  • vertexAttributeInstanceRateZeroDivisor (n.b. indirect draws with non-zero base instances don't work correctly with this; I'm considering turning this off for that reason)
• VK_EXT_shader_integer_functions2_INTEL
  • shaderIntegerFunctions2

We also advertise VK_EXT_descriptor_indexing, but until argument buffer support is merged, we'll be out of spec, since the 500k minimum required by that extension needs argument buffers on Metal. But once that's merged, we should be able to support that fully.

What Vulkan features are supported by M1?

vulkan.gpuinfo.org doesn't list M1.

Can you add support for the VK_KHR_shader_non_semantic_info extension? This will also require support for the SPV_KHR_non_semantic_info extension as well. The shader based debug printf validation tests requires these extensions, and technically without them the behavior of debug printf is undefined.

This PR contains a few code-clean-up updates that should not affect behavior.

• MVKSmallVector allow constructor to size with default values.
• Remove obsolete MVKVector, which was long ago replaced with MVKSmallVector.
• Remove unnecessary concrete implementations of template functions that are used only within a single compilation unit.
• Add strings for all current VkResult values.
• Make logging functions globally accessible to ease their use in debugging activities.
• Add and use MVK_APPLE_SILICON macro definition.
• Remove a few unused member variables.

• [ ] rust-analyzer: Chokes on type with nested impl Traits

• [x] rapierfix cargo test -p rapier3d

This PR adds a #[gpu_only] macro to spirv-std-macros, which essentially expands to the following. Which we were doing a lot in the code already, and will only add more in the future.

fn foo() {
     #[cfg(target_arch = "spriv")] {
        // SPIR-V fn body.
     }
     
     #[cfg(not(target_arch = "spriv"))] {
         unimplemented!()
     }
}

Great. Thanks for the education, and for your work on setting Actions up!

For future reference, you'll want to make sure that the GitHub Actions virtual environment image has been updated to include a new version of Xcode.

@billhollings: At the moment, the macos-latest image maps to macos-10.15, and that image's list of available Xcode versions (and paths) can be found here: https://github.com/actions/virtual-environments/blob/main/images/macos/macos-10.15-Readme.md#xcode

At some point macos-latest will map to macos-11.0 (the macos-11.0 image is currently in preview, and has more limited capacity available).

@cdavis5e Specifically wanted another pair of eyes on use of MVK_APPLE_SILICON.

This PR contains a few code-clean-up updates that should not affect behavior.

• MVKSmallVector allow constructor to size with default values.
• Remove obsolete MVKVector, which was long ago replaced with MVKSmallVector.
• Remove unnecessary concrete implementations of template functions that are used only within a single compilation unit.
• Add strings for all current VkResult values.
• Make logging functions globally accessible to ease their use in debugging activities.
• Add and use MVK_APPLE_SILICON macro definition.
• Remove a few unused member variables.