All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Gustavo Padovan <gustavo@padovan.org>,
	dri-devel@lists.freedesktop.org, 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,
	Alex Deucher <alexander.deucher@amd.com>,
	Gustavo Padovan <gustavo.padovan@collabora.co.uk>,
	John Harrison <John.C.Harrison@Intel.com>,
	m.chehab@samsung.com
Subject: Re: [PATCH 1/2] dma-buf/fence: add fence_collection fences
Date: Thu, 19 May 2016 09:46:47 +0200	[thread overview]
Message-ID: <573D6F67.7070109@amd.com> (raw)
In-Reply-To: <20160518225710.GA32627@nuc-i3427.alporthouse.com>

Am 19.05.2016 um 00:57 schrieb Chris Wilson:
> On Wed, May 18, 2016 at 05:59:52PM -0300, Gustavo Padovan wrote:
>> +static void collection_check_cb_func(struct fence *fence, struct fence_cb *cb)
>> +{
>> +	struct fence_collection_cb *f_cb;
>> +	struct fence_collection *collection;
>> +
>> +	f_cb = container_of(cb, struct fence_collection_cb, cb);
>> +	collection = f_cb->collection;
>> +
>> +	if (atomic_dec_and_test(&collection->num_pending_fences))
>> +		fence_signal(&collection->base);
>> +}
>> +
>> +static bool fence_collection_enable_signaling(struct fence *fence)
>> +{
>> +	struct fence_collection *collection = to_fence_collection(fence);
>> +	int i;
>> +
>> +	for (i = 0 ; i < collection->num_fences ; i++) {
>> +		if (fence_add_callback(collection->fences[i].fence,
>> +				       &collection->fences[i].cb,
>> +				       collection_check_cb_func)) {
>> +			atomic_dec(&collection->num_pending_fences);
>> +		}
>> +	}
> We don't always have a convenient means to preallocate an array of
> fences to use. Keeping a list of fences in addition to the array would
> be easier to user in many circumstances.

I agree that there is use for such an implementation as well, but as 
mentioned in the last review cycle we intentionally chose an array 
instead of a more complex implementation here.

This way the array can be passed to function like 
fence_wait_any_timeout() as well.

I also suggested to rename it to fence_array to make that difference 
clear and allow for another implementation to live side by side with this.

My crux at the moment is that I need both for the amdgpu driver, an 
array based implementation and a collection like one.

Gustavo would you mind if I take your patches and work a bit on this?

>
> Just means we need a
>
> struct fence_collection_entry {
> 	struct fence *fence;
> 	struct list_head link;
> };
>
> int fence_collection_add(struct fence *_collection,
> 			 struct fence *fence)
> {
> 	struct fence_collection *collection =
> 		to_fence_collection(_collection);
> 	struct fence_collection_entry *entry;
>
> 	entry = kmalloc(sizeof(*entry), GFP_KERNEL);
> 	if (!entry)
> 		return -ENOMEM;
>
> 	entry->fence = fence_get(fence);
> 	list_add_tail(&entry->link, &collection->fence_list);
> 	atomic_inc(&collection->num_pending_fences);
>
> 	return 0;
> }
>
> and a couple of list iterations as well as walking the arrays.
>
> (This fence_collection_add() needs to be documented to only be valid
> from the constructing thread before the fence is sealed for export/use.)

As suggested by Daniel as well I would prefer that the the array 
implementation only gets the fences as already filled array in the 
constructor. This is much more fail save.

Christian.

> -Chris
>

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

WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Gustavo Padovan <gustavo@padovan.org>,
	<dri-devel@lists.freedesktop.org>, <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>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	Gustavo Padovan <gustavo.padovan@collabora.co.uk>,
	John Harrison <John.C.Harrison@Intel.com>, <m.chehab@samsung.com>
Subject: Re: [PATCH 1/2] dma-buf/fence: add fence_collection fences
Date: Thu, 19 May 2016 09:46:47 +0200	[thread overview]
Message-ID: <573D6F67.7070109@amd.com> (raw)
In-Reply-To: <20160518225710.GA32627@nuc-i3427.alporthouse.com>

Am 19.05.2016 um 00:57 schrieb Chris Wilson:
> On Wed, May 18, 2016 at 05:59:52PM -0300, Gustavo Padovan wrote:
>> +static void collection_check_cb_func(struct fence *fence, struct fence_cb *cb)
>> +{
>> +	struct fence_collection_cb *f_cb;
>> +	struct fence_collection *collection;
>> +
>> +	f_cb = container_of(cb, struct fence_collection_cb, cb);
>> +	collection = f_cb->collection;
>> +
>> +	if (atomic_dec_and_test(&collection->num_pending_fences))
>> +		fence_signal(&collection->base);
>> +}
>> +
>> +static bool fence_collection_enable_signaling(struct fence *fence)
>> +{
>> +	struct fence_collection *collection = to_fence_collection(fence);
>> +	int i;
>> +
>> +	for (i = 0 ; i < collection->num_fences ; i++) {
>> +		if (fence_add_callback(collection->fences[i].fence,
>> +				       &collection->fences[i].cb,
>> +				       collection_check_cb_func)) {
>> +			atomic_dec(&collection->num_pending_fences);
>> +		}
>> +	}
> We don't always have a convenient means to preallocate an array of
> fences to use. Keeping a list of fences in addition to the array would
> be easier to user in many circumstances.

I agree that there is use for such an implementation as well, but as 
mentioned in the last review cycle we intentionally chose an array 
instead of a more complex implementation here.

This way the array can be passed to function like 
fence_wait_any_timeout() as well.

I also suggested to rename it to fence_array to make that difference 
clear and allow for another implementation to live side by side with this.

My crux at the moment is that I need both for the amdgpu driver, an 
array based implementation and a collection like one.

Gustavo would you mind if I take your patches and work a bit on this?

>
> Just means we need a
>
> struct fence_collection_entry {
> 	struct fence *fence;
> 	struct list_head link;
> };
>
> int fence_collection_add(struct fence *_collection,
> 			 struct fence *fence)
> {
> 	struct fence_collection *collection =
> 		to_fence_collection(_collection);
> 	struct fence_collection_entry *entry;
>
> 	entry = kmalloc(sizeof(*entry), GFP_KERNEL);
> 	if (!entry)
> 		return -ENOMEM;
>
> 	entry->fence = fence_get(fence);
> 	list_add_tail(&entry->link, &collection->fence_list);
> 	atomic_inc(&collection->num_pending_fences);
>
> 	return 0;
> }
>
> and a couple of list iterations as well as walking the arrays.
>
> (This fence_collection_add() needs to be documented to only be valid
> from the constructing thread before the fence is sealed for export/use.)

As suggested by Daniel as well I would prefer that the the array 
implementation only gets the fences as already filled array in the 
constructor. This is much more fail save.

Christian.

> -Chris
>

  reply	other threads:[~2016-05-19  7:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-18 20:59 [PATCH 1/2] dma-buf/fence: add fence_collection fences Gustavo Padovan
2016-05-18 20:59 ` Gustavo Padovan
2016-05-18 20:59 ` [PATCH 2/2] Documentation: add fence-collection to kernel DocBook Gustavo Padovan
2016-05-18 20:59   ` Gustavo Padovan
2016-05-18 22:57 ` [PATCH 1/2] dma-buf/fence: add fence_collection fences Chris Wilson
2016-05-18 22:57   ` Chris Wilson
2016-05-19  7:46   ` Christian König [this message]
2016-05-19  7:46     ` Christian König
2016-05-19  7:57     ` Daniel Vetter
2016-05-19  7:57       ` Daniel Vetter
2016-05-19 13:20     ` Gustavo Padovan

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=573D6F67.7070109@amd.com \
    --to=christian.koenig@amd.com \
    --cc=John.C.Harrison@Intel.com \
    --cc=alexander.deucher@amd.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniels@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo.padovan@collabora.co.uk \
    --cc=gustavo@padovan.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=marcheu@google.com \
    --cc=seanpaul@google.com \
    /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.