> > 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
On 02/12/2018 12:45 PM, Gerd Hoffmann wrote: 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
On 02/12/2018 12:45 PM, Gerd Hoffmann wrote:
Hi,
(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:
On Mon, 12 Feb 2018 12:45:40 +0100
Gerd Hoffmann wrote:
> Hi,
>
> > >(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 serv
> > I was more thinking about a struct containing enough info to allow the
> > proxy on the host side find the buffer, something like:
> >
> > struct {
> >enum type { stdvga, virtio-cpu, ... }
> >pcislot device;
> >union {
> > int stdvga_pcibar_offset;
> >
On 02/12/2018 03:27 PM, Gerd Hoffmann wrote:
On Mon, Feb 12, 2018 at 03:00:24PM +0100, Tomeu Vizoso wrote:
On 02/12/2018 12:52 PM, Gerd Hoffmann wrote:
Hi,
can we reach agreement on whether vsock should be involved in this?
I think the best approach would be to have guest proxy and host
On Mon, Feb 12, 2018 at 03:00:24PM +0100, Tomeu Vizoso wrote:
> On 02/12/2018 12:52 PM, Gerd Hoffmann wrote:
> >Hi,
> >
> > > can we reach agreement on whether vsock should be involved in this?
> >
> > I think the best approach would be to have guest proxy and host proxy
> > use vsock for the
On 02/12/2018 12:52 PM, Gerd Hoffmann wrote:
Hi,
can we reach agreement on whether vsock should be involved in this?
I think the best approach would be to have guest proxy and host proxy
use vsock for the wayland protocol. Use a wayland protocol extension to
reference the buffers in stdvg
Hi,
> can we reach agreement on whether vsock should be involved in this?
I think the best approach would be to have guest proxy and host proxy
use vsock for the wayland protocol. Use a wayland protocol extension to
reference the buffers in stdvga / ivshmem / virtio-gpu. Only the two
proxies
Hi,
> >(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, alloc
Hi Gerd and Stefan,
can we reach agreement on whether vsock should be involved in this?
Thanks,
Tomeu
On 02/07/2018 10:49 AM, Tomeu Vizoso wrote:
On 02/06/2018 03:23 PM, Gerd Hoffmann wrote:
Hi,
Hmm? I'm assuming the wayland client (in the guest) talks to the
wayland proxy, using the w
On 02/06/2018 03:23 PM, Gerd Hoffmann wrote:
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
On 02/07/2018 02:09 AM, Michael S. Tsirkin wrote:
On Tue, Feb 06, 2018 at 03:23:02PM +0100, Gerd Hoffmann wrote:
Creation of shareable buffer by guest
-
1. Client requests virtio driver to create a buffer suitable for sharing
with host (DRM_VIRTGP
On Tue, Feb 06, 2018 at 03:23:02PM +0100, Gerd Hoffmann wrote:
> > 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
On Mon, 5 Feb 2018 17:03:22 +0100
Gerd Hoffmann wrote:
> On Mon, Feb 05, 2018 at 03:46:17PM +0100, Tomeu Vizoso wrote:
> > On 02/05/2018 01:20 PM, Gerd Hoffmann wrote:
> > >Hi,
> > >
>
> Hmm. I allways assumed the wayland client allocates the buffers, not
> the server. Is that wrong?
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?
>
On 02/05/2018 05:03 PM, Gerd Hoffmann wrote:
On Mon, Feb 05, 2018 at 03:46:17PM +0100, Tomeu Vizoso wrote:
On 02/05/2018 01:20 PM, Gerd Hoffmann wrote:
Hi,
Why not use virtio-vsock to run the wayland protocol? I don't like
the idea to duplicate something with very simliar functionality in
On Mon, Feb 05, 2018 at 03:46:17PM +0100, Tomeu Vizoso wrote:
> On 02/05/2018 01:20 PM, Gerd Hoffmann wrote:
> >Hi,
> >
> > > > Why not use virtio-vsock to run the wayland protocol? I don't like
> > > > the idea to duplicate something with very simliar functionality in
> > > > virtio-gpu.
> >
On 02/05/2018 01:20 PM, Gerd Hoffmann wrote:
Hi,
Why not use virtio-vsock to run the wayland protocol? I don't like
the idea to duplicate something with very simliar functionality in
virtio-gpu.
The reason for abandoning that approach was the type of objects that
could be shared via virtio
Hi,
> > Why not use virtio-vsock to run the wayland protocol? I don't like
> > the idea to duplicate something with very simliar functionality in
> > virtio-gpu.
>
> The reason for abandoning that approach was the type of objects that
> could be shared via virtio-vsock would be extremely limite
On 1 February 2018 at 17:36, Gerd Hoffmann wrote:
Hi,
Sorry for joining the party late. Had a broken finger and was
offline for a bunch of weeks (and a buif backlog afterwards ...).
Hi, no problem, hope it's fine now.
This is to allow clients running within VMs to be able to
communicate wit
Hi,
Sorry for joining the party late. Had a broken finger and was offline
for a bunch of weeks (and a buif backlog afterwards ...).
> This is to allow clients running within VMs to be able to communicate
> with a compositor in the host. Clients will use the communication
> protocol that the co
This is to allow clients running within VMs to be able to communicate
with a compositor in the host. Clients will use the communication
protocol that the compositor supports, and virtio-gpu will assist with
making buffers available in both sides, and copying content as needed.
It is expected that
23 matches
Mail list logo