All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gustavo Padovan <gustavo@padovan.org>
To: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org,
	Daniel Stone <daniels@collabora.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Rob Clark <robdclark@gmail.com>,
	Greg Hackmann <ghackmann@google.com>,
	John Harrison <John.C.Harrison@Intel.com>,
	laurent.pinchart@ideasonboard.com, seanpaul@google.com,
	marcheu@google.com, m.chehab@samsung.com,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Subject: [PATCH 0/2] dma-buf/sync_file: rework fences on struct sync_file
Date: Thu, 30 Jun 2016 11:09:46 -0300	[thread overview]
Message-ID: <1467295788-6422-1-git-send-email-gustavo@padovan.org> (raw)

From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

Hi all, 
  
This is an attempt to improve fence support on Sync File. The basic idea  
is to have only sync_file->fence and store all fences there, either as 
normal fences or fence_arrays. That way we can remove some potential
duplication when using fence_array with sync_file: the duplication of the array 
of fences and the duplication of fence_add_callback() for all fences.  
  
Now when creating a new sync_file during the merge process sync_file_set_fence()
will set sync_file->fence based on the number of fences for that sync_file. If  
there is more than one fence a fence_array is created. One important advantage  
approach is that we only add one fence callback now, no matter how many fences  
there are in a sync_file - the individual callbacks are added by fence_array.
  
Please review! Thanks! 
  
  Gustavo  

Changes since RFC v2 (Comments from Chris Wilson and Christian König):  
 - struct sync_file lost status member in favor of fence_is_signaled()
 - drop use of fence_array_teardown()
 - use sizeof(*fence) to allocate only an array on fence pointers

Changes since RFC v1 (Comments from Chris Wilson and Christian König):  
 - Not using fence_ops anymore.
 - fence_is_array() was created to differentiate fence from fence_array  
 - fence_array_teardown() is now exported and used under fence_is_array()
 - struct sync_file lost num_fences member 

Gustavo Padovan (2):
  dma-buf/fence-array: add fence_is_array()
  dma-buf/sync_file: rework fence storage in struct file

 drivers/dma-buf/sync_file.c          | 163 ++++++++++++++++++++++-------------
 drivers/staging/android/sync_debug.c |  13 ++-
 include/linux/fence-array.h          |  10 +++
 include/linux/sync_file.h            |  17 ++--
 4 files changed, 128 insertions(+), 75 deletions(-)

-- 
2.5.5

WARNING: multiple messages have this Message-ID (diff)
From: Gustavo Padovan <gustavo@padovan.org>
To: dri-devel@lists.freedesktop.org
Cc: marcheu@google.com, Daniel Stone <daniels@collabora.com>,
	seanpaul@google.com, Daniel Vetter <daniel.vetter@ffwll.ch>,
	linux-kernel@vger.kernel.org, laurent.pinchart@ideasonboard.com,
	Gustavo Padovan <gustavo.padovan@collabora.co.uk>,
	John Harrison <John.C.Harrison@Intel.com>,
	m.chehab@samsung.com
Subject: [PATCH 0/2] dma-buf/sync_file: rework fences on struct sync_file
Date: Thu, 30 Jun 2016 11:09:46 -0300	[thread overview]
Message-ID: <1467295788-6422-1-git-send-email-gustavo@padovan.org> (raw)

From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

Hi all, 
  
This is an attempt to improve fence support on Sync File. The basic idea  
is to have only sync_file->fence and store all fences there, either as 
normal fences or fence_arrays. That way we can remove some potential
duplication when using fence_array with sync_file: the duplication of the array 
of fences and the duplication of fence_add_callback() for all fences.  
  
Now when creating a new sync_file during the merge process sync_file_set_fence()
will set sync_file->fence based on the number of fences for that sync_file. If  
there is more than one fence a fence_array is created. One important advantage  
approach is that we only add one fence callback now, no matter how many fences  
there are in a sync_file - the individual callbacks are added by fence_array.
  
Please review! Thanks! 
  
  Gustavo  

Changes since RFC v2 (Comments from Chris Wilson and Christian König):  
 - struct sync_file lost status member in favor of fence_is_signaled()
 - drop use of fence_array_teardown()
 - use sizeof(*fence) to allocate only an array on fence pointers

Changes since RFC v1 (Comments from Chris Wilson and Christian König):  
 - Not using fence_ops anymore.
 - fence_is_array() was created to differentiate fence from fence_array  
 - fence_array_teardown() is now exported and used under fence_is_array()
 - struct sync_file lost num_fences member 

Gustavo Padovan (2):
  dma-buf/fence-array: add fence_is_array()
  dma-buf/sync_file: rework fence storage in struct file

 drivers/dma-buf/sync_file.c          | 163 ++++++++++++++++++++++-------------
 drivers/staging/android/sync_debug.c |  13 ++-
 include/linux/fence-array.h          |  10 +++
 include/linux/sync_file.h            |  17 ++--
 4 files changed, 128 insertions(+), 75 deletions(-)

-- 
2.5.5

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

             reply	other threads:[~2016-06-30 15:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-30 14:09 Gustavo Padovan [this message]
2016-06-30 14:09 ` [PATCH 0/2] dma-buf/sync_file: rework fences on struct sync_file Gustavo Padovan
2016-06-30 14:09 ` [PATCH 1/2] dma-buf/fence-array: add fence_is_array() Gustavo Padovan
2016-06-30 14:09   ` Gustavo Padovan
2016-06-30 14:23   ` Chris Wilson
2016-06-30 14:23     ` Chris Wilson
2016-06-30 21:55     ` Chris Wilson
2016-06-30 21:55       ` Chris Wilson
2016-06-30 14:09 ` [PATCH 2/2] dma-buf/sync_file: rework fence storage in struct file Gustavo Padovan
2016-06-30 14:09   ` Gustavo Padovan
2016-06-30 14:22   ` Chris Wilson
2016-06-30 14:22     ` Chris Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1467295788-6422-1-git-send-email-gustavo@padovan.org \
    --to=gustavo@padovan.org \
    --cc=John.C.Harrison@Intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniels@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ghackmann@google.com \
    --cc=gustavo.padovan@collabora.co.uk \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=marcheu@google.com \
    --cc=robdclark@gmail.com \
    --cc=seanpaul@google.com \
    --cc=sumit.semwal@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.