[Mesa-dev] [PATCH] [RFC] mesa: propose simple EGL_MESA_image_dma_buf_export

[Dave Airlie]

>>
>> On 29 August 2014 08:46, Gwenole Beauchesne <gb.devel at gmail.com> wrote:
>>>
>>> Could you please describe in there the ownership model? I think the
>>> implementation should own the fd, so the clients should dup() it if
>>> ever necessary.
>>
>>
>> So the fd can be destroyed at any time, particularly with threads? Meaning
>> that if you want to use it, then the first thing you need to do before all
>> others, is to dup() it, but in theory it could be destroyed by then too ...
>>
>> Much better to hand the client back something that it unambiguously owns,
>> where there's no possibility for interference. Note how
>> EGL_EXT_image_dma_buf_import was revised from the same shared
>> 'implementation owns fd so client should dup() model', to one where the
>> implementation internally dup()s.
>
> Yes, makes sense then. Either way, we need to be unambiguous.

6 months later I get back to this, not bad!

Okay I can change the fd ownership issue to one where we internally
dup and hand it back.

>
>>> Do we have a Query API for EGLImage? I thought that was for EGLSurface
>>> only. I mean, if not, that could be interesting to retrieve all the
>>> necessary other attributes, or extend the eglExportDMABufImageMESA()
>>> function to include the same level of information than what we have
>>> for EXT_image_dma_buf_import. e.g. multi-plane stride information for
>>> instance, up to including the actual format.
>>>
>>> What happens if the EGLImage is not backing a 2D texture?
>>
>>
>> Or TEXTURE_EXTERNAL, surely? Anyway, isn't that restriction a bit too harsh,
>> that the image has to be bound (or have been bound once?) to
>> TEXTURE_{2D,EXTERNAL}? Given how EGLImage is used as a neutral interchange
>> type/format in places, I think supporting dma_buf_import -> EGLImage ->
>> dma_buf_export, with no need to ever bind it to GLES texture units, is a
>> useful thing to have.
>
> That's what I was wondering about too. Though, this proposal could
> immediately fit my needs. I was curious about the non-2D texture
> cases. A Query API for images might be useful to have. That way,
> EGL_MESA_image_dma_buf_export would remain the unique and future proof
> interface to get the dma_buf fd, and only that. And the Query API be
> useful to extract any side information that would be needed depending
> on the original <target>. WDYT?

So there is resistance to a query API upstream in the KHR area, at
least according
to https://www.khronos.org/registry/egl/extensions/MESA/EGL_MESA_drm_image.txt
which I based this on.

So I'm wondering how would this API look if we are going to pass back
multiple fd, pitches, offsets etc to mirror the other API.

eglExportImageQueryMesa(EGLDisplay dpy, EGLImageKHR image, int
*num_planes, int *fourcc);
then the original interface can return 3 fds, 3 planes and 3 offsets

 EGLBoolean eglExportDMABUFImageMESA(EGLDisplay dpy,
                                        EGLImageKHR image,
                                        int *fd,
                                        EGLint *stride,);