On 10/11/2013 03:29 PM, John Sheu 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.)  Hopefully 
the extension's still at a stage where we
can fix up this inconsistency.

Yes. Let's update the spec to have a saner interface before we lose a handle on 
all the consumers.

To my knowledge, there exists only two implementations.

ARM ships an implementation for Android on Mali. I don't see such
a spec update hurting ARM, because Android devices
are fairly locked down systems with a monolithic source tree for each
device.

As you saw in Mesa, only Intel supports the extension. Today, Piglit
is the only consumer. And there exists no real Mesa release that
supports it. (That is, Mesa 9.2 doesn't support it; only git master
does).

_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to