Vulkan 1.3 requirements

[billhollings]

Appendix D of the Vulkan spec and the VK_VERSION_1_3 man page summarize the extension list below, and adds additional Vulkan 1.3 enhancement requirements.

Extension	MoltenVK Support	Status Notes
VK_KHR_copy_commands2	✅
VK_KHR_dynamic_rendering	✅
VK_KHR_format_feature_flags2	✅	Added (#2108)
VK_KHR_maintenance4	✅	Added (#2484)
VK_KHR_shader_integer_dot_product	✅	Added (#2119)
VK_KHR_shader_non_semantic_info	✅
VK_KHR_shader_terminate_invocation	✅	Added ( #2424)
VK_KHR_synchronization2	✅	Added (#2021)
VK_KHR_zero_initialize_workgroup_memory	✅	Added (#2450)
VK_EXT_4444_formats	✅
VK_EXT_extended_dynamic_state	✅	Added (#2036)
VK_EXT_extended_dynamic_state2	✅	Added (#2036)
VK_EXT_image_robustness	✅
VK_EXT_inline_uniform_block	✅
VK_EXT_pipeline_creation_cache_control	✅
VK_EXT_pipeline_creation_feedback	✅
VK_EXT_private_data	✅
VK_EXT_shader_demote_to_helper_invocation	✅
VK_EXT_subgroup_size_control	✅
VK_EXT_texel_buffer_alignment	✅
VK_EXT_texture_compression_astc_hdr	✅
VK_EXT_tooling_info	✅	Added (#2435)
VK_EXT_ycbcr_2plane_444_formats		Not required for 1.3 (see spec re promotion of this extension)

---

In addition to the promoted extensions described above, Vulkan 1.3 added required support for:

• SPIR-V version 1.6
  • SPIR-V 1.6 deprecates (but does not remove) the WorkgroupSize decoration.
• The bufferDeviceAddress feature which indicates support for accessing memory in shaders as storage buffers via vkGetBufferDeviceAddress.
• The vulkanMemoryModel and vulkanMemoryModelDeviceScope features, which indicate support for the corresponding Vulkan Memory Model capabilities.
• The maxInlineUniformTotalSize limit is added to provide the total size of all inline uniform block bindings in a pipeline layout.

Additional details of functionality and information that may need to be included in a 1.3 implementation can be found here.

[CarterLi]

Ref: haasn/libplacebo#174

[rcaridade145]

In regards to VK_KHR_shader_integer_dot_product

I came across

gpuweb/gpuweb#2677

Which led to me.

-https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/compiler/nir/nir_opcodes.py#L1367

Hopefully this can be useful.

[cdavis5e]

In regards to VK_KHR_shader_integer_dot_product

I came across

gpuweb/gpuweb#2677

Which led to me.

-https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/compiler/nir/nir_opcodes.py#L1367

Hopefully this can be useful.

That bit of code you highlighted is for a packed saturating vertical add. That's only part of three of the new instructions added by that extension. Metal already has that (as addsat()). For a dot product, we need a vertical multiply followed by a horizontal add (i.e. add all elements of the product vector together). AFAIK, Metal doesn't have either an overload of dot() that accepts integral input or any sort of horizontal add. We'd have to expand the final addition manually, which would be painful.

[billhollings]

We'd have to expand the final addition manually, which would be painful.

By that, you mean adding the required synthetic functions to SPIRV-Cross?

[cdavis5e]

We'd have to expand the final addition manually, which would be painful.

By that, you mean adding the required synthetic functions to SPIRV-Cross?

Yes.

[rcaridade145]

gfx-rs/naga#1689 People of webgpu seem to have dealt with dot product with integers on Metal.

[rcaridade145]

Been studying spirv-cross code and other alternatives like naga and tint (really nice code) .

Tint - https://dawn.googlesource.com/tint/+/refs/heads/main/src/tint/writer/msl/generator_impl.cc#681

It should be implemented something like that (to support some integer dot) here no?

https://github.com/KhronosGroup/SPIRV-Cross/blob/main/spirv_msl.cpp#L5414

[devshgraphicsprogramming]

btw vulkanMemoryModel starts to be quite important when SPV_KHR_physical_storage_buffer gets used because you start needing to use it on OpLoad and OpStore if you want Buffer Device Addresses to volatile/coherent variables

[AndrewTriesToCode]

Hi, just want to confirm that until this is supported only 1.x DXVK releases are compatible with MoltenVK. Do I understand that right?

Thanks yall are awesome.

[cdavis5e]

Hi, just want to confirm that until this is supported only 1.x DXVK releases are compatible with MoltenVK. Do I understand that right?

Yes, that is correct. Hopefully, you won't have to wait much longer...

[ForestCSharp]

Should I be able to use dynamic rendering without the Ext function pointers?
I'm currently getting a segfault calling vkCmdBeginRendering/vkCmdBeginRendering, though I can access the same functionality via
pfn_begin_rendering = (PFN_vkCmdBeginRenderingKHR)vkGetDeviceProcAddr(device, "vkCmdBeginRenderingKHR"); pfn_begin_rendering(vk_command_buffer, &vk_rendering_info);
but would prefer to have one codepath for Windows + Mac using the 1.3 functions

[spnda]

Should I be able to use dynamic rendering without the Ext function pointers?

No. That's invalid usage of Vulkan, as 1.3 is not advertised.

Your problem is easily avoidable anyway, just use an if to switch between loading the core function and the extension function, based on the physical device API version. The functions have the same signature, and the structures didn't change from the promotion, so its all backwards compatible.

[spnda]

I just by accident found another extension which was made core with Vulkan 1.3, but was not listed in the Appendix you linked in the original post.

VK_ATTACHMENT_STORE_OP_NONE was added with 1.3, meaning VK_EXT_load_store_op_none was partially made core. The spec says this:

VK_ATTACHMENT_STORE_OP_NONE specifies the contents within the render area are not accessed by the store operation as long as no values are written to the attachment during the render pass. If values are written during the render pass, this behaves identically to VK_ATTACHMENT_STORE_OP_DONT_CARE and with matching access semantics.

Seems like this could just be emulated with MTLStoreActionDontCare. I'll look into a quick implementation of that op and the two extensions providing it. But it should probably still be listed in the original post.

Also, perhaps we missed some other things found here that need to be supported.

[billhollings]

VK_ATTACHMENT_STORE_OP_NONE was added with 1.3, meaning VK_EXT_load_store_op_none was partially made core.

Actually, this was also added via VK_KHR_dynamic_rendering, which is why it also ended up in 1.3.

Since MoltenVK already supports VK_KHR_dynamic_rendering, it should also support VK_ATTACHMENT_STORE_OP_NONE, which it doesn't deliberately, but since it defaults to STORE, it does successfully use it.

Seems like this could just be emulated with MTLStoreActionDontCare.

Hmmm...as part of the description above, the spec also includes:

VK_ATTACHMENT_STORE_OP_DONT_CARE can cause contents generated during previous render passes to be discarded before reaching memory, even if no write to the attachment occurs during the current render pass.

With this in mind, my interpretation of the difference between VK_ATTACHMENT_STORE_OP_NONE and VK_ATTACHMENT_STORE_OP_DONT_CARE, is that NONE indicates that the attachment is not written to in this render pass, so it doesn't need to be stored, but it needs to be retained for further render passes.

And I read the "If values are written..." part to mean, "If you write when you said you wouldn't, we're not going to save the changes, and you've messed it up already, so we're not going to bother retaining it".

With all that in mind, I think MTLStoreActionStore would be appropriate, since we want to ensure the content is not discarded. MoltenVK does this in mvkMTLStoreActionFromVkAttachmentStoreOpInObj() through the default, but we should fix MoltenVK to do this officially, to avoid the error message, particularly since VK_KHR_dynamic_rendering is supported now.

Also, perhaps we missed some other things found here that need to be supported.

Good catch. I've added this to the main section above.

[squidbus]

Just want to note that VK_EXT_ycbcr_2plane_444_formats is not required, the formats can be added as unsupported for Vulkan 1.3 as long as the extension remains unadvertised.

[billhollings]

Just want to note that VK_EXT_ycbcr_2plane_444_formats is not required, the formats can be added as unsupported for Vulkan 1.3 as long as the extension remains unadvertised.

Thanks! Nice catch!

[dboyan]

I'm working on VK_KHR_zero_initialize_workgroup_memory. The SPIRV-Cross side work is at KhronosGroup/SPIRV-Cross#2444. Once that is merged, we can enable it pretty easily.

Note that full CTS compliance related to the extension requires the bugfix as in #2434 (an independent specialization constant issue unrelated to the extension itself). The proper fix also requires a small API addition on SPIRV-Cross side to give us the required knowledge. I'll try to have an updated version for upstream ready in a few days.

[devshgraphicsprogramming]

Is there any fundamental difficulty with implementing VK_KHR_shader_terminate_invocation btw? Nobody talked about it so far.

[dboyan]

VK_KHR_shader_terminate_invocation

It's just added in #2424

[billhollings]

@dboyan

I'm working on VK_KHR_zero_initialize_workgroup_memory [clip] we can enable it pretty easily.

Looking forward to it! Thanks for your work!

I couldn't review the commit you linked inline, but when you submit a PR:

• Be sure to add ZeroInitializeWorkgroupMemory to MVKDeviceFeatureStructs.def (in the same relative location in the list as in MVKPhysicalDevice::getFeatures()).

• Is there a reason for the additional #include "vulkan/vulkan_core.h"? That header is already covered through mvk_vulkan.h.

[dboyan]

Thanks for the comments! Just created the pull request (#2450) with those addressed. I was waiting for #2441 to land, because there would be conflicts otherwise and it is needed for passing CTS cases.

[IsaacMarovitz]

Since Vulkan 1.3 seems fairly imminent, I figured I'd summarise what will be needed for Vulkan 1.4 (will need a separate issue at some point, of course).

Extension	MoltenVK Support	Status Notes
VK_KHR_dynamic_rendering_local_read (Optional)
VK_KHR_global_priority
VK_KHR_index_type_uint8
VK_KHR_line_rasterization
VK_KHR_load_store_op_none
VK_KHR_maintenance5
VK_KHR_maintenance6
VK_KHR_map_memory2	✅
VK_KHR_push_descriptor	✅
VK_KHR_shader_expect_assume
VK_KHR_shader_float_controls2
VK_KHR_shader_subgroup_rotate
VK_KHR_vertex_attribute_divisor	✅
VK_EXT_host_image_copy (Optional)	✅
VK_EXT_pipeline_protected_access (Optional)
VK_EXT_pipeline_robustness

[devshgraphicsprogramming]

Since Vulkan 1.3 seems fairly imminent, I figured I'd summarise what will be needed for Vulkan 1.4 (will need a separate issue at some point, of course).
Extension MoltenVK Support Status Notes
VK_KHR_dynamic_rendering_local_read
VK_KHR_global_priority
VK_KHR_index_type_uint8
VK_KHR_line_rasterization
VK_KHR_load_store_op_none
VK_KHR_maintenance5
VK_KHR_maintenance6
VK_KHR_map_memory2 ✅
VK_KHR_push_descriptor ✅
VK_KHR_shader_expect_assume
VK_KHR_shader_float_controls2
VK_KHR_shader_subgroup_rotate
VK_KHR_vertex_attribute_divisor ✅
VK_EXT_host_image_copy ✅
VK_EXT_pipeline_protected_access
VK_EXT_pipeline_robustness

Maybe add a column if its really a thing that needs to be supported, or an extension that promoted to core but is still an optional feature

[QuantumDeveloper]

does shader object extension is currently supported?

[K0bin]

@QuantumDeveloper That's not really possible to support because Metal uses proper pipelines everywhere.

[tareksander]

Isn't VK_KHR_maintenance4 optional too? There is a feature flag for the extension and in the 1.3 feature flags, and nothing in the spec says a Vulkan 1.3 implementation has to support that flag.

[squidbus]

Going by KhronosGroup/Vulkan-Docs#1747, it seems that most promoted extension features (which would include maintenance4) are promoted as required unless stated otherwise, same as they are required in the original extension.

[tareksander]

Ok, I found the relevant part of the spec. Quite confusing that it isn't listed with the struct definition itself, suggesting all features are optional.

[billhollings]

PR #2489 competes this issue.

[AndrewTriesToCode]

Congrats!