All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Jason Ekstrand <jason@jlekstrand.net>
Cc: Jacob Lifshay <programmerjake@gmail.com>,
	Nicolas Dufresne <nicolas@ndufresne.ca>,
	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>,
	ML mesa-dev <mesa-dev@lists.freedesktop.org>,
	"open list:DMA BUFFER SHARING FRAMEWORK" 
	<linux-media@vger.kernel.org>,
	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: Thu, 19 Mar 2020 11:34:39 +0100	[thread overview]
Message-ID: <20200319103439.GC2363188@phenom.ffwll.local> (raw)
In-Reply-To: <CAOFGe94vX5CMyjs8jehXj3f7t9yu__=-N+etNz5eY7sqwqb-jA@mail.gmail.com>

On Tue, Mar 17, 2020 at 12:18:47PM -0500, Jason Ekstrand wrote:
> On Tue, Mar 17, 2020 at 12:13 PM Jacob Lifshay <programmerjake@gmail.com> wrote:
> >
> > One related issue with explicit sync using sync_file is that combined
> > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> > rendering in userspace (like llvmpipe but for Vulkan and with extra
> > instructions for GPU tasks) but need to synchronize with other
> > drivers/processes is that there should be some way to create an
> > explicit fence/semaphore from userspace and later signal it. This
> > seems to conflict with the requirement for a sync_file to complete in
> > finite time, since the user process could be stopped or killed.
> 
> Yeah... That's going to be a problem.  The only way I could see that
> working is if you created a sync_file that had a timeout associated
> with it.  However, then you run into the issue where you may have
> corruption if stuff doesn't complete on time.  Then again, you're not
> really dealing with an external unit and so the latency cost of going
> across the window system protocol probably isn't massively different
> from the latency cost of triggering the sync_file.  Maybe the answer
> there is to just do everything in-order and not worry about
> synchronization?

vgem does that already (fences with timeout). The corruption issue is also
not new, if your shaders take forever real gpus will nick your rendering
with a quick reset. Iirc someone (from cros google team maybe) was even
looking into making llvmpipe run on top of vgem as a real dri/drm mesa
driver.
-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: Jason Ekstrand <jason@jlekstrand.net>
Cc: 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>,
	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>,
	"open list:DMA BUFFER SHARING FRAMEWORK"
	<linux-media@vger.kernel.org>
Subject: Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
Date: Thu, 19 Mar 2020 11:34:39 +0100	[thread overview]
Message-ID: <20200319103439.GC2363188@phenom.ffwll.local> (raw)
In-Reply-To: <CAOFGe94vX5CMyjs8jehXj3f7t9yu__=-N+etNz5eY7sqwqb-jA@mail.gmail.com>

On Tue, Mar 17, 2020 at 12:18:47PM -0500, Jason Ekstrand wrote:
> On Tue, Mar 17, 2020 at 12:13 PM Jacob Lifshay <programmerjake@gmail.com> wrote:
> >
> > One related issue with explicit sync using sync_file is that combined
> > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> > rendering in userspace (like llvmpipe but for Vulkan and with extra
> > instructions for GPU tasks) but need to synchronize with other
> > drivers/processes is that there should be some way to create an
> > explicit fence/semaphore from userspace and later signal it. This
> > seems to conflict with the requirement for a sync_file to complete in
> > finite time, since the user process could be stopped or killed.
> 
> Yeah... That's going to be a problem.  The only way I could see that
> working is if you created a sync_file that had a timeout associated
> with it.  However, then you run into the issue where you may have
> corruption if stuff doesn't complete on time.  Then again, you're not
> really dealing with an external unit and so the latency cost of going
> across the window system protocol probably isn't massively different
> from the latency cost of triggering the sync_file.  Maybe the answer
> there is to just do everything in-order and not worry about
> synchronization?

vgem does that already (fences with timeout). The corruption issue is also
not new, if your shaders take forever real gpus will nick your rendering
with a quick reset. Iirc someone (from cros google team maybe) was even
looking into making llvmpipe run on top of vgem as a real dri/drm mesa
driver.
-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

  reply	other threads:[~2020-03-19 10:34 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 [this message]
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
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=20200319103439.GC2363188@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=daniel.vetter@ffwll.ch \
    --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=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.