qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC v2 11/12] Add virtio-gpu vhost-user backend


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [RFC v2 11/12] Add virtio-gpu vhost-user backend
Date: Mon, 11 Jun 2018 08:49:33 +0200
User-agent: NeoMutt/20180512

> >> 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.

I'd tend to create separate devices instead of inheriting from the
existing devices.  Arn't the code paths more or less completely
different?  What code is shared between builtin and vhost-user versions
of the 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?

Well, you need dma-bufs for 3d anyway, so why not use them for 2d too?
I don't think we need separate code paths for 2d vs. 3d updates.

> 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).

Yep, a direct vhost-user -> wayland path makes sense.  Using dma-bufs
for both 2d and 3d should simplify that too (again: one code path
instead of two).

What do you mean with nested window composition?

cheers,
  Gerd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]