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

[Gwenole Beauchesne]

Hi,

2014-08-29 10:05 GMT+02:00 Daniel Stone <daniel at fooishbar.org>:
> Hi,
>
> 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.

>> 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?

Regards,
Gwenole.