WIP cl_ext_image_drm_format_modifier

[kpet]

• Do we need a Vulkan mechanism to get a DRM format modifier for an image exported from Vulkan?

[bcalidas]

Sharing some initial feedback.

1. For cl_ext_image_tiling_control, is there really a need for the CL_DEVICE_IMAGE_TILING_DEVICE_ACCESS_EXT token.

2. For cl_ext_image_tiling_control does CL_DEVICE_IMAGE_TILING_HOST_ACCESS_EXT relate to whether or not the implementation will detile the image on mapping?

3. For cl_ext_image_tiling_control, is there an assumption that the image is linear if no explicit tiling mode is forced. To us it seemed that the spec implicitly suggested optimal tiling by default.

4. For cl_ext_image_drm_format_modifer, why would a drm format modifier be required for an image. Shouldn't drm format modifiers be viewed as a decoration of top of optimal tiling. Our thinking was that drm format modifiers would be applied only when importing an optimally tiled image. Additionally, they could be queried for any image ( including linear ) but an application would only make the query when exporting an image.

5. For cl_ext_image_drm_format_modifier, how are we planning to manage the drm format modifier header file from the implementation side and from the application side.

[bashbaug]

At least for Vulkan, there are two ways to create an image with a DRM format modifier:

1. Using VkImageDrmFormatModifierExplicitCreateInfoEXT, which requires creating the image with the exact DRM format modifier specified. This is analogous to the CL_MEM_IMAGE_DRM_FORMAT_MODIFIER_EXT property added by this extension.
2. Using VkImageDrmFormatModifierListCreateInfoEXT, which allows creating the image from a set of specified DRM format modifiers. This provides the implementation with some freedom to choose what it considers to be the best DRM format modifier.

Should we support (2) and add the ability to pass a list of viable DRM format modifiers as well?

Note, if we added this functionality, then the application should still be able to query CL_IMAGE_DRM_FORMAT_MODIFIER_EXT to determine which of the DRM format modifiers in the set was chosen.

[kpet]

Discussed in the 2025/04/15 memory TSG teleconference: another way of allowing implementations to express a preferred DRM modifier (which is what we'd really get with (2)) would be to state that the list of supported DRM modifiers reported by the implementation is ordered by preference. No strong preference for one or the other approach expressed on the call.

[nyanmisaka]

Just wondering if there is a way in ARM libMali to import AFBC compressed images? I came across this draft by accident while searching.

In my use case the hardware video decoder is able to produce images with the AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 DRM format modifer and it would help performance (reduce memory bandwidth utilizing) if libMali could directly import that instead of requiring linear images.

[kpet]

Just wondering if there is a way in ARM libMali to import AFBC compressed images? I came across this draft by accident while searching.

@nyanmisaka Yes, this is supported in shipping drivers using this extension. I'm happy to help you get going with it. Feel free to reach out at [email protected].