EXT_image_dma_buf_import format enumeration

[emersion]

EXT_image_dma_buf_import allows one to import DMA-BUFs, but doesn't allow one to enumerate the list of supported formats. EXT_image_dma_buf_import_modifiers fixes this by adding eglQueryDmaBufFormatsEXT.

The ability to enumerate formats is key for proper format negotiation, e.g. in a Wayland compositor. The latest linux-dmabuf protocol version doesn't allow clients to import DMA-BUFs for formats not advertised by the compositor.

Some drivers don't support modifiers. Because format enumeration is important, Mesa will still advertise EXT_image_dma_buf_import_modifiers for these drivers (and return an empty list in eglQueryDmaBufModifiersEXT).

But none of this is documented anywhere. It would be nice to settle on a solution and add it to the EGL specs. Here are two possible proposals:

1. Document that drivers supporting EXT_image_dma_buf_import should also support EXT_image_dma_buf_import_modifiers even if they don't support modifiers.
2. Add a new EXT_image_dma_buf_import_formats extension, which is a subset of EXT_image_dma_buf_import_modifiers: it would contain only eglQueryDmaBufFormatsEXT but not eglQueryDmaBufModifiersEXT. Slightly more work, but if it makes sense to you I'm willing to send patches around.

Thoughts?

cc @cubanismo @fooishbar

[stonesthrow]

Thanks @emersion , I will bring this to GLES/EGL WG , but we will need you/MESA people to craft the work/specs. Just not enough people and bandwidth to support linux platform properly.

[fooishbar]

I have a very strong preference for #1. Now that all the modifier entrypoints accept (and queries advertise) DRM_FORMAT_MOD_INVALID, and we've all gone out and typed out support for that exact usecase, I don't see what benefit #2 would bring us.

Suggested addition to EGL_EXT_image_dma_buf_import_modifiers question section:

1. What if my implementation does not support DRM format modifiers?
   It is strongly recommended that every implementation supporting dmabuf import also implements this extension. DRM_FORMAT_MOD_INVALID is a special modifier token indicating that the exact layout is not known and will be determined by implementation-defined semantics. Platforms not supporting modifiers should implement this extension, advertising only the DRM_FORMAT_MOD_INVALID modifier for every supported format, and accepting only the DRM_FORMAT_MOD_INVALID modifier for EGLImage import.

Suggested addition to EGL_EXT_image_dma_buf_import question section:

1. How can clients discover the set of supported formats?
   Every driver supporting dmabuf import should implement the EGL_EXT_image_dma_buf_import_modifiers extension, even if they do not support modifiers. This extension adds format-advertisement entrypoints, and as detailed in that extension's question section, DRM_FORMAT_MOD_INVALID is used to implement the same behaviour as without that extension, i.e. that the exact buffer layout is not known and will be determined by implementation-defined semantics.

[emersion]

This looks like a good idea to me. This would let drivers return an external_only flag for implicit modifiers too, which is useful to know whether rendering to a buffer using this format is possible. This isn't possible if the driver returns zero modifiers.

I'll type up the Mesa patch for this.

[cubanismo]

Are there drivers that don't advertise EGL_EXT_image_dma_buf_import_modifiers but do advertise EXT_image_dma_buf_import? If not, I'd prefer stronger language, e.g., just updating EXT_image_dma_buf_import's dependency section to require EGL_EXT_image_dma_buf_import_modifiers, and modifying Daniel's proposed text above accordingly.

[emersion]

IIRC the Mali proprietary blob does this? @fooishbar probably knows more.

[fooishbar]

It depends on how the SoC vendor configures it (it’s not a single blob like NV), but a lot of them seem to ship it with dmabuf disabled entirely. I’ve yet to see a build with modifiers in the wild.

[shutaozhenzhen]

Are there drivers that don't advertise EGL_EXT_image_dma_buf_import_modifiers but do advertise EXT_image_dma_buf_import? If not, I'd prefer stronger language, e.g., just updating EXT_image_dma_buf_import's dependency section to require EGL_EXT_image_dma_buf_import_modifiers, and modifying Daniel's proposed text above accordingly.

I meet a soc which use mali G52, and support EXT_image_dma_buf_import, but do not support EGL_EXT_image_dma_buf_import_modifiers. eglQueryDmaBufFormatsEXT actually returns meanful fourcc codes, but only some of the return values are truely supported.

[fooishbar]

I assume this is using the proprietary Mali driver? Exposing the entrypoint without advertising the extension is not something that’s expected to work - and the driver can be trivially modified to work with the modifier extension by exposing only DRM_FORMAT_MOD_INVALID.