EXT_image_dma_buf_import format enumeration about egl-registry

[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.

[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.

[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.