VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLTEXTURE_BIT_KHR not defined

[martinweber]

Hi,

TLDR;

• using VkExternalMemoryImageCreateInfo.handleTypes = 0 results in an MoltenVK error and terminates the process
• VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLBUFFER_BIT_KHR and VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLBUFFER_BIT_KHR are needed to use VK_EXT_metal_objects but are not defined in the specification

I am using VK_EXT_metal_objects to create a Vulkan Image from a Metal Image.

To do that, I put a VkImportMetalTextureInfoEXT into pNext of VkImageCreateInfo. To prevent the Vulkan validation layer to complain about unbound memory, I put a VkExternalMemoryImageCreateInfo into pNext of VkImportMetalTextureInfoEXT. Initially I set its handleTypes flag to 0 as none of the available flags makes sense.

A handleTypes flag of 0 results in this error from MoltenVK though (and the process terminates):

[mvk-error] VK_ERROR_FEATURE_NOT_PRESENT: vkCreateImage(): Only external memory handle type VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLTEXTURE_BIT_KHR is supported.

As this flag is not available from the Vulkan SDK I went and searched for it. It seems it only has a placeholder in MKVDeviceMemory.h until VK_KHR_external_memory_metal defines it.

As a workaround I tried to use the placeholder definition in my code. This eliminates the error in MoltenVK and my application no longer gets terminated. Now the Vulkan validation layer is complaining though as the placeholder definition enables all flags. Effectively this trades the unbound memory validation error for this one.

I was wondering - as the flags VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLBUFFER_BIT_KHR and VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLBUFFER_BIT_KHR are tied to the usage of VK_EXT_metal_objects - shouldn't they be part of VK_EXT_metal_objects?

As for now, I need to either ignore the Vulkan validation error about unbound memory or the wrong flag value in handleTypes in VkExternalMemoryImageCreateInfo.

Would it be possible to accept a handleTypes flag of 0 in MVKImage::initExternalMemory as valid in the meanwhile (i.e. not terminate the process), as the VkExternalMemoryImageCreateInfo specification says "handleTypes is zero or a bitmask of VkExternalMemoryHandleTypeFlagBits"?

Thanks! -Martin

[kocdemir]

Hi @billhollings , is there a Khronos side tracker for this? I wonder if it's only about moving the internally defined flags into the spec (maybe by modifying VK_EXT_metal_objects for VkExternalMemoryHandleTypeFlagBits) or is there some other changes needed on the MoltenVK side?

Thanks

[billhollings]

I was wondering - as the flags VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLBUFFER_BIT_KHR and VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLBUFFER_BIT_KHR are tied to the usage of VK_EXT_metal_objects - shouldn't they be part of VK_EXT_metal_objects?

and

Hi @billhollings , is there a Khronos side tracker for this? I wonder if it's only about moving the internally defined flags into the spec (maybe by modifying VK_EXT_metal_objects for VkExternalMemoryHandleTypeFlagBits) or is there some other changes needed on the MoltenVK side?

Thanks

Yes. That should have been included in the original VK_EXT_metal_objects specification, but unfortunately wasn't.

Pushing through a Vulkan spec revision is just a matter of priorities here, and will happen sometime.

In the meantime, since both VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLBUFFER_BIT_KHR and VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLTEXTURE_BIT_KHR are internally mapped to VK_EXTERNAL_MEMORY_HANDLE_TYPE_FLAG_BITS_MAX_ENUM, you can pass VK_EXTERNAL_MEMORY_HANDLE_TYPE_FLAG_BITS_MAX_ENUM for either instead. This may trigger a Vulkan Validation Layer error, which will have to be ignored.