[Mesa-dev] [PATCH 04/13] todo! dri: Questions about fence fd ownership

[Rob Clark]

On Fri, Jul 8, 2016 at 8:00 PM, Chad Versace <chad.versace at intel.com> wrote:
> See the comments.
> ---
>  include/GL/internal/dri_interface.h | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/include/GL/internal/dri_interface.h b/include/GL/internal/dri_interface.h
> index 99c83ec..051ddb4 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -418,6 +418,12 @@ struct __DRI2fenceExtensionRec {
>      *
>      * \param ctx     the context associated with the fence
>      * \param fd      the fence fd or -1
> +    *
> +    * TODO(chadv): Who owns the fence fd when the caller imports it (when
> +    * fd != 1)? Does EGL or the driver own it?
> +    *
> +    * TODO(chadv): Who owns the fence fd when the driver creates it (when
> +    * fd == -1)? Does EGL or the driver own it?

btw, thanks for picking up this patchset.. it was on my TODO list for
a while, but never quite bubbled up to the top..

When the caller creates an egl fence from an fd, the driver takes
ownership (and the caller must dup() if it wants to hold on to the fd
itself).  When caller calls eglDupNativeFenceFD() the caller takes
ownership of the returned fd (so the driver must dup()).

As far as internal ownership, I don't 100% remember what my plan was..
I guess the driver needs to dup(), since at the egl api level the
fence can be destroyed while the internal dri2_egl_sync is still live
due to driver holding a ref.

BR,
-R

>      */
>     void *(*create_fence_fd)(__DRIcontext *ctx, int fd);
>
> @@ -430,6 +436,9 @@ struct __DRI2fenceExtensionRec {
>      *
>      * \param screen  the screen associated with the fence
>      * \param fence   the fence
> +    *
> +    * TODO(chadv): Should the driver return its actual fence fd? Or should it
> +    * return a dup'd fd?
>      */
>     int (*get_fence_fd)(__DRIscreen *screen, void *fence);
>  };
> --
> 2.9.0.rc2
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev