[Mesa-dev] EXT_image_dma_buf_import FD ownership
krh at bitplanet.net
Mon Oct 14 20:21:44 CEST 2013
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.
> 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
More information about the mesa-dev