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
next prev parent reply other threads:[~2020-03-19 10:34 UTC|newest]
Thread overview: 54+ 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 19:21 ` Jason Ekstrand
2020-03-11 20:18 ` Nicolas Dufresne
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:34 ` Tomek Bury
2020-03-16 14:19 ` Daniel Stone
2020-03-16 15:33 ` Tomek Bury
2020-03-16 16:03 ` Tomek Bury
2020-03-16 16:04 ` Jason Ekstrand
2020-03-17 8:01 ` Simon Ser
2020-03-17 14:38 ` Jason Ekstrand
2020-03-16 16:04 ` Daniel Stone
2020-03-16 17:11 ` Tomek Bury
2020-03-16 15:06 ` Jason Ekstrand
2020-03-16 21:15 ` Laurent Pinchart
2020-03-16 22:02 ` Jason Ekstrand
2020-03-17 15:33 ` Nicolas Dufresne
2020-03-17 16:27 ` Jason Ekstrand
2020-03-17 17:12 ` [Mesa-dev] " Jacob Lifshay
2020-03-17 17:18 ` Jason Ekstrand
2020-03-19 10:34 ` Daniel Vetter [this message]
2020-03-17 17:21 ` Lucas Stach
2020-03-17 17:59 ` Jacob Lifshay
2020-03-17 18:14 ` Lucas Stach
2020-03-18 0:16 ` Jacob Lifshay
2020-03-18 2:08 ` Jason Ekstrand
2020-03-18 5:20 ` Jacob Lifshay
2020-03-18 6:34 ` Jason Ekstrand
2020-03-18 7:27 ` Jacob Lifshay
2020-03-18 10:05 ` Michel Dänzer
2020-03-18 13:54 ` Nicolas Dufresne
2020-03-19 10:37 ` Daniel Vetter
2020-03-19 15:45 ` Adam Jackson
2020-03-17 18:21 ` Nicolas Dufresne
2020-03-19 10:42 ` Daniel Vetter
2020-03-17 17:34 ` [Mesa-dev] " Lucas Stach
2020-03-16 23:41 ` Roman Gilg
2020-03-17 3:37 ` Jason Ekstrand
2020-03-17 7:53 ` Jonas Ådahl
2020-03-11 23:02 ` Adam Jackson
2020-03-12 15:46 ` Jason Ekstrand
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 18:33 ` Marek Olšák
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 19:54 ` Marek Olšák
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox