On 11/14/2017 03:19 PM, Gerd Hoffmann wrote:
What kind of shared memory is used by wayland?
sysv shm? gbm buffers / dmabufs?
Typically, shared memory for CPU-rendered content, and dmabufs for
GPU-rendered content.
Ok. I guess solving this for virtio-gpu (with virgl enabled) is easiest
then. Due to opengl rendering being offloaded to the host gpu the
guest window content already is in a host gpu buffer.
Yes, besides, we already have virtio-gpu in place which can be improved as
needed.
I'm more worried about CPU-rendered buffers, as the client is just putting
in the socket the output of shm_open or similar. There I don't see any easy
solution which is why I tried to get more "creative".
Will clients actually use cpu rendering of opengl is available?
Don't know of any Wayland clients that would behave in that way.
Can clients cpu-render into dumb drm buffers?
They could, but dumb buffers aren't generally shareable, besides being
intended to be just dumb. We could probably use VGEM for that though.
But the problem is that all Wayland clients are currently expected to do
their CPU rendering to a buffer that was created in /dev/shm/ or with
the memfd_create syscall.
I know we cannot support all the kinds of objects that can be referenced
by FDs, but I think it can be said that all modern protocols that can
contain references to big areas of memory make use of passing FDs to
shared memory. Depending on the situation that memory would have been
allocated in the host or in the client.
Thanks,
Tomeu
