Draft: Add a VK_MESA_legacy_dma_buf_drm_format_modifier_query extension

[gfxstrand]

This extension provides a way to query a legacy Linux dma-buf for its embedded modifier. This is needed by emulation layers which implement OpenGL on top of Vulkan and need to interact with legacy window-system components as the X server. This extension is not intended for general-purpose use and modifiers should be passed explicitly between applications or components whenever possible.

[gfxstrand]

Both sides of the Mesa implementation are here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33932

[cubanismo]

There's an internal MR with an alternative solution for this. We should probably reconcile the two rather than have two separate solutions.

[gfxstrand]

There's an internal MR with an alternative solution for this. We should probably reconcile the two rather than have two separate solutions.

A quick search isn't finding it. Can you throw me a # or tag me on the internal one?

[gfxstrand]

I looked it up. That's a very different extension for solving a very different problem. Mechanically, the implementation of the two may end up being similar on some implementations but they're not the same at all. This extension exists to solve a problem you really only hit if you're either using Vulkan to write an X11 compositor or are somehow inside the X server itself (such as when Zink is used by the modesetting driver) and need to composite buffers coming from Mesa GL drivers.

[orowith2os]

are somehow inside the X server itself (such as when Zink is used by the modesetting driver) and need to composite buffers coming from Mesa GL drivers.

This is the case inside of Flatpak, where you may be using nouveau GL or a CPU renderer, or perhaps some other GL driver (in the case of a multi-gpu system).

Systems with several GPUs/drivers, especially mixed with containers, are funky :)

[cubanismo]

I believe comments were made in a Vulkan System Integration TSG meeting to the effect that this extension proposal was no longer being pursued due to alternative solutions being proposed/agreed on. @gfxstrand, is that the case, or am I misremembering? If true, could this be closed? If not, I'll try to get it some additional review personally and better visibility in an upcoming TSG meeting.

[CLAassistant]

All committers have signed the CLA.

[gfxstrand]

We've actually started to see users hitting this case in the wild since switching nouveau to NVK+Zink. We may be re-evaluating whether or not this is necessary. I think for now it's okay to proceed with additional review. I'm also happy to ram it through as a vendor extension if we need to as it really isn't going to affect anyone outside the Linux desktop ecosystem.

[oddhack]

Heads-up: we have made a formatting change to vk.xml to crunch out whitespace in XML attribute lists, which will probably affect you the next time you sync this branch with current main branch. When you do this, try following the process in https://github.com/KhronosGroup/Vulkan-Docs/wiki/Merge-XML-Whitespace, which should prevent the need for any tedious conflict resolution consequent to the whitespace change.