From: "Christian König" <christian.koenig@amd.com> To: Daniel Stone <daniel@fooishbar.org>, Simon Ser <contact@emersion.fr> Cc: "Daniel Vetter" <daniel@ffwll.ch>, tvrtko.ursulin@linux.intel.com, daniels@collabora.com, "Michel Dänzer" <michel.daenzer@mailbox.org>, gustavo@padovan.org, Felix.Kuehling@amd.com, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, sergemetral@google.com, tzimmermann@suse.de, alexander.deucher@amd.com, skhawaja@google.com, sumit.semwal@linaro.org, jason@jlekstrand.net, maad.aldabagh@amd.com Subject: Re: Tackling the indefinite/user DMA fence problem Date: Wed, 25 May 2022 16:22:48 +0200 [thread overview] Message-ID: <bae1a848-a089-6207-af07-8606c7bb6519@amd.com> (raw) In-Reply-To: <CAPj87rPW=YW8OnRyByJ_-6k3M9Oo7m7cTg88F8AF4TfudAjAJA@mail.gmail.com> Am 25.05.22 um 16:15 schrieb Daniel Stone: > Hi, > > On Wed, 25 May 2022 at 15:07, Simon Ser <contact@emersion.fr> wrote: >> On Wednesday, May 25th, 2022 at 15:51, Daniel Vetter <daniel@ffwll.ch> wrote: >>>> You can add that to the list of reasons why compositors need to stop >>>> using buffers with unsignaled fences. There's plenty of other reasons >>>> there already (the big one being that otherwise slow clients can slow >>>> down the compositor, even if the compositor uses a high priority context >>>> and the HW supports preemption). >>> >>> Yeah that's tbh another reason why I think we shouldn't do umf as a >>> transparent thing - compositors need to get better anyway, so we might as >>> well take this as a chance to do this right. >> As a compositor dev, I agree -- we should definitely be smarter about >> this. Note, it would help a lot to have a good way to integrate the >> waits into a poll(2) event loop. > The same holds for Weston. We're currently working through a bunch of > internal infrastructure to be able to handle this. Mutter (aka GNOME) > is also really well-placed to be able to do this. > > Having pollable waits would be really useful, but I don't think it's > essential. In my strawman I'm just waking up at the usual > just-before-repaint point and checking; if it doesn't make it for this > frame then we'll wait for the next frame. If someone submits buffers > which take 4 repaint periods to clear then we'll have 3 'unnecessary' > wakeups, but given the GPU is already slammed then it's not an > efficiency problem I don't think. (I don't know if all the other > compositor people share this view.) Oh, well you should already have pollable waits, at least on DMA-buf. If you are saying you want to have that for drm_syncobj timelines as well then that's certainly something we could do. Regards, Christian. > > Cheers, > Daniel
WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com> To: Daniel Stone <daniel@fooishbar.org>, Simon Ser <contact@emersion.fr> Cc: tvrtko.ursulin@linux.intel.com, daniels@collabora.com, tzimmermann@suse.de, "Michel Dänzer" <michel.daenzer@mailbox.org>, gustavo@padovan.org, Felix.Kuehling@amd.com, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, sergemetral@google.com, maad.aldabagh@amd.com, alexander.deucher@amd.com, skhawaja@google.com, sumit.semwal@linaro.org, jason@jlekstrand.net, linux-media@vger.kernel.org Subject: Re: Tackling the indefinite/user DMA fence problem Date: Wed, 25 May 2022 16:22:48 +0200 [thread overview] Message-ID: <bae1a848-a089-6207-af07-8606c7bb6519@amd.com> (raw) In-Reply-To: <CAPj87rPW=YW8OnRyByJ_-6k3M9Oo7m7cTg88F8AF4TfudAjAJA@mail.gmail.com> Am 25.05.22 um 16:15 schrieb Daniel Stone: > Hi, > > On Wed, 25 May 2022 at 15:07, Simon Ser <contact@emersion.fr> wrote: >> On Wednesday, May 25th, 2022 at 15:51, Daniel Vetter <daniel@ffwll.ch> wrote: >>>> You can add that to the list of reasons why compositors need to stop >>>> using buffers with unsignaled fences. There's plenty of other reasons >>>> there already (the big one being that otherwise slow clients can slow >>>> down the compositor, even if the compositor uses a high priority context >>>> and the HW supports preemption). >>> >>> Yeah that's tbh another reason why I think we shouldn't do umf as a >>> transparent thing - compositors need to get better anyway, so we might as >>> well take this as a chance to do this right. >> As a compositor dev, I agree -- we should definitely be smarter about >> this. Note, it would help a lot to have a good way to integrate the >> waits into a poll(2) event loop. > The same holds for Weston. We're currently working through a bunch of > internal infrastructure to be able to handle this. Mutter (aka GNOME) > is also really well-placed to be able to do this. > > Having pollable waits would be really useful, but I don't think it's > essential. In my strawman I'm just waking up at the usual > just-before-repaint point and checking; if it doesn't make it for this > frame then we'll wait for the next frame. If someone submits buffers > which take 4 repaint periods to clear then we'll have 3 'unnecessary' > wakeups, but given the GPU is already slammed then it's not an > efficiency problem I don't think. (I don't know if all the other > compositor people share this view.) Oh, well you should already have pollable waits, at least on DMA-buf. If you are saying you want to have that for drm_syncobj timelines as well then that's certainly something we could do. Regards, Christian. > > Cheers, > Daniel
next prev parent reply other threads:[~2022-05-25 14:23 UTC|newest] Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-02 16:37 Tackling the indefinite/user DMA fence problem Christian König 2022-05-02 16:37 ` [PATCH 01/15] dma-buf: rename DMA_FENCE_FLAG_USER_BITS to _DEVICE Christian König 2022-05-02 16:37 ` [PATCH 02/15] dma-buf: introduce user fence support Christian König 2022-05-04 7:53 ` Tvrtko Ursulin 2022-05-04 9:15 ` Christian König 2022-05-02 16:37 ` [PATCH 03/15] dma-buf: add user fence support to dma_fence_array Christian König 2022-05-02 16:37 ` [PATCH 04/15] dma-buf: add user fence support to dma_fence_chain Christian König 2022-05-02 16:37 ` [PATCH 05/15] dma-buf: add user fence support to dma_resv Christian König 2022-05-02 16:37 ` [PATCH 06/15] dma-buf: add user fence support to dma_fence_merge() Christian König 2022-05-02 16:37 ` [PATCH 07/15] dma-buf: add user fence utility functions Christian König 2022-05-02 16:37 ` [PATCH 08/15] dma-buf: add support for polling on user fences Christian König 2022-05-02 16:37 ` [PATCH 09/15] dma-buf/sync_file: add user fence support Christian König 2022-05-02 16:37 ` [PATCH 10/15] drm: add user fence support for atomic out fences Christian König 2022-05-02 16:37 ` [PATCH 11/15] drm: add user fence support for atomic in fences Christian König 2022-05-02 16:37 ` [PATCH 12/15] drm: add user fence support to drm_gem_plane_helper_prepare_fb Christian König 2022-05-02 16:37 ` [PATCH 13/15] drm: add user fence support to drm_syncobj Christian König 2022-05-02 16:37 ` [PATCH 14/15] drm/amdgpu: switch DM to atomic fence helpers Christian König 2022-05-02 16:37 ` Christian König 2022-05-02 16:37 ` [PATCH 15/15] drm/amdgpu: user fence proof of concept Christian König 2022-05-04 10:08 ` Tackling the indefinite/user DMA fence problem Daniel Vetter 2022-05-04 10:08 ` Daniel Vetter 2022-05-09 6:56 ` Christian König 2022-05-09 6:56 ` Christian König 2022-05-09 14:10 ` Daniel Vetter 2022-05-09 14:10 ` Daniel Vetter 2022-05-17 10:28 ` Christian König 2022-05-17 10:28 ` Christian König 2022-05-25 13:05 ` Daniel Vetter 2022-05-25 13:05 ` Daniel Vetter 2022-05-25 13:28 ` Michel Dänzer 2022-05-25 13:28 ` Michel Dänzer 2022-05-25 13:51 ` Daniel Vetter 2022-05-25 13:51 ` Daniel Vetter 2022-05-25 14:07 ` Simon Ser 2022-05-25 14:07 ` Simon Ser 2022-05-25 14:15 ` Daniel Stone 2022-05-25 14:15 ` Daniel Stone 2022-05-25 14:22 ` Christian König [this message] 2022-05-25 14:22 ` Christian König 2022-05-25 14:25 ` Daniel Vetter 2022-05-25 14:25 ` Daniel Vetter
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=bae1a848-a089-6207-af07-8606c7bb6519@amd.com \ --to=christian.koenig@amd.com \ --cc=Felix.Kuehling@amd.com \ --cc=alexander.deucher@amd.com \ --cc=contact@emersion.fr \ --cc=daniel@ffwll.ch \ --cc=daniel@fooishbar.org \ --cc=daniels@collabora.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=gustavo@padovan.org \ --cc=jason@jlekstrand.net \ --cc=linaro-mm-sig@lists.linaro.org \ --cc=linux-media@vger.kernel.org \ --cc=maad.aldabagh@amd.com \ --cc=michel.daenzer@mailbox.org \ --cc=sergemetral@google.com \ --cc=skhawaja@google.com \ --cc=sumit.semwal@linaro.org \ --cc=tvrtko.ursulin@linux.intel.com \ --cc=tzimmermann@suse.de \ /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.