All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marc-André Lureau" <marcandre.lureau@gmail.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: QEMU <qemu-devel@nongnu.org>, Dave Airlie <airlied@gmail.com>
Subject: Re: [Qemu-devel] [RFC v2 11/12] Add virtio-gpu vhost-user backend
Date: Sat, 9 Jun 2018 03:02:12 +0200	[thread overview]
Message-ID: <CAJ+F1CL4VMqjZqTxb4JUyo=Erb++_HU_yYtf5SiuiZCqQ2Adww@mail.gmail.com> (raw)
In-Reply-To: <CAJ+F1C+v0NCX+88=MGW7uM_05tgcB4d7rRC-RC87n0a6gAq4kA@mail.gmail.com>

On Fri, Jun 8, 2018 at 7:25 PM, Marc-André Lureau
<marcandre.lureau@gmail.com> wrote:
> Hi
>
> On Mon, Jun 4, 2018 at 11:37 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
>> On Fri, Jun 01, 2018 at 06:27:48PM +0200, Marc-André Lureau wrote:
>>> Add to virtio-gpu devices a "vhost-user" property. When set, the
>>> associated vhost-user backend is used to handle the virtio rings.
>>>
>>> For now, a socketpair is created for the backend to share the rendering
>>> results with qemu via a simple VHOST_GPU protocol.
>>
>> Why this isn't a separate device, like vhost-user-input-pci?
>
> Ok, let's have vhost-user-gpu-pci and vhost-user-vga, inheriting from
> existing devices.
>
>>> +typedef struct VhostGpuUpdate {
>>> +    uint32_t scanout_id;
>>> +    uint32_t x;
>>> +    uint32_t y;
>>> +    uint32_t width;
>>> +    uint32_t height;
>>> +    uint8_t data[];
>>> +} QEMU_PACKED VhostGpuUpdate;
>>
>> Hmm, when designing a new protocol I think we can do better than just
>> squeering the pixels into a tcp stream.  Use shared memory instead?  Due
>> to vhost we are limited to linux anyway, so we might even consider stuff
>> like dmabufs here.
>
> Well, my goal is not to invent a new spice or wayland protocol :) I
> don't care much about 2d performance at this point, more about 3d. Can
> we leave 2d improvements for another day? Beside, what would dmabuf
> bring us for 2d compared to shmem?
>
> There seems to be a lot of overhead with the roundtrip vhost-user ->
> qemu -> spice worker -> spice client -> wayland/x11 -> gpu already
> (but this isn't necessarily so bad at 60fps or less).
> Ideally, I would like to bypass qemu & spice for local rendering, but
> I don't think wayland support that kind of nested window composition
> (at least tracking messages weston --nested doesn't show that kind of
> optimization).
>
> FWIW, here are some Unigine Heaven 4.0 benchmarks (probably within +-10%):
>
> qemu-gtk/egl+virtio-gpu: fps:2.6/ score: 64
> qemu-gtk/egl+vhost-user-gpu: fps:12.9 / score: 329
>
> spice+virtio-gpu: fps:2.8 / score: 70
> spice+vhost-user-gpu: fps:12.1 / score: 304
>
> That should give an extra motivation :)
>

(host is fps:31.1 / score:784



-- 
Marc-André Lureau

  reply	other threads:[~2018-06-09  1:02 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-01 16:27 [Qemu-devel] [RFC v2 00/12] vhost-user for input & GPU Marc-André Lureau
2018-06-01 16:27 ` [Qemu-devel] [RFC v2 01/12] chardev: avoid crash if no associated address Marc-André Lureau
2018-06-08 14:52   ` Philippe Mathieu-Daudé
2018-06-11  8:59     ` Daniel P. Berrangé
2018-06-11  9:04   ` Daniel P. Berrangé
2018-06-01 16:27 ` [Qemu-devel] [RFC v2 02/12] libvhost-user: exit by default on VHOST_USER_NONE Marc-André Lureau
2018-06-08 14:48   ` Philippe Mathieu-Daudé
2018-06-01 16:27 ` [Qemu-devel] [RFC v2 03/12] vhost-user: wrap some read/write with retry handling Marc-André Lureau
2018-06-08 14:53   ` Philippe Mathieu-Daudé
2018-06-01 16:27 ` [Qemu-devel] [RFC v2 04/12] Add vhost-user-backend Marc-André Lureau
2018-06-04  9:36   ` Daniel P. Berrangé
2018-06-07 22:34     ` Marc-André Lureau
2018-06-08  8:43       ` Daniel P. Berrangé
2018-06-12 14:53         ` Marc-André Lureau
2018-06-12 15:08           ` Daniel P. Berrangé
2018-06-01 16:27 ` [Qemu-devel] [RFC v2 05/12] vhost-user: split vhost_user_read() Marc-André Lureau
2018-06-08 14:57   ` Philippe Mathieu-Daudé
2018-06-12 14:58     ` Marc-André Lureau
2018-06-01 16:27 ` [Qemu-devel] [RFC v2 06/12] vhost-user: add vhost_user_input_get_config() Marc-André Lureau
2018-06-04  9:07   ` Dr. David Alan Gilbert
2018-06-04  9:18     ` Marc-André Lureau
2018-06-04  9:59       ` Dr. David Alan Gilbert
2018-06-12 12:46         ` Marc-André Lureau
2018-06-01 16:27 ` [Qemu-devel] [RFC v2 07/12] libvhost-user: export vug_source_new Marc-André Lureau
2018-06-01 16:27 ` [Qemu-devel] [RFC v2 08/12] contrib: add vhost-user-input Marc-André Lureau
2018-06-01 16:27 ` [Qemu-devel] [RFC v2 09/12] Add vhost-input-pci Marc-André Lureau
2018-06-04  8:58   ` Gerd Hoffmann
2018-06-07 22:22     ` Marc-André Lureau
2018-06-08  5:41       ` Gerd Hoffmann
2018-06-01 16:27 ` [Qemu-devel] [RFC v2 10/12] vhost-user: add vhost_user_gpu_set_socket() Marc-André Lureau
2018-06-04  9:28   ` Gerd Hoffmann
2018-06-01 16:27 ` [Qemu-devel] [RFC v2 11/12] Add virtio-gpu vhost-user backend Marc-André Lureau
2018-06-04  9:37   ` Gerd Hoffmann
2018-06-08 17:25     ` Marc-André Lureau
2018-06-09  1:02       ` Marc-André Lureau [this message]
2018-06-11  6:49       ` Gerd Hoffmann
2018-06-01 16:27 ` [Qemu-devel] [RFC v2 12/12] contrib: add vhost-user-gpu Marc-André Lureau
2018-06-01 17:28 ` [Qemu-devel] [RFC v2 00/12] vhost-user for input & GPU no-reply

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='CAJ+F1CL4VMqjZqTxb4JUyo=Erb++_HU_yYtf5SiuiZCqQ2Adww@mail.gmail.com' \
    --to=marcandre.lureau@gmail.com \
    --cc=airlied@gmail.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.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.