Add a new extension: VK_EXT_map_memory_placed

[gfxstrand]

This extension adds support for requesting that a VkDeviceMemory object be mapped at a particular location in the client's address space. This is similar to the addr parameter to the mmap() ioctl. In order for this to succeed, the client may have to first reserve the address range via a platform-specific mechanism.

Fixes: #1832

External links

• Intel Linux implementation
• Crucible test

[Tobski]

@jekstrand can you add a proposal document for this extension?

[oddhack]

Will be handled internally by the Development call - assigning to Tom as a placeholder for that.

[gfxstrand]

I've updated the PR as well as all the driver/test branches with the following changes:

• It's now all based on a new VK_EXT_memory_map2
• VK_EXT_map_memory_placed now has a proposal doc as per @Tobski
• There is now a VK_MEMORY_UNMAP_RESERVE_BIT_EXT which cuases the driver to mmap(MAP_ANONYMOUS | MAP_PRIVATE) over the memory region instead of munmap(). This should give the re-reserve behavior the Wine folks want.
• My UNMAP_RESERVE test found some bugs in the ANV implementation which are now fixed.

[gfxstrand]

cc @Guy1524 @DadSchoorse

[Tobski]

Ok I feel like you'll anticipate what I'm going to say here but, can you write a proposal doc for map memory 2 as well please 😅

It seems like a straightforward extension, but it's not clear why we need it without the motivation written down.

I suppose you could also combine the two extensions with a single proposal document if you'd prefer, but that might be more work.

[gfxstrand]

While dealing with the comments from Tobias, I realized I didn't specify interactions with host pointer import. I've added a couple VUs saying that you can't do a placed maps or unmap with reserve on something imported from a host pointer import.

[Tobski]

Ok this is my most thorough review yet, so I'm fairly sure once all of this is addressed you can finally have my approval :P

[gfxstrand]

Now that VK_KHR_map_memory2 is ratified and released, I've rebased this branch and fixed up a bunch of stuff. The ANV branch has also been updated.

[cubanismo]

Still says WIP, but this LGTM.

[gfxstrand]

Still says WIP, but this LGTM.

Dropped the WIP. We're currently waiting on someone to write some CTS tests. I put together a test plan but have yet to find someone to write the actual tests.

[pdaniell-nv]

There is an initial implementation of this extension in our NVIDIA Vulkan Beta drivers here: https://developer.nvidia.com/vulkan-driver

[gfxstrand]

@oddhack, I just rebased the branch today and we agreed on the working group call to skip some of the usual process and go ahead and ship this. Do you want to merge it from here or would you like me to create an internal MR and merge it that way?

Also, this is pretty short notice so it's okay if we miss this week's spec update.

[gfxstrand]

And... we now have an NVK implementation: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27599

[gfxstrand]

@oddhack To be clear, this is good to ship as soon as you're ready. There's no need to delay until next week. I just didn't want to throw a wrench in your process if you already had other extensions queued up to go in.

[TheComputerGuy96]

And... we now have an NVK implementation: https://gitlab.freedesktop.org/mesa/crucible/-/merge_requests/147

@gfxstrand This is the actual NVK implementation: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27599 (the link you posted is just some non-Vulkan CTS tests for the extension)

[gfxstrand]

Did I do that here, too? It's been a day... 😂

[oddhack]

@oddhack To be clear, this is good to ship as soon as you're ready. There's no need to delay until next week. I just didn't want to throw a wrench in your process if you already had other extensions queued up to go in.

It's fine to merge from here, though I'm glad you're bringing it up early as it's easier to handle the github PRs first and then the internal ones. Should respond to @Tobski's suggestion but I'll sign this off and it will go out this week.

[gfxstrand]

I've dealt with the comments from @Tobski and @spencer-lunarg. I also fixed a dependency warning.

[gfxstrand]

Unfortunately, my fix for the dependency warning caused a new CI issue. It's complaining that I put the requires for VkMemoryUnmapFlagBitsKHR in VK_EXT_memory_map_placed which uses an EXT suffix. However, this is consistent with other cases where we add an unused flags field in an extension or core version and then a different extension is the first to add actual flags. How would you like to resolve this?

I've moved it back to VK_KHR_map_memory2

[oddhack]

Unfortunately, my fix for the dependency warning caused a new CI issue. It's complaining that I put the requires for VkMemoryUnmapFlagBitsKHR in VK_EXT_memory_map_placed which uses an EXT suffix. However, this is consistent with other cases where we add an unused flags field in an extension or core version and then a different extension is the first to add actual flags. How would you like to resolve this?

I've moved it back to VK_KHR_map_memory2

It looks like you squashed away the offending commit? If you happen to recall the diff I'd like to take a look at it for future extensions but it appears this is working OK now.

[oddhack]

@gfxstrand this is saying something about @Tobski requested changes though I can't figure out what was requested that you haven't already addressed. Maybe git is confused? Also there's the suggestion from @DadSchoorse above. So I will hold off on merging until tomorrow and we can check back on the call.

[Tobski]

@gfxstrand this is saying something about @Tobski requested changes though I can't figure out what was requested that you haven't already addressed. Maybe git is confused? Also there's the suggestion from @DadSchoorse above. So I will hold off on merging until tomorrow and we can check back on the call.

I'm pretty sure I just asked for a proposal, which has now been done. Will review again and clear this up!

[Tobski]

A couple of nitpicky editorial things that I'd like to see fixed but it's nothing I feel needs to be resolved before merging.

[Tobski]

We've generally been dropping them from the appendix rather than the proposal - reason being the questions usually come up when you read the proposal, not the appendix. Suggest dropping them here? Not going to gate merging on this but it is weird to have them duped...