From: Daniel Vetter <daniel@ffwll.ch>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: Lucas Stach <dev@lynxeye.de>,
Jacob Lifshay <programmerjake@gmail.com>,
Jason Ekstrand <jason@jlekstrand.net>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
xorg-devel <xorg-devel@lists.x.org>,
linux-media@vger.kernel.org,
Maling list - DRI developers <dri-devel@lists.freedesktop.org>,
"wayland-devel @ lists . freedesktop . org"
<wayland-devel@lists.freedesktop.org>,
Discussion of the development of and with GStreamer
<gstreamer-devel@lists.freedesktop.org>,
ML mesa-dev <mesa-dev@lists.freedesktop.org>,
Nicolas Dufresne <nicolas@ndufresne.ca>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
Date: Thu, 19 Mar 2020 11:37:35 +0100 [thread overview]
Message-ID: <20200319103735.GD2363188@phenom.ffwll.local> (raw)
In-Reply-To: <14115064-24e5-da2c-38c6-f3ba0d447b18@daenzer.net>
On Wed, Mar 18, 2020 at 11:05:48AM +0100, Michel Dänzer wrote:
> On 2020-03-17 6:21 p.m., Lucas Stach wrote:
> > That's one of the issues with implicit sync that explicit may solve:
> > a single client taking way too much time to render something can
> > block the whole pipeline up until the display flip. With explicit
> > sync the compositor can just decide to use the last client buffer if
> > the latest buffer isn't ready by some deadline.
>
> FWIW, the compositor can do this with implicit sync as well, by polling
> a dma-buf fd for the buffer. (Currently, it has to poll for writable,
> because waiting for the exclusive fence only isn't enough with amdgpu)
Would be great if we don't have to make this recommended uapi, just
because amdgpu leaks it's trickery into the wider world. Polling for read
really should be enough (and I guess Christian gets to fix up amdgpu more,
at least for anything that has a dma-buf attached even if it's not shared
with anything !amdgpu.ko).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Jacob Lifshay <programmerjake@gmail.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
xorg-devel <xorg-devel@lists.x.org>,
Maling list - DRI developers <dri-devel@lists.freedesktop.org>,
"wayland-devel @ lists . freedesktop . org"
<wayland-devel@lists.freedesktop.org>,
Discussion of the development of and with GStreamer
<gstreamer-devel@lists.freedesktop.org>,
Jason Ekstrand <jason@jlekstrand.net>,
ML mesa-dev <mesa-dev@lists.freedesktop.org>,
Nicolas Dufresne <nicolas@ndufresne.ca>,
linux-media@vger.kernel.org
Subject: Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
Date: Thu, 19 Mar 2020 11:37:35 +0100 [thread overview]
Message-ID: <20200319103735.GD2363188@phenom.ffwll.local> (raw)
In-Reply-To: <14115064-24e5-da2c-38c6-f3ba0d447b18@daenzer.net>
On Wed, Mar 18, 2020 at 11:05:48AM +0100, Michel Dänzer wrote:
> On 2020-03-17 6:21 p.m., Lucas Stach wrote:
> > That's one of the issues with implicit sync that explicit may solve:
> > a single client taking way too much time to render something can
> > block the whole pipeline up until the display flip. With explicit
> > sync the compositor can just decide to use the last client buffer if
> > the latest buffer isn't ready by some deadline.
>
> FWIW, the compositor can do this with implicit sync as well, by polling
> a dma-buf fd for the buffer. (Currently, it has to poll for writable,
> because waiting for the exclusive fence only isn't enough with amdgpu)
Would be great if we don't have to make this recommended uapi, just
because amdgpu leaks it's trickery into the wider world. Polling for read
really should be enough (and I guess Christian gets to fix up amdgpu more,
at least for anything that has a dma-buf attached even if it's not shared
with anything !amdgpu.ko).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-03-19 10:37 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-11 17:31 Plumbing explicit synchronization through the Linux ecosystem Jason Ekstrand
2020-03-11 17:31 ` Jason Ekstrand
2020-03-11 19:21 ` Jason Ekstrand
2020-03-11 19:21 ` Jason Ekstrand
2020-03-11 20:18 ` Nicolas Dufresne
2020-03-11 20:18 ` Nicolas Dufresne
2020-03-16 10:20 ` Laurent Pinchart
2020-03-16 10:20 ` Laurent Pinchart
2020-03-16 12:55 ` Tomek Bury
2020-03-16 13:01 ` Laurent Pinchart
2020-03-16 13:01 ` Laurent Pinchart
2020-03-16 13:34 ` Tomek Bury
2020-03-16 13:34 ` Tomek Bury
2020-03-16 14:19 ` Daniel Stone
2020-03-16 14:19 ` Daniel Stone
2020-03-16 15:33 ` Tomek Bury
2020-03-16 15:33 ` Tomek Bury
2020-03-16 16:03 ` Tomek Bury
2020-03-16 16:03 ` Tomek Bury
2020-03-16 16:04 ` Jason Ekstrand
2020-03-16 16:04 ` Jason Ekstrand
2020-03-17 8:01 ` Simon Ser
2020-03-17 8:01 ` Simon Ser
2020-03-17 14:38 ` Jason Ekstrand
2020-03-17 14:38 ` Jason Ekstrand
2020-03-16 16:04 ` Daniel Stone
2020-03-16 16:04 ` Daniel Stone
2020-03-16 17:11 ` Tomek Bury
2020-03-16 17:11 ` Tomek Bury
2020-03-16 15:06 ` Jason Ekstrand
2020-03-16 15:06 ` Jason Ekstrand
2020-03-16 21:15 ` Laurent Pinchart
2020-03-16 21:15 ` Laurent Pinchart
2020-03-16 22:02 ` Jason Ekstrand
2020-03-16 22:02 ` Jason Ekstrand
2020-03-17 15:33 ` Nicolas Dufresne
2020-03-17 15:33 ` Nicolas Dufresne
2020-03-17 16:27 ` Jason Ekstrand
2020-03-17 16:27 ` Jason Ekstrand
2020-03-17 17:12 ` [Mesa-dev] " Jacob Lifshay
2020-03-17 17:12 ` Jacob Lifshay
2020-03-17 17:18 ` Jason Ekstrand
2020-03-17 17:18 ` Jason Ekstrand
2020-03-19 10:34 ` Daniel Vetter
2020-03-19 10:34 ` Daniel Vetter
2020-03-17 17:21 ` Lucas Stach
2020-03-17 17:21 ` Lucas Stach
2020-03-17 17:59 ` Jacob Lifshay
2020-03-17 17:59 ` Jacob Lifshay
2020-03-17 18:14 ` Lucas Stach
2020-03-17 18:14 ` Lucas Stach
2020-03-18 0:16 ` Jacob Lifshay
2020-03-18 0:16 ` Jacob Lifshay
2020-03-18 2:08 ` Jason Ekstrand
2020-03-18 2:08 ` Jason Ekstrand
2020-03-18 5:20 ` Jacob Lifshay
2020-03-18 5:20 ` Jacob Lifshay
2020-03-18 6:34 ` Jason Ekstrand
2020-03-18 6:34 ` Jason Ekstrand
2020-03-18 7:27 ` Jacob Lifshay
2020-03-18 7:27 ` Jacob Lifshay
2020-03-18 10:05 ` Michel Dänzer
2020-03-18 10:05 ` Michel Dänzer
2020-03-18 13:54 ` Nicolas Dufresne
2020-03-18 13:54 ` Nicolas Dufresne
2020-03-19 10:37 ` Daniel Vetter [this message]
2020-03-19 10:37 ` Daniel Vetter
2020-03-19 15:45 ` Adam Jackson
2020-03-19 15:45 ` Adam Jackson
2020-03-17 18:21 ` Nicolas Dufresne
2020-03-17 18:21 ` Nicolas Dufresne
2020-03-19 10:42 ` Daniel Vetter
2020-03-19 10:42 ` Daniel Vetter
2020-03-17 17:34 ` [Mesa-dev] " Lucas Stach
2020-03-17 17:34 ` Lucas Stach
2020-03-16 23:41 ` Roman Gilg
2020-03-16 23:41 ` Roman Gilg
2020-03-17 3:37 ` Jason Ekstrand
2020-03-17 3:37 ` Jason Ekstrand
2020-03-17 7:53 ` Jonas Ådahl
2020-03-17 7:53 ` Jonas Ådahl
2020-03-11 23:02 ` Adam Jackson
2020-03-11 23:02 ` Adam Jackson
2020-03-12 15:46 ` Jason Ekstrand
2020-03-12 15:46 ` Jason Ekstrand
2020-03-13 1:37 ` Alexander E. Patrakov
2020-03-13 1:37 ` Alexander E. Patrakov
2020-03-14 2:02 ` [Mesa-dev] " Marek Olšák
2020-03-16 2:49 ` Jason Ekstrand
2020-03-16 3:50 ` Marek Olšák
2020-03-16 9:57 ` Michel Dänzer
2020-03-16 9:57 ` Michel Dänzer
2020-03-16 18:33 ` Marek Olšák
2020-03-17 10:01 ` Michel Dänzer
2020-03-17 10:01 ` Michel Dänzer
2020-03-17 17:13 ` Marek Olšák
2020-03-19 10:51 ` Daniel Vetter
2020-03-19 10:51 ` Daniel Vetter
2020-03-19 19:54 ` Marek Olšák
2020-03-20 8:50 ` Michel Dänzer
2020-03-20 8:50 ` Michel Dänzer
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=20200319103735.GD2363188@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=daniel.vetter@ffwll.ch \
--cc=dev@lynxeye.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=gstreamer-devel@lists.freedesktop.org \
--cc=jason@jlekstrand.net \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=mesa-dev@lists.freedesktop.org \
--cc=michel@daenzer.net \
--cc=nicolas@ndufresne.ca \
--cc=programmerjake@gmail.com \
--cc=wayland-devel@lists.freedesktop.org \
--cc=xorg-devel@lists.x.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.