All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Lifshay <programmerjake@gmail.com>
To: Lucas Stach <dev@lynxeye.de>
Cc: Jason Ekstrand <jason@jlekstrand.net>,
	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>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	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>,
	linux-media@vger.kernel.org
Subject: Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
Date: Tue, 17 Mar 2020 17:16:04 -0700	[thread overview]
Message-ID: <CAC2bXD5+KwBXBo-qHWkGw+=cH_AytwS=jeDGbskXcmO0rfsREw@mail.gmail.com> (raw)
In-Reply-To: <949b8373908a9895e97981e872d6e35dcaaba632.camel@lynxeye.de>

On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach <dev@lynxeye.de> wrote:
>
> Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay:
> > I think I found a userspace-accessible way to create sync_files and
> > dma_fences that would fulfill the requirements:
> > https://github.com/torvalds/linux/blob/master/drivers/dma-buf/sw_sync.c
> >
> > I'm just not sure if that's a good interface to use, since it appears
> > to be designed only for debugging. Will have to check for additional
> > requirements of signalling an error when the process that created the
> > fence is killed.
>
> Something like that can certainly be lifted for general use if it makes
> sense. But then with a software renderer I don't really see how fences
> help you at all. With a software renderer you know exactly when the
> frame is finished and you can just defer pushing it over to the next
> pipeline element until that time. You won't gain any parallelism by
> using fences as the CPU is busy doing the rendering and will not run
> other stuff concurrently, right?

There definitely may be other hardware and/or processes that can
process some stuff concurrently with the main application, such as the
compositor and or video encoding processes (for video capture).
Additionally, from what I understand, sync_file is the standard way to
export and import explicit synchronization between processes and
between drivers on Linux, so it seems like a good idea to support it
from an interoperability standpoint even if it turns out that there
aren't any scheduling/timing benefits.

Jacob

WARNING: multiple messages have this Message-ID (diff)
From: Jacob Lifshay <programmerjake@gmail.com>
To: Lucas Stach <dev@lynxeye.de>
Cc: 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>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Jason Ekstrand <jason@jlekstrand.net>,
	ML mesa-dev <mesa-dev@lists.freedesktop.org>,
	Nicolas Dufresne <nicolas@ndufresne.ca>,
	Discussion of the development of and with GStreamer
	<gstreamer-devel@lists.freedesktop.org>
Subject: Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
Date: Tue, 17 Mar 2020 17:16:04 -0700	[thread overview]
Message-ID: <CAC2bXD5+KwBXBo-qHWkGw+=cH_AytwS=jeDGbskXcmO0rfsREw@mail.gmail.com> (raw)
In-Reply-To: <949b8373908a9895e97981e872d6e35dcaaba632.camel@lynxeye.de>

On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach <dev@lynxeye.de> wrote:
>
> Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay:
> > I think I found a userspace-accessible way to create sync_files and
> > dma_fences that would fulfill the requirements:
> > https://github.com/torvalds/linux/blob/master/drivers/dma-buf/sw_sync.c
> >
> > I'm just not sure if that's a good interface to use, since it appears
> > to be designed only for debugging. Will have to check for additional
> > requirements of signalling an error when the process that created the
> > fence is killed.
>
> Something like that can certainly be lifted for general use if it makes
> sense. But then with a software renderer I don't really see how fences
> help you at all. With a software renderer you know exactly when the
> frame is finished and you can just defer pushing it over to the next
> pipeline element until that time. You won't gain any parallelism by
> using fences as the CPU is busy doing the rendering and will not run
> other stuff concurrently, right?

There definitely may be other hardware and/or processes that can
process some stuff concurrently with the main application, such as the
compositor and or video encoding processes (for video capture).
Additionally, from what I understand, sync_file is the standard way to
export and import explicit synchronization between processes and
between drivers on Linux, so it seems like a good idea to support it
from an interoperability standpoint even if it turns out that there
aren't any scheduling/timing benefits.

Jacob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-03-18  0:16 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 [this message]
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
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='CAC2bXD5+KwBXBo-qHWkGw+=cH_AytwS=jeDGbskXcmO0rfsREw@mail.gmail.com' \
    --to=programmerjake@gmail.com \
    --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=nicolas@ndufresne.ca \
    --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.