[Mesa-dev] Update: Vulkan modifiers extension VK_EXT_image_drm_format_modifier

[Chad Versace]

As many of you know, I've been writing a Vulkan extension for DRM format
modifiers, named VK_EXT_image_drm_format_modifier.

The extension is very close to completion. I've submitted a branch to
Khronos for review. It's receiving active review inside Khronos from
some non-Mesa closed-source window-system-integration people, and Mesa
people too (namely jekstrand).

You should take a look at the spec if you care about modifiers and Vulkan.
I try to keep up-to-date urls to everything related to this extension at
<http://kiwitree.net/~chadv/vulkan/#1.0-VK_EXT_image_drm_format_modifier>.

There remain only two unresolved issues from my perspective:

    - The exact definition of members of the array
      VkImageDrmFormatModifierExplicitCreateInfoEXT::pPlaneLayouts.
      Should the extension re-use VkSubresourceLayout as the array
      members? Or should it define a new struct with less fields than
      VkSubresourceLayout?

    - If an image has a modifier that requires an extra plane (such as
      a color-compression plane), should the extension allow such an
      image to be disjoint? Specifically, if a modifier requires an
      extra plane, should the extension allow the modifier's
      drmFormatModifierTilingFeatures to contain
      VK_FORMAT_FEATURE_DISJOINT_KHR?

      I've tentatively concluded "no": images with extra planes must be
      non-disjoint. Though we could lift this restriction in a future
      extension.

Branches
========
I maintain a public branch of the Vulkan spec, branch
1.0-VK_EXT_image_drm_format_modifier, which is synchronized with the
Khronos-internal branch of the same name. I like cgit; other people like
Github; so I keep a mirror at both.

    cgit: http://git.kiwitree.net/cgit/~chadv/vulkan-spec/log?h=1.0-VK_EXT_image_drm_format_modifier
    github: https://github.com/chadversary/vulkan-spec/commits/1.0-VK_EXT_image_drm_format_modifier
    khronos-internal: https://gitlab.khronos.org/vulkan/vulkan/merge_requests/2555


Prebuilt Specs
==============
I maintain a public build of the branch. The built headers and HTML
specification are synchronized with the git branch thanks to the magic
of shell scripts.

    vulkan.h: http://git.kiwitree.net/cgit/~chadv/vulkan-spec/tree/src/vulkan/vulkan.h?h=1.0-VK_EXT_image_drm_format_modifier
    spec appendix: http://kiwitree.net/~chadv/vulkan/1.0-VK_EXT_image_drm_format_modifier/html/vkspec.html#VK_EXT_image_drm_format_modifier
    full spec: http://kiwitree.net/~chadv/vulkan/1.0-VK_EXT_image_drm_format_modifier/html/vkspec.html


Where to start reading
======================
Here's a short reading guide for people unfamiliar with the extension:

    - Don't start with the specification. You'll quickly get lost.

    - First, read the VK_EXT_external_memory_dma_buf and
      VK_EXT_queue_family_foreign extensions. They're small extensions.
      They're intended to be used with VK_EXT_image_drm_format_modifier.
      Despite that intent, the the three extensions are independent from
      the Vulkan specification's perspective.

    - Read the appendix chapter for VK_EXT_image_drm_format_modifier.
      I've written an "introduction to modifiers" section in the
      appendix. If you're already intimately understand modifiers, then
      you can briefly scan this section, skipping over the boring stuff.

    - Read the issue section in the appendix.

    - Now for the tofu. Study the new structs and functions. Find them
      under `#define VK_EXT_image_drm_format_modifier` in vulkan.h.
      Also, study the new enums values. Find them by grepping 'DRM.*EXT'
      in vulkan.h.

    - Finally, go read the specification text for the new structs,
      functions, and enums.


How to send feedback
====================
I honestly don't know. You _could_ comment on the merge request
in the Khronos-internal Gitlab. But you probably (and rightfully so)
want to keep the discussion public.

You could provide general feedback by replying to this thread.

You could leave comments on my Github branch. I don't like Github, but
I can't think of a better solution, other than...

I could send my specification patches to mesa-dev. If people want that,
say so.

So... yeah. I don't know how you should provide feedback. Just do it,
and we'll iron out any problems as they arise.