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: Fri, 16 Feb 2018 11:48:40 +0100 [thread overview]
Message-ID: <20180216104840.wtqblyrrhwek6ox7@sirius.home.kraxel.org> (raw)
In-Reply-To: <37179029-8ccb-8eb2-0901-04b64cef3608@collabora.com>
> > Yes.
>
> Would it make sense for virtio-gpu to map buffers to the guest via PCI BARs?
> So we can use a single drm driver for both 2d and 3d.
Should be doable.
I'm wondering two things though:
(1) Will shmem actually help avoiding a copy?
virtio-gpu with virgl will (even if the guest doesn't use opengl) store
the resources in gpu memory. So the VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D
copy goes from guest memory directly to gpu memory, and if we export
that as dma-buf and pass it to the wayland server it should be able to
render it without doing another copy.
How does the wl_shm_pool workflow look like inside the wayland server?
Can it ask the gpu to render directly from the pool? Or is a copy to
gpu memory needed here? If the latter we would effectively trade one
copy for another ...
(2) Could we handle the mapping without needing shmem?
Possibly we could extend the vgem driver. So we pass in a iov (which
qemu gets from guest via VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING), get
back a drm object. Which effectively creates drm objects on the host
which match the drm object in the guest (both backed by the same set of
physical pages).
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-16 10:48 UTC|newest]
Thread overview: 26+ 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 ` [PATCH v3 1/2] " Tomeu Vizoso
2018-02-01 16:36 ` Gerd Hoffmann
2018-02-05 8:19 ` Tomeu Vizoso
2018-02-05 12:20 ` Gerd Hoffmann
2018-02-05 14:46 ` Tomeu Vizoso
2018-02-05 16:03 ` Gerd Hoffmann
2018-02-06 12:41 ` Tomeu Vizoso
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 9:49 ` Tomeu Vizoso
2018-02-09 11:14 ` Tomeu Vizoso
2018-02-12 11:52 ` Gerd Hoffmann
2018-02-12 14:00 ` Tomeu Vizoso
2018-02-12 14:27 ` Gerd Hoffmann
2018-02-12 14:42 ` Tomeu Vizoso
2018-02-12 15:29 ` Gerd Hoffmann
2018-02-12 11:45 ` Gerd Hoffmann
2018-02-13 7:41 ` Pekka Paalanen
2018-02-13 14:27 ` Tomeu Vizoso
2018-02-16 10:48 ` Gerd Hoffmann [this message]
2018-02-15 15:28 ` Tomeu Vizoso
2018-02-06 15:00 ` Pekka Paalanen
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
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=20180216104840.wtqblyrrhwek6ox7@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 \
/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;
as well as URLs for NNTP newsgroup(s).