From: "Christian König" <christian.koenig@amd.com> To: Daniel Stone <daniel@fooishbar.org> 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:46:17 +0200 [thread overview] Message-ID: <770eb698-1dde-9e46-da83-44911d96abec@amd.com> (raw) In-Reply-To: <CAPj87rN_7vmmWcL1vqhvM=etaTjwts_L0vYbsgvYF0_qZw83gw@mail.gmail.com> Am 26.05.21 um 13:31 schrieb Daniel Stone: > Hi Christian, > > On Wed, 26 May 2021 at 12:02, Christian König <christian.koenig@amd.com> wrote: >> Am 25.05.21 um 23:17 schrieb Jason Ekstrand: >>> This new IOCTL solves this problem by allowing us to get a snapshot of >>> the implicit synchronization state of a given dma-buf in the form of a >>> sync file. It's effectively the same as a poll() or I915_GEM_WAIT only, >>> instead of CPU waiting directly, it encapsulates the wait operation, at >>> the current moment in time, in a sync_file so we can check/wait on it >>> later. As long as the Vulkan driver does the sync_file export from the >>> dma-buf before we re-introduce it for rendering, it will only contain >>> fences from the compositor or display. This allows to accurately turn >>> it into a VkFence or VkSemaphore without any over- synchronization. >> Regarding that, why do we actually use a syncfile and not a drm_syncobj >> here? >> >> The later should be much closer to a Vulkan timeline semaphore. > 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? Christian. > > 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: "Christian König" <christian.koenig@amd.com> To: Daniel Stone <daniel@fooishbar.org> 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:46:17 +0200 [thread overview] Message-ID: <770eb698-1dde-9e46-da83-44911d96abec@amd.com> (raw) In-Reply-To: <CAPj87rN_7vmmWcL1vqhvM=etaTjwts_L0vYbsgvYF0_qZw83gw@mail.gmail.com> Am 26.05.21 um 13:31 schrieb Daniel Stone: > Hi Christian, > > On Wed, 26 May 2021 at 12:02, Christian König <christian.koenig@amd.com> wrote: >> Am 25.05.21 um 23:17 schrieb Jason Ekstrand: >>> This new IOCTL solves this problem by allowing us to get a snapshot of >>> the implicit synchronization state of a given dma-buf in the form of a >>> sync file. It's effectively the same as a poll() or I915_GEM_WAIT only, >>> instead of CPU waiting directly, it encapsulates the wait operation, at >>> the current moment in time, in a sync_file so we can check/wait on it >>> later. As long as the Vulkan driver does the sync_file export from the >>> dma-buf before we re-introduce it for rendering, it will only contain >>> fences from the compositor or display. This allows to accurately turn >>> it into a VkFence or VkSemaphore without any over- synchronization. >> Regarding that, why do we actually use a syncfile and not a drm_syncobj >> here? >> >> The later should be much closer to a Vulkan timeline semaphore. > 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? Christian. > > Cheers, > Daniel
next prev parent reply other threads:[~2021-05-26 12:46 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 [this message] 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 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=770eb698-1dde-9e46-da83-44911d96abec@amd.com \ --to=christian.koenig@amd.com \ --cc=contact@emersion.fr \ --cc=daniel.vetter@ffwll.ch \ --cc=daniel@fooishbar.org \ --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: 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.