From: "Christian König" <christian.koenig@amd.com>
To: Gustavo Padovan <gustavo@padovan.org>, 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: Re: [RFC 0/5] rework fences on struct sync_file
Date: Fri, 24 Jun 2016 11:27:39 +0200 [thread overview]
Message-ID: <576CFD0B.6000501@amd.com> (raw)
In-Reply-To: <1466695790-2833-1-git-send-email-gustavo@padovan.org>
Am 23.06.2016 um 17:29 schrieb Gustavo Padovan:
> 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.
>
> Two fence ops had to be created to help abstract the difference between handling
> fences and fences_arrays: .teardown() and .get_fences(). The former run needed
> on fence_array, and the latter just return a copy of all fences in the fence.
> I'm not so sure about adding those two, speacially .get_fences(). What do you
> think?
Clearly not a good idea to add this a fence ops, cause those are
specialized functions for only a certain fence implementation (the
fence_array).
What you should do is try to cast the fence in your sync file using
to_fence_array() and then you can access the fences in the array.
Regards,
Christian.
>
> Please comment! Thanks.
>
> Gustavo
> ---
>
> Gustavo Padovan (5):
> dma-buf/fence: add .teardown() ops
> dma-buf/fence-array: add fence_array_teardown()
> dma-buf/fence: add .get_fences() ops
> dma-buf/fence-array: add fence_array_get_fences()
> dma-buf/sync_file: rework fence storage in struct file
>
> drivers/dma-buf/fence-array.c | 30 ++++++++
> drivers/dma-buf/fence.c | 21 ++++++
> drivers/dma-buf/sync_file.c | 129 +++++++++++++++++++++++++----------
> drivers/staging/android/sync_debug.c | 5 +-
> include/linux/fence.h | 10 +++
> include/linux/sync_file.h | 12 ++--
> 6 files changed, 161 insertions(+), 46 deletions(-)
>
_______________________________________________
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: Gustavo Padovan <gustavo@padovan.org>, <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: Re: [RFC 0/5] rework fences on struct sync_file
Date: Fri, 24 Jun 2016 11:27:39 +0200 [thread overview]
Message-ID: <576CFD0B.6000501@amd.com> (raw)
In-Reply-To: <1466695790-2833-1-git-send-email-gustavo@padovan.org>
Am 23.06.2016 um 17:29 schrieb Gustavo Padovan:
> 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.
>
> Two fence ops had to be created to help abstract the difference between handling
> fences and fences_arrays: .teardown() and .get_fences(). The former run needed
> on fence_array, and the latter just return a copy of all fences in the fence.
> I'm not so sure about adding those two, speacially .get_fences(). What do you
> think?
Clearly not a good idea to add this a fence ops, cause those are
specialized functions for only a certain fence implementation (the
fence_array).
What you should do is try to cast the fence in your sync file using
to_fence_array() and then you can access the fences in the array.
Regards,
Christian.
>
> Please comment! Thanks.
>
> Gustavo
> ---
>
> Gustavo Padovan (5):
> dma-buf/fence: add .teardown() ops
> dma-buf/fence-array: add fence_array_teardown()
> dma-buf/fence: add .get_fences() ops
> dma-buf/fence-array: add fence_array_get_fences()
> dma-buf/sync_file: rework fence storage in struct file
>
> drivers/dma-buf/fence-array.c | 30 ++++++++
> drivers/dma-buf/fence.c | 21 ++++++
> drivers/dma-buf/sync_file.c | 129 +++++++++++++++++++++++++----------
> drivers/staging/android/sync_debug.c | 5 +-
> include/linux/fence.h | 10 +++
> include/linux/sync_file.h | 12 ++--
> 6 files changed, 161 insertions(+), 46 deletions(-)
>
next prev parent reply other threads:[~2016-06-24 9:27 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-23 15:29 [RFC 0/5] rework fences on struct sync_file Gustavo Padovan
2016-06-23 15:29 ` Gustavo Padovan
2016-06-23 15:29 ` [RFC 1/5] dma-buf/fence: add .teardown() ops Gustavo Padovan
2016-06-23 20:48 ` Chris Wilson
2016-06-23 20:48 ` Chris Wilson
2016-06-24 13:19 ` Gustavo Padovan
2016-06-24 13:19 ` Gustavo Padovan
2016-07-12 10:51 ` Daniel Vetter
2016-07-12 10:51 ` Daniel Vetter
2016-06-23 15:29 ` [RFC 2/5] dma-buf/fence-array: add fence_array_teardown() Gustavo Padovan
2016-06-23 15:29 ` Gustavo Padovan
2016-06-23 15:29 ` [RFC 3/5] dma-buf/fence: add .get_fences() ops Gustavo Padovan
2016-06-23 15:29 ` Gustavo Padovan
2016-06-23 20:40 ` Chris Wilson
2016-06-23 20:40 ` Chris Wilson
2016-07-12 10:52 ` Daniel Vetter
2016-07-12 10:52 ` Daniel Vetter
2016-06-23 15:29 ` [RFC 4/5] dma-buf/fence-array: add fence_array_get_fences() Gustavo Padovan
2016-06-23 20:35 ` Chris Wilson
2016-06-23 20:35 ` Chris Wilson
2016-06-23 15:29 ` [RFC 5/5] dma-buf/sync_file: rework fence storage in struct file Gustavo Padovan
2016-06-23 21:27 ` Chris Wilson
2016-06-23 21:27 ` Chris Wilson
2016-06-24 13:23 ` Gustavo Padovan
2016-06-24 13:23 ` Gustavo Padovan
2016-06-24 9:27 ` Christian König [this message]
2016-06-24 9:27 ` [RFC 0/5] rework fences on struct sync_file Christian König
2016-06-24 13:17 ` Gustavo Padovan
2016-06-24 13:17 ` Gustavo Padovan
2016-06-24 14:14 ` Christian König
2016-06-24 14:14 ` Christian König
2016-06-24 14:59 ` Gustavo Padovan
2016-06-24 15:09 ` Christian König
2016-06-24 15:09 ` Christian König
2016-06-24 15:19 ` 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=576CFD0B.6000501@amd.com \
--to=christian.koenig@amd.com \
--cc=John.C.Harrison@Intel.com \
--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.