From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lionel Landwerlin Subject: Re: [PATCH] intel: make bufmgr_gem shareable from different API Date: Thu, 11 Sep 2014 13:21:13 +0100 Message-ID: <541193B9.5070205@intel.com> References: <1410435221-16419-1-git-send-email-lionel.g.landwerlin@intel.com> <1410435221-16419-2-git-send-email-lionel.g.landwerlin@intel.com> <20140911115227.GK28332@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTP id C840E6E57B for ; Thu, 11 Sep 2014 05:21:19 -0700 (PDT) In-Reply-To: <20140911115227.GK28332@nuc-i3427.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Chris Wilson , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 11/09/14 12:52, Chris Wilson wrote: > 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. That's what I meant, sorry if it was unclear. > > 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. Will have a look, thanks. > >> 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 >> --- >> 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 > I tried to use the embedded list, but from my understanding I need the embedded structure at the top of the bufmgr struct. Is that possible? Sounds like an ABI break. Thanks, - Lionel