[Mesa-dev] EXT_image_dma_buf_import FD ownership

[Kristian Høgsberg]

On Fri, Oct 11, 2013 at 3:29 PM, John Sheu <sheu at google.com> wrote:
> Hello folks:
>
> About the ownership of dmabuf file descriptors that are passed into EGL.
> I'm looking in particular at this blurb from the spec:
>
>        * If <target> is EGL_LINUX_DMA_BUF_EXT and eglCreateImageKHR fails,
>          EGL does not retain ownership of the file descriptor and it is the
>          responsibility of the application to close it."
>
> My take on this is that this is different from most users of dmabuf, or even
> file descriptors in general.  For example, mmap() doesn't own the descriptor
> passed to it; and more specifically to dmabufs, neither does (say)
> DRM_IOCTL_PRIME_HANDLE_TO_FD, or any of the V4L2 entry points that support
> dmabuf (e.g. VIDIOC_QBUF).  They all increment the refcount on the
> descriptor, not own it.
>
> Since we're still iterating drafts on the EXT_image_dma_buf_import spec --
> I'd like to see the spec specify that EGL has the similar behavior of taking
> a reference, but not owning the descriptor.
>
> As far as I see, in Mesa, only the Intel stack has implemented
> EXT_image_dma_buf_import, and the change would be fairly trivial (removing
> dri2_take_dma_buf_ownership), since it eventually just passes the FD down to
> DRM_IOCTL_PRIME_HANDLE_TO_FD.  And as far as I'm aware, the piglit
> conformance tests are the only present consumers.  (Maybe the Wayland folks
> have something to say about this too.)

We don't use the EXT_image_dma_buf_import extension, we hide all the
details in a Wayland specific extensions.  But I do agree that the fd
life-cycle semantics in the dma_buf extensions are non-standard and it
would be cleaner for it to not take ownership of the fd.

Kristian

> Hopefully the extension's still at a
> stage where we can fix up this inconsistency.
>
> -John Sheu
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>