From: Gerd Hoffmann <kraxel@redhat.com> To: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: linux-kernel@vger.kernel.org, Zach Reizner <zachr@google.com>, kernel@collabora.com, dri-devel@lists.freedesktop.org, virtualization@lists.linux-foundation.org, "Michael S. Tsirkin" <mst@redhat.com>, David Airlie <airlied@linux.ie>, Jason Wang <jasowang@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com> Subject: Re: [PATCH v3 1/2] drm/virtio: Add window server support Date: Tue, 6 Feb 2018 15:23:02 +0100 [thread overview] Message-ID: <20180206142302.vdjyqmnoypydci4t@sirius.home.kraxel.org> (raw) In-Reply-To: <fd557eb7-f539-2ecf-142c-8313b9f7ddb3@collabora.com> Hi, > > Hmm? I'm assuming the wayland client (in the guest) talks to the > > wayland proxy, using the wayland protocol, like it would talk to a > > wayland display server. Buffers must be passed from client to > > server/proxy somehow, probably using fd passing, so where is the > > problem? > > > > Or did I misunderstand the role of the proxy? > > Hi Gerd, > > it's starting to look to me that we're talking a bit past the other, so I > have pasted below a few words describing my current plan regarding the 3 key > scenarios that I'm addressing. You are describing the details, but I'm missing the big picture ... So, virtualization aside, how do buffers work in wayland? As far I know it goes like this: (a) software rendering: client allocates shared memory buffer, renders into it, then passes a file handle for that shmem block together with some meta data (size, format, ...) to the wayland server. (b) gpu rendering: client opens a render node, allocates a buffer, asks the cpu to renders into it, exports the buffer as dma-buf (DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server (again including meta data of course). Is that correct? Now, with virtualization added to the mix it becomes a bit more complicated. Client and server are unmodified. The client talks to the guest proxy (wayland protocol). The guest proxy talks to the host proxy (protocol to be defined). The host proxy talks to the server (wayland protocol). Buffers must be managed along the way, and we want avoid copying around the buffers. The host proxy could be implemented directly in qemu, or as separate process which cooperates with qemu for buffer management. Fine so far? > I really think that whatever we come up with needs to support 3D clients as > well. Lets start with 3d clients, I think these are easier. They simply use virtio-gpu for 3d rendering as usual. When they are done the rendered buffer already lives in a host drm buffer (because virgl runs the actual rendering on the host gpu). So the client passes the dma-buf to the guest proxy, the guest proxy imports it to look up the resource-id, passes the resource-id to the host proxy, the host proxy looks up the drm buffer and exports it as dma-buf, then passes it to the server. Done, without any extra data copies. > Creation of shareable buffer by guest > ------------------------------------------------- > > 1. Client requests virtio driver to create a buffer suitable for sharing > with host (DRM_VIRTGPU_RESOURCE_CREATE) client or guest proxy? > 4. QEMU maps that buffer to the guest's address space > (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver That part is problematic. The host can't simply allocate something in the physical address space, because most physical address space management is done by the guest. All pci bars are mapped by the guest firmware for example (or by the guest OS in case of hotplug). > 4. QEMU pops data+buffers from the virtqueue, looks up shmem FD for each > resource, sends data + FDs to the compositor with SCM_RIGHTS BTW: Is there a 1:1 relationship between buffers and shmem blocks? Or does the wayland protocol allow for offsets in buffer meta data, so you can place multiple buffers in a single shmem block? cheers, Gerd
WARNING: multiple messages have this Message-ID (diff)
From: Gerd Hoffmann <kraxel@redhat.com> To: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: "Michael S. Tsirkin" <mst@redhat.com>, David Airlie <airlied@linux.ie>, Stefan Hajnoczi <stefanha@gmail.com>, Jason Wang <jasowang@redhat.com>, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, virtualization@lists.linux-foundation.org, kernel@collabora.com Subject: Re: [PATCH v3 1/2] drm/virtio: Add window server support Date: Tue, 6 Feb 2018 15:23:02 +0100 [thread overview] Message-ID: <20180206142302.vdjyqmnoypydci4t@sirius.home.kraxel.org> (raw) In-Reply-To: <fd557eb7-f539-2ecf-142c-8313b9f7ddb3@collabora.com> Hi, > > Hmm? I'm assuming the wayland client (in the guest) talks to the > > wayland proxy, using the wayland protocol, like it would talk to a > > wayland display server. Buffers must be passed from client to > > server/proxy somehow, probably using fd passing, so where is the > > problem? > > > > Or did I misunderstand the role of the proxy? > > Hi Gerd, > > it's starting to look to me that we're talking a bit past the other, so I > have pasted below a few words describing my current plan regarding the 3 key > scenarios that I'm addressing. You are describing the details, but I'm missing the big picture ... So, virtualization aside, how do buffers work in wayland? As far I know it goes like this: (a) software rendering: client allocates shared memory buffer, renders into it, then passes a file handle for that shmem block together with some meta data (size, format, ...) to the wayland server. (b) gpu rendering: client opens a render node, allocates a buffer, asks the cpu to renders into it, exports the buffer as dma-buf (DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server (again including meta data of course). Is that correct? Now, with virtualization added to the mix it becomes a bit more complicated. Client and server are unmodified. The client talks to the guest proxy (wayland protocol). The guest proxy talks to the host proxy (protocol to be defined). The host proxy talks to the server (wayland protocol). Buffers must be managed along the way, and we want avoid copying around the buffers. The host proxy could be implemented directly in qemu, or as separate process which cooperates with qemu for buffer management. Fine so far? > I really think that whatever we come up with needs to support 3D clients as > well. Lets start with 3d clients, I think these are easier. They simply use virtio-gpu for 3d rendering as usual. When they are done the rendered buffer already lives in a host drm buffer (because virgl runs the actual rendering on the host gpu). So the client passes the dma-buf to the guest proxy, the guest proxy imports it to look up the resource-id, passes the resource-id to the host proxy, the host proxy looks up the drm buffer and exports it as dma-buf, then passes it to the server. Done, without any extra data copies. > Creation of shareable buffer by guest > ------------------------------------------------- > > 1. Client requests virtio driver to create a buffer suitable for sharing > with host (DRM_VIRTGPU_RESOURCE_CREATE) client or guest proxy? > 4. QEMU maps that buffer to the guest's address space > (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver That part is problematic. The host can't simply allocate something in the physical address space, because most physical address space management is done by the guest. All pci bars are mapped by the guest firmware for example (or by the guest OS in case of hotplug). > 4. QEMU pops data+buffers from the virtqueue, looks up shmem FD for each > resource, sends data + FDs to the compositor with SCM_RIGHTS BTW: Is there a 1:1 relationship between buffers and shmem blocks? Or does the wayland protocol allow for offsets in buffer meta data, so you can place multiple buffers in a single shmem block? cheers, Gerd _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-02-06 14:23 UTC|newest] Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-01-26 13:58 [PATCH v3 0/2] drm/virtio: Add window server support Tomeu Vizoso 2018-01-26 13:58 ` Tomeu Vizoso 2018-01-26 13:58 ` [PATCH v3 1/2] " Tomeu Vizoso 2018-01-26 13:58 ` Tomeu Vizoso 2018-02-01 16:36 ` Gerd Hoffmann 2018-02-01 16:36 ` Gerd Hoffmann 2018-02-05 8:19 ` Tomeu Vizoso 2018-02-05 8:19 ` Tomeu Vizoso 2018-02-05 8:19 ` Tomeu Vizoso 2018-02-05 12:20 ` Gerd Hoffmann 2018-02-05 14:46 ` Tomeu Vizoso 2018-02-05 14:46 ` Tomeu Vizoso 2018-02-05 16:03 ` Gerd Hoffmann 2018-02-05 16:03 ` Gerd Hoffmann 2018-02-06 12:41 ` Tomeu Vizoso 2018-02-06 12:41 ` Tomeu Vizoso 2018-02-06 14:23 ` Gerd Hoffmann [this message] 2018-02-06 14:23 ` Gerd Hoffmann 2018-02-07 1:09 ` Michael S. Tsirkin 2018-02-07 7:41 ` Tomeu Vizoso 2018-02-07 7:41 ` Tomeu Vizoso 2018-02-07 1:09 ` Michael S. Tsirkin 2018-02-07 9:49 ` Tomeu Vizoso 2018-02-07 9:49 ` Tomeu Vizoso 2018-02-09 11:14 ` Tomeu Vizoso 2018-02-09 11:14 ` Tomeu Vizoso 2018-02-12 11:52 ` Gerd Hoffmann 2018-02-12 11:52 ` Gerd Hoffmann 2018-02-12 14:00 ` Tomeu Vizoso 2018-02-12 14:00 ` Tomeu Vizoso 2018-02-12 14:00 ` Tomeu Vizoso 2018-02-12 14:27 ` Gerd Hoffmann 2018-02-12 14:27 ` Gerd Hoffmann 2018-02-12 14:42 ` Tomeu Vizoso 2018-02-12 14:42 ` Tomeu Vizoso 2018-02-12 15:29 ` Gerd Hoffmann 2018-02-12 15:29 ` Gerd Hoffmann 2018-02-12 15:29 ` Gerd Hoffmann 2018-02-12 14:42 ` Tomeu Vizoso 2018-02-12 11:45 ` Gerd Hoffmann 2018-02-12 11:45 ` Gerd Hoffmann 2018-02-12 11:45 ` Gerd Hoffmann 2018-02-13 7:41 ` Pekka Paalanen 2018-02-13 7:41 ` Pekka Paalanen 2018-02-13 7:41 ` Pekka Paalanen 2018-02-13 14:27 ` Tomeu Vizoso 2018-02-13 14:27 ` Tomeu Vizoso 2018-02-16 10:48 ` Gerd Hoffmann 2018-02-16 10:48 ` Gerd Hoffmann 2018-02-16 10:48 ` Gerd Hoffmann 2018-02-13 14:27 ` Tomeu Vizoso 2018-02-15 15:28 ` Tomeu Vizoso 2018-02-15 15:28 ` Tomeu Vizoso 2018-02-15 15:28 ` Tomeu Vizoso 2018-02-06 14:23 ` Gerd Hoffmann 2018-02-06 12:41 ` Tomeu Vizoso 2018-02-06 15:00 ` Pekka Paalanen 2018-02-06 15:00 ` Pekka Paalanen 2018-02-06 15:00 ` Pekka Paalanen 2018-02-05 16:03 ` Gerd Hoffmann 2018-02-05 14:46 ` Tomeu Vizoso 2018-02-05 12:20 ` Gerd Hoffmann 2019-03-18 12:47 ` Tomeu Vizoso 2019-03-18 12:47 ` Tomeu Vizoso 2019-03-18 12:47 ` Tomeu Vizoso 2018-01-26 13:58 ` [PATCH v3 2/2] drm/virtio: Handle buffers from the compositor Tomeu Vizoso 2018-01-26 13:58 ` Tomeu Vizoso
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=20180206142302.vdjyqmnoypydci4t@sirius.home.kraxel.org \ --to=kraxel@redhat.com \ --cc=airlied@linux.ie \ --cc=dri-devel@lists.freedesktop.org \ --cc=jasowang@redhat.com \ --cc=kernel@collabora.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mst@redhat.com \ --cc=stefanha@gmail.com \ --cc=tomeu.vizoso@collabora.com \ --cc=virtualization@lists.linux-foundation.org \ --cc=zachr@google.com \ /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: linkBe 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.