From: Simon Ser <contact@emersion.fr>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "Daniel Vetter" <daniel.vetter@ffwll.ch>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [Intel-gfx] [PATCH 5/7] dma-buf: Add an API for exporting sync files (v11)
Date: Thu, 27 May 2021 10:48:44 +0000 [thread overview]
Message-ID: <UhXviIJwnJG8qWOGYpAwgqll4W4TPSjVIFdG72MzhY4T2u7xS_Ql7OY-xlkfTR1HIoZ7-U8UhfqDsj62JIu98ESf_CfncvWougxT8JKm0ik=@emersion.fr> (raw)
In-Reply-To: <YK91kB0ikqxurHN1@phenom.ffwll.local>
On Thursday, May 27th, 2021 at 12:33 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > The sync_file is also import/exportable to a certain drm_syncobj timeline
> > point (or as binary signal). So no big deal, we are all compatible here :)
> > I just thought that it might be more appropriate to return a drm_syncobj
> > directly instead of a sync_file.
>
> I think another big potential user for this is a vk-based compositor which
> needs to interact/support implicit synced clients. And compositor world I
> think is right now still more sync_file (because that's where we started
> with atomic kms ioctl).
Yeah, right now compositors can only deal with sync_file. I have a
Vulkan pull request for wlroots [1] that would benefit from this, I
think.
Also it seems like drm_syncobj isn't necessarily going to be the the
sync primitive that ends them all with all that user-space fence
discussion, so long-term I guess we'll need a conversion anyways.
[1]: https://github.com/swaywm/wlroots/pull/2771
> Plus you can convert them to the other form anyway, so really doesn't
> matter much. But for the above reasons I'm leaning slightly towards
> sync_file. Except if compositor folks tell me I'm a fool and why :-)
sync_file is fine from my PoV.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Simon Ser <contact@emersion.fr>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "Daniel Vetter" <daniel.vetter@ffwll.ch>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
"Jason Ekstrand" <jason@jlekstrand.net>,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [Intel-gfx] [PATCH 5/7] dma-buf: Add an API for exporting sync files (v11)
Date: Thu, 27 May 2021 10:48:44 +0000 [thread overview]
Message-ID: <UhXviIJwnJG8qWOGYpAwgqll4W4TPSjVIFdG72MzhY4T2u7xS_Ql7OY-xlkfTR1HIoZ7-U8UhfqDsj62JIu98ESf_CfncvWougxT8JKm0ik=@emersion.fr> (raw)
In-Reply-To: <YK91kB0ikqxurHN1@phenom.ffwll.local>
On Thursday, May 27th, 2021 at 12:33 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > The sync_file is also import/exportable to a certain drm_syncobj timeline
> > point (or as binary signal). So no big deal, we are all compatible here :)
> > I just thought that it might be more appropriate to return a drm_syncobj
> > directly instead of a sync_file.
>
> I think another big potential user for this is a vk-based compositor which
> needs to interact/support implicit synced clients. And compositor world I
> think is right now still more sync_file (because that's where we started
> with atomic kms ioctl).
Yeah, right now compositors can only deal with sync_file. I have a
Vulkan pull request for wlroots [1] that would benefit from this, I
think.
Also it seems like drm_syncobj isn't necessarily going to be the the
sync primitive that ends them all with all that user-space fence
discussion, so long-term I guess we'll need a conversion anyways.
[1]: https://github.com/swaywm/wlroots/pull/2771
> Plus you can convert them to the other form anyway, so really doesn't
> matter much. But for the above reasons I'm leaning slightly towards
> sync_file. Except if compositor folks tell me I'm a fool and why :-)
sync_file is fine from my PoV.
next prev parent reply other threads:[~2021-05-27 10:49 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-25 21:17 [Intel-gfx] [PATCH 0/7] dma-buf: Add an API for exporting sync files (v11) Jason Ekstrand
2021-05-25 21:17 ` Jason Ekstrand
2021-05-25 21:17 ` [Intel-gfx] [PATCH 1/7] dma-buf: Add dma_fence_array_for_each (v2) Jason Ekstrand
2021-05-25 21:17 ` Jason Ekstrand
2021-05-25 21:17 ` [Intel-gfx] [PATCH 2/7] dma-buf: Rename dma_resv helpers from _rcu to _unlocked (v2) Jason Ekstrand
2021-05-25 21:17 ` Jason Ekstrand
2021-05-26 10:57 ` [Intel-gfx] " Christian König
2021-05-26 10:57 ` Christian König
2021-05-27 10:39 ` [Intel-gfx] " Daniel Vetter
2021-05-27 10:39 ` Daniel Vetter
2021-05-27 11:58 ` [Intel-gfx] " Christian König
2021-05-27 11:58 ` Christian König
2021-05-27 13:21 ` [Intel-gfx] " Daniel Vetter
2021-05-27 13:21 ` Daniel Vetter
2021-05-27 13:25 ` [Intel-gfx] " Daniel Vetter
2021-05-27 13:25 ` Daniel Vetter
2021-05-27 13:41 ` [Intel-gfx] " Christian König
2021-05-27 13:41 ` Christian König
2021-06-01 14:34 ` [Intel-gfx] " Daniel Vetter
2021-06-01 14:34 ` Daniel Vetter
2021-06-01 17:27 ` [Intel-gfx] " Christian König
2021-06-01 17:27 ` Christian König
2021-06-01 17:29 ` [Intel-gfx] " Christian König
2021-06-01 17:29 ` Christian König
2021-05-25 21:17 ` [PATCH 3/7] dma-buf: Add dma_resv_get_singleton_unlocked (v5) Jason Ekstrand
2021-05-25 21:17 ` [Intel-gfx] " Jason Ekstrand
2021-05-25 21:17 ` [PATCH 4/7] dma-buf: Document DMA_BUF_IOCTL_SYNC Jason Ekstrand
2021-05-25 21:17 ` [Intel-gfx] " Jason Ekstrand
2021-05-27 10:38 ` Daniel Vetter
2021-05-27 10:38 ` Daniel Vetter
2021-05-27 11:12 ` [Intel-gfx] " Sumit Semwal
2021-05-27 11:12 ` Sumit Semwal
2021-06-10 20:57 ` [Intel-gfx] " Jason Ekstrand
2021-06-10 20:57 ` Jason Ekstrand
2021-05-25 21:17 ` [PATCH 5/7] dma-buf: Add an API for exporting sync files (v11) Jason Ekstrand
2021-05-25 21:17 ` [Intel-gfx] " Jason Ekstrand
2021-05-26 11:02 ` Christian König
2021-05-26 11:02 ` Christian König
2021-05-26 11:31 ` [Intel-gfx] " Daniel Stone
2021-05-26 11:31 ` Daniel Stone
2021-05-26 12:46 ` Christian König
2021-05-26 12:46 ` Christian König
2021-05-26 13:12 ` Daniel Stone
2021-05-26 13:12 ` Daniel Stone
2021-05-26 13:23 ` Christian König
2021-05-26 13:23 ` Christian König
2021-05-27 10:33 ` Daniel Vetter
2021-05-27 10:33 ` Daniel Vetter
2021-05-27 10:48 ` Simon Ser [this message]
2021-05-27 10:48 ` Simon Ser
2021-05-27 12:01 ` Christian König
2021-05-27 12:01 ` Christian König
[not found] ` <CAOFGe95Zdn8P3=sOT0HkE9_+ac70g36LxpmLOyR2bKTTeS-xvQ@mail.gmail.com>
[not found] ` <fef50d81-399a-af09-1d13-de4db1b3fab8@amd.com>
2021-05-27 15:39 ` Jason Ekstrand
2021-05-27 15:39 ` Jason Ekstrand
2021-05-25 21:17 ` [PATCH 6/7] RFC: dma-buf: Add an extra fence to dma_resv_get_singleton_unlocked Jason Ekstrand
2021-05-25 21:17 ` [Intel-gfx] " Jason Ekstrand
2021-05-25 21:17 ` [PATCH 7/7] RFC: dma-buf: Add an API for importing sync files (v7) Jason Ekstrand
2021-05-25 21:17 ` [Intel-gfx] " Jason Ekstrand
2021-05-26 17:09 ` Daniel Vetter
2021-05-26 17:09 ` Daniel Vetter
2021-05-25 21:44 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma-buf: Add an API for exporting sync files (v11) Patchwork
2021-05-25 21:46 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-05-25 22:14 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-05-26 4:20 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-06-10 20:10 ` [Intel-gfx] [PATCH 0/7] " Chia-I Wu
2021-06-10 20:10 ` Chia-I Wu
2021-06-10 20:26 ` [Intel-gfx] " Jason Ekstrand
2021-06-10 20:26 ` Jason Ekstrand
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='UhXviIJwnJG8qWOGYpAwgqll4W4TPSjVIFdG72MzhY4T2u7xS_Ql7OY-xlkfTR1HIoZ7-U8UhfqDsj62JIu98ESf_CfncvWougxT8JKm0ik=@emersion.fr' \
--to=contact@emersion.fr \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--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.