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
next 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: linkBe 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.