Add VK_EXT_external_memory_metal

[aitor-lunarg]

No description provided.

[oddhack]

@aitor-lunarg process-wise, we require that extension number and flag bits be reserved by a commit to main prior to the extension development branch actually being able to use them. I don't know where this extension stands deployment / release-wise, but we need to separate out the reservations and accept those first, to avoid a race condition (see extension 597 for a guide to what that PR would look like).

[aitor-lunarg]

Before moving forward with this extension, there's one concern that we need to address. Metal does not provide all Vulkan formats, so there are times where an implementation will emulate some of them. Why is this an issue:

Implementations may decide to emulate those formats with an internal representation such that those formats are backed by multiple textures. Taking MoltenVK as an example implementation with VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM. This format is backed by 3 textures (one for each plane), so it is not possible to export all of the backing textures through a single handle unfortunately as of now.

There are 3 potential solutions that come to mind to fix this issue as we stand:

1. Force implementation to have those multi-planar emulated implementations in a single texture if they want to export it. Unsure if there could be issues with precision when sampling that would prevent this approach.
2. Modify the API for this extension to allow exporting more than one single handle for these cases. This would lead to a query call first to understand how many handles the user will get, and then get the handles. However, this is quite counter intuitive since we imply that a VkDeviceMemory object may not be a single handle. When importing we would also need to provide all handles as the implementation expects them. I don't really like this approach.
3. Modify the handle to MTLHeap and force implementations to have all resources stored in those objects if they want to export them. Again, this also has issues since not all Apple hardware may support MTLHeap and there are a few known restrictions that make it ugly for non-Apple silicon GPUs.

@linyaa-kiwi would it be possible to bring this up for discussion this coming SI meeting? I would like to understand if other similar extensions have run into similar issues and how they've tackled them if so. Or just get general feedback/ideas about this issue.

cc/ @kocdemir

[linyaa-kiwi]

@linyaa-kiwi would it be possible to bring this up for discussion this coming SI meeting? I would like to understand if other similar extensions have run into similar issues and how they've tackled them if so. Or just get general feedback/ideas about this issue.

@aitor-lunarg Would you like to discuss in today's SI meeting? If not, what week works best for you?

[aitor-lunarg]

Seems like GitHub is having some issues, would it be possible to retrigger the failed checks (failed due to a 500 error when trying to clone required repos)? Nvm, I saw I can do that myself

[linyaa-kiwi]

I found some more points for improvement today.

[linyaa-kiwi]

Thanks. I'll give it another review today.

[linyaa-kiwi]

Thanks for the fixes! LGTM and I approve for merge.

[aitor-lunarg]

Rebased to get Vulkan 1.4 so things don't explode when I propagate to VVL and CTS for release

[oddhack]

@linyaa-kiwi @aitor-lunarg on the maintenance call, we were unsure about where this sits for release - do we want to ratify it first? Please loop in @r-potter but I'm expecting this will not go out this week, at least.