On Mon, Feb 18, 2019 at 11:18 PM Gerd Hoffmann <> wrote:
On Tue, Feb 12, 2019 at 08:17:13AM -0800, Frank Yang wrote:
> In implementing a complete graphics system, shared memory objects may
> transcend device boundaries.
>
> Consider for example, Android and gralloc. The media codec versus the GPU
> rendering are commonly considered as separate devices, but they work better
> if operating on a common shared memory type (gralloc buffers).
Linux has dma-bufs for that (driver-api/dma-buf.rst).
Â
Yes; I also followed a discussion around udmabuf for Vulkan host memory sharing.
However, dma-buf seems to require either a Linux kernel or a Linux host.
Dma-bufs aren't also 1:1 with Vulkan host visible memory pointers,
or v4l2 codec buffers, or ffmpeg codec buffers, etc.
For the use case of Vulkan, it's fortunate that there is an external memory dma buf,
but its application seems very limited to linux hosts and
host drivers that support that kind of external memory.
The proposed device would be able to expose memory for direct access in a way that
does not couple to dma-buf which is highly desirable for our use case.
Using the ping/event messages, even win32 handles and general opaque fds
can be passed from host to guest and back.
You can think of the proposed device as a 'virtio-dmabuf' that
tries to expose shareable memory in a way that disregards implementation details of
guest and host kernels.
Â
cheers,
 Gerd
