From: Daniel Stone <daniel@fooishbar.org>
To: "Christian König" <christian.koenig@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Simon Ser <contact@emersion.fr>,
Sumit Semwal <sumit.semwal@linaro.org>
Subject: Re: [Intel-gfx] [PATCH 5/7] dma-buf: Add an API for exporting sync files (v11)
Date: Wed, 26 May 2021 14:12:11 +0100 [thread overview]
Message-ID: <CAPj87rPdMthO2Wv7QxMGnO__BiZVauMa9HaRk+35Sgvm69QSjw@mail.gmail.com> (raw)
In-Reply-To: <770eb698-1dde-9e46-da83-44911d96abec@amd.com>
Hi,
On Wed, 26 May 2021 at 13:46, Christian König <christian.koenig@amd.com> wrote:
> Am 26.05.21 um 13:31 schrieb Daniel Stone:
> > How would we insert a syncobj+val into a resv though? Like, if we pass
> > an unmaterialised syncobj+val here to insert into the resv, then an
> > implicit-only media user (or KMS) goes to sync against the resv, what
> > happens?
>
> Well this is for exporting, not importing. So we don't need to worry
> about that.
>
> It's just my thinking because the drm_syncobj is the backing object on
> VkSemaphore implementations these days, isn't it?
Yeah, I can see that to an extent. But then binary vs. timeline
syncobjs are very different in use (which is unfortunate tbh), and
then we have an asymmetry between syncobj export & sync_file import.
You're right that we do want a syncobj though. This is probably not
practical due to smashing uAPI to bits, but if we could wind the clock
back a couple of years, I suspect the interface we want is that export
can either export a sync_file or a binary syncobj, and further that
binary syncobjs could transparently act as timeline semaphores by
mapping any value (either wait or signal) to the binary signal. In
hindsight, we should probably just never have had binary syncobj. Oh
well.
Cheers,
Daniel
_______________________________________________
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: Daniel Stone <daniel@fooishbar.org>
To: "Christian König" <christian.koenig@amd.com>
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>
Subject: Re: [Intel-gfx] [PATCH 5/7] dma-buf: Add an API for exporting sync files (v11)
Date: Wed, 26 May 2021 14:12:11 +0100 [thread overview]
Message-ID: <CAPj87rPdMthO2Wv7QxMGnO__BiZVauMa9HaRk+35Sgvm69QSjw@mail.gmail.com> (raw)
In-Reply-To: <770eb698-1dde-9e46-da83-44911d96abec@amd.com>
Hi,
On Wed, 26 May 2021 at 13:46, Christian König <christian.koenig@amd.com> wrote:
> Am 26.05.21 um 13:31 schrieb Daniel Stone:
> > How would we insert a syncobj+val into a resv though? Like, if we pass
> > an unmaterialised syncobj+val here to insert into the resv, then an
> > implicit-only media user (or KMS) goes to sync against the resv, what
> > happens?
>
> Well this is for exporting, not importing. So we don't need to worry
> about that.
>
> It's just my thinking because the drm_syncobj is the backing object on
> VkSemaphore implementations these days, isn't it?
Yeah, I can see that to an extent. But then binary vs. timeline
syncobjs are very different in use (which is unfortunate tbh), and
then we have an asymmetry between syncobj export & sync_file import.
You're right that we do want a syncobj though. This is probably not
practical due to smashing uAPI to bits, but if we could wind the clock
back a couple of years, I suspect the interface we want is that export
can either export a sync_file or a binary syncobj, and further that
binary syncobjs could transparently act as timeline semaphores by
mapping any value (either wait or signal) to the binary signal. In
hindsight, we should probably just never have had binary syncobj. Oh
well.
Cheers,
Daniel
next prev parent reply other threads:[~2021-05-26 13:12 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 [this message]
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
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=CAPj87rPdMthO2Wv7QxMGnO__BiZVauMa9HaRk+35Sgvm69QSjw@mail.gmail.com \
--to=daniel@fooishbar.org \
--cc=christian.koenig@amd.com \
--cc=contact@emersion.fr \
--cc=daniel.vetter@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.