Re: [PATCH] intel: make bufmgr_gem shareable from different API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 11, 2014 at 12:33:41PM +0100, Lionel Landwerlin wrote:
> When using Mesa and LibVA in the same process, one would like to be
> able bind buffers from the output of the decoder to a GL texture
> through an EGLImage.
> 
> LibVA can reuse buffers allocated by Gbm through a file descriptor. It
> will then wrap it into a drm_intel_bo with
> drm_intel_bo_gem_create_from_prime().
> 
> Given both libraries are using libdrm to allocate and use buffer
> objects, there is a need to have the buffer objects properly
> refcounted. That is possible if both API use the same drm_intel_bo
> objects, but that also requires that both API use the same
> drm_intel_bufmgr object.

The description is wrong though. Reusing buffers export and import
through a dmabuf, should work and be correctly refcounted already.

This patch adds the ability to use the same /dev/dri/card0 device fd
between two libraries. This implies that they share the same context and
address space, which is probably not what you want, but nevertheless
seems sensible if they are sharing the device fd in the first place.

I suspect this may break unwary users such as igt, which would fork
after creating a bufmgr, close the fds, but then open their own device
fd with the same fd as before. Not a huge issue, just something to check
in case it causes some fun fallout.
 
> This patch modifies drm_intel_bufmgr_gem_init() so given a file
> descriptor, it will look for an already existing drm_intel_bufmgr
> using the same file descriptor and return that object.
> 
> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@xxxxxxxxx>
> ---
>  intel/intel_bufmgr_gem.c | 100 +++++++++++++++++++++++++++++++++++++++++------
>  1 file changed, 88 insertions(+), 12 deletions(-)
> 
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index 0e1cb0d..125c81c 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -94,6 +94,8 @@ struct drm_intel_gem_bo_bucket {
>  typedef struct _drm_intel_bufmgr_gem {
>  	drm_intel_bufmgr bufmgr;
>  
> +	atomic_t refcount;
> +
>  	int fd;
>  
>  	int max_relocs;
> @@ -3186,6 +3188,85 @@ drm_intel_bufmgr_gem_set_aub_annotations(drm_intel_bo *bo,
>  	bo_gem->aub_annotation_count = count;
>  }
>  
> +static pthread_mutex_t bufmgr_list_mutex = PTHREAD_MUTEX_INITIALIZER;
> +static drm_intel_bufmgr_gem **bufmgr_list = NULL;
> +static unsigned bufmgr_list_size = 0, bufmgr_list_nb;
> +
> +static drm_intel_bufmgr_gem *
> +drm_intel_bufmgr_gem_find_or_create_for_fd(int fd, int *found)
> +{
> +        drm_intel_bufmgr_gem *bufmgr_gem;
> +
> +        assert(pthread_mutex_lock(&bufmgr_list_mutex) == 0);
> +
> +        if (bufmgr_list == NULL) {

Just use an embedded list rather than array, that would greatly simplify
the search, cration and deletion.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux