From: Jason Ekstrand <jason@jlekstrand.net>
To: Chia-I Wu <olvaffe@gmail.com>
Cc: "Daniel Stone" <daniels@collabora.com>,
"Christian König" <christian.koenig@amd.com>,
"Michel Dänzer" <michel@daenzer.net>,
"ML dri-devel" <dri-devel@lists.freedesktop.org>,
wayland <wayland-devel@lists.freedesktop.org>,
"Bas Nieuwenhuizen" <bas@basnieuwenhuizen.nl>,
"Dave Airlie" <airlied@redhat.com>,
mesa-dev <mesa-dev@lists.freedesktop.org>,
"Intel GFX" <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 0/7] dma-buf: Add an API for exporting sync files (v11)
Date: Thu, 10 Jun 2021 15:26:21 -0500 [thread overview]
Message-ID: <CAOFGe94ObDCHSo1MybrLbhoXmYvDqUMUC_jOMnnDo-J=YUAVXA@mail.gmail.com> (raw)
In-Reply-To: <CAPaKu7Ssizz2_A8cy12G544_uCGxWuMw8v54vSusF77SwD_yiw@mail.gmail.com>
On Thu, Jun 10, 2021 at 3:11 PM Chia-I Wu <olvaffe@gmail.com> wrote:
>
> On Tue, May 25, 2021 at 2:18 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
> > Modern userspace APIs like Vulkan are built on an explicit
> > synchronization model. This doesn't always play nicely with the
> > implicit synchronization used in the kernel and assumed by X11 and
> > Wayland. The client -> compositor half of the synchronization isn't too
> > bad, at least on intel, because we can control whether or not i915
> > synchronizes on the buffer and whether or not it's considered written.
> We might have an important use case for this half, for virtio-gpu and Chrome OS.
>
> When the guest compositor acts as a proxy to connect guest apps to the
> host compositor, implicit fencing requires the guest compositor to do
> a wait before forwarding the buffer to the host compositor. With this
> patch, the guest compositor can extract the dma-fence from the buffer,
> and if the fence is a virtio-gpu fence, forward both the fence and the
> buffer to the host compositor. It will allow us to convert a
> guest-side wait into a host-side wait.
Yeah, I think the first half solves a lot of problems. I'm rebasing
it now and will send a v12 series shortly. I don't think there's a
lot standing between the first few patches and merging. I've got IGT
tests and I'm pretty sure the code is good. The last review cycle got
distracted with some renaming fun.
--Jason
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Jason Ekstrand <jason@jlekstrand.net>
To: Chia-I Wu <olvaffe@gmail.com>
Cc: "Daniel Stone" <daniels@collabora.com>,
"Christian König" <christian.koenig@amd.com>,
"Michel Dänzer" <michel@daenzer.net>,
"ML dri-devel" <dri-devel@lists.freedesktop.org>,
wayland <wayland-devel@lists.freedesktop.org>,
"Dave Airlie" <airlied@redhat.com>,
mesa-dev <mesa-dev@lists.freedesktop.org>,
"Intel GFX" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 0/7] dma-buf: Add an API for exporting sync files (v11)
Date: Thu, 10 Jun 2021 15:26:21 -0500 [thread overview]
Message-ID: <CAOFGe94ObDCHSo1MybrLbhoXmYvDqUMUC_jOMnnDo-J=YUAVXA@mail.gmail.com> (raw)
In-Reply-To: <CAPaKu7Ssizz2_A8cy12G544_uCGxWuMw8v54vSusF77SwD_yiw@mail.gmail.com>
On Thu, Jun 10, 2021 at 3:11 PM Chia-I Wu <olvaffe@gmail.com> wrote:
>
> On Tue, May 25, 2021 at 2:18 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
> > Modern userspace APIs like Vulkan are built on an explicit
> > synchronization model. This doesn't always play nicely with the
> > implicit synchronization used in the kernel and assumed by X11 and
> > Wayland. The client -> compositor half of the synchronization isn't too
> > bad, at least on intel, because we can control whether or not i915
> > synchronizes on the buffer and whether or not it's considered written.
> We might have an important use case for this half, for virtio-gpu and Chrome OS.
>
> When the guest compositor acts as a proxy to connect guest apps to the
> host compositor, implicit fencing requires the guest compositor to do
> a wait before forwarding the buffer to the host compositor. With this
> patch, the guest compositor can extract the dma-fence from the buffer,
> and if the fence is a virtio-gpu fence, forward both the fence and the
> buffer to the host compositor. It will allow us to convert a
> guest-side wait into a host-side wait.
Yeah, I think the first half solves a lot of problems. I'm rebasing
it now and will send a v12 series shortly. I don't think there's a
lot standing between the first few patches and merging. I've got IGT
tests and I'm pretty sure the code is good. The last review cycle got
distracted with some renaming fun.
--Jason
next prev parent reply other threads:[~2021-06-10 20:26 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-25 21:17 [Intel-gfx] [PATCH 0/7] dma-buf: Add an API for exporting sync files (v11) Jason Ekstrand
2021-05-25 21:17 ` Jason Ekstrand
2021-05-25 21:17 ` [Intel-gfx] [PATCH 1/7] dma-buf: Add dma_fence_array_for_each (v2) Jason Ekstrand
2021-05-25 21:17 ` Jason Ekstrand
2021-05-25 21:17 ` [Intel-gfx] [PATCH 2/7] dma-buf: Rename dma_resv helpers from _rcu to _unlocked (v2) Jason Ekstrand
2021-05-25 21:17 ` Jason Ekstrand
2021-05-26 10:57 ` [Intel-gfx] " Christian König
2021-05-26 10:57 ` Christian König
2021-05-27 10:39 ` [Intel-gfx] " Daniel Vetter
2021-05-27 10:39 ` Daniel Vetter
2021-05-27 11:58 ` [Intel-gfx] " Christian König
2021-05-27 11:58 ` Christian König
2021-05-27 13:21 ` [Intel-gfx] " Daniel Vetter
2021-05-27 13:21 ` Daniel Vetter
2021-05-27 13:25 ` [Intel-gfx] " Daniel Vetter
2021-05-27 13:25 ` Daniel Vetter
2021-05-27 13:41 ` [Intel-gfx] " Christian König
2021-05-27 13:41 ` Christian König
2021-06-01 14:34 ` [Intel-gfx] " Daniel Vetter
2021-06-01 14:34 ` Daniel Vetter
2021-06-01 17:27 ` [Intel-gfx] " Christian König
2021-06-01 17:27 ` Christian König
2021-06-01 17:29 ` [Intel-gfx] " Christian König
2021-06-01 17:29 ` Christian König
2021-05-25 21:17 ` [PATCH 3/7] dma-buf: Add dma_resv_get_singleton_unlocked (v5) Jason Ekstrand
2021-05-25 21:17 ` [Intel-gfx] " Jason Ekstrand
2021-05-25 21:17 ` [PATCH 4/7] dma-buf: Document DMA_BUF_IOCTL_SYNC Jason Ekstrand
2021-05-25 21:17 ` [Intel-gfx] " Jason Ekstrand
2021-05-27 10:38 ` Daniel Vetter
2021-05-27 10:38 ` Daniel Vetter
2021-05-27 11:12 ` [Intel-gfx] " Sumit Semwal
2021-05-27 11:12 ` Sumit Semwal
2021-06-10 20:57 ` [Intel-gfx] " Jason Ekstrand
2021-06-10 20:57 ` Jason Ekstrand
2021-05-25 21:17 ` [PATCH 5/7] dma-buf: Add an API for exporting sync files (v11) Jason Ekstrand
2021-05-25 21:17 ` [Intel-gfx] " Jason Ekstrand
2021-05-26 11:02 ` Christian König
2021-05-26 11:02 ` Christian König
2021-05-26 11:31 ` [Intel-gfx] " Daniel Stone
2021-05-26 11:31 ` Daniel Stone
2021-05-26 12:46 ` Christian König
2021-05-26 12:46 ` Christian König
2021-05-26 13:12 ` Daniel Stone
2021-05-26 13:12 ` Daniel Stone
2021-05-26 13:23 ` Christian König
2021-05-26 13:23 ` Christian König
2021-05-27 10:33 ` Daniel Vetter
2021-05-27 10:33 ` Daniel Vetter
2021-05-27 10:48 ` Simon Ser
2021-05-27 10:48 ` Simon Ser
2021-05-27 12:01 ` Christian König
2021-05-27 12:01 ` Christian König
[not found] ` <CAOFGe95Zdn8P3=sOT0HkE9_+ac70g36LxpmLOyR2bKTTeS-xvQ@mail.gmail.com>
[not found] ` <fef50d81-399a-af09-1d13-de4db1b3fab8@amd.com>
2021-05-27 15:39 ` Jason Ekstrand
2021-05-27 15:39 ` Jason Ekstrand
2021-05-25 21:17 ` [PATCH 6/7] RFC: dma-buf: Add an extra fence to dma_resv_get_singleton_unlocked Jason Ekstrand
2021-05-25 21:17 ` [Intel-gfx] " Jason Ekstrand
2021-05-25 21:17 ` [PATCH 7/7] RFC: dma-buf: Add an API for importing sync files (v7) Jason Ekstrand
2021-05-25 21:17 ` [Intel-gfx] " Jason Ekstrand
2021-05-26 17:09 ` Daniel Vetter
2021-05-26 17:09 ` Daniel Vetter
2021-05-25 21:44 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma-buf: Add an API for exporting sync files (v11) Patchwork
2021-05-25 21:46 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-05-25 22:14 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-05-26 4:20 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-06-10 20:10 ` [Intel-gfx] [PATCH 0/7] " Chia-I Wu
2021-06-10 20:10 ` Chia-I Wu
2021-06-10 20:26 ` Jason Ekstrand [this message]
2021-06-10 20:26 ` Jason Ekstrand
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='CAOFGe94ObDCHSo1MybrLbhoXmYvDqUMUC_jOMnnDo-J=YUAVXA@mail.gmail.com' \
--to=jason@jlekstrand.net \
--cc=airlied@redhat.com \
--cc=bas@basnieuwenhuizen.nl \
--cc=christian.koenig@amd.com \
--cc=daniels@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=mesa-dev@lists.freedesktop.org \
--cc=michel@daenzer.net \
--cc=olvaffe@gmail.com \
--cc=wayland-devel@lists.freedesktop.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.