Re: [RFC PATCH 00/13] gfxstream + rutabaga_gfx: a surprising delight or startling epiphany?

[Akihiko Odaki <akihiko.odaki@gmail.com>]

On 2023/04/22 8:54, Gurchetan Singh wrote:
> On Fri, Apr 21, 2023 at 9:02 AM Stefan Hajnoczi <stefanha@gmail.com> wrote:
>>
>> On Thu, 20 Apr 2023 at 21:13, Gurchetan Singh
>> <gurchetansingh@chromium.org> wrote:
>>>
>>> From: Gurchetan Singh <gurchetansingh@google.com>
>>>
>>> Rationale:
>>>
>>> - gfxstream [a] is good for the Android Emulator/upstream QEMU
>>>    alignment
>>> - Wayland passhthrough [b] via the cross-domain context type is good
>>>    for Linux on Linux display virtualization
>>> - rutabaga_gfx [c] sits on top of gfxstream, cross-domain and even
>>>    virglrenderer
>>> - This series ports rutabaga_gfx to QEMU
>>
>> What rutabaga_gfx and gfxstream? Can you explain where they sit in the
>> stack and how they build on or complement virtio-gpu and
>> virglrenderer?
> 
> rutabaga_gfx and gfxstream are both libraries that implement the
> virtio-gpu protocol.  There's a document available in the Gitlab issue
> to see where they fit in the stack [a].
> 
> gfxstream grew out of the Android Emulator's need to virtualize
> graphics for app developers.  There's a short history of gfxstream in
> patch 10.  It complements virglrenderer in that it's a bit more
> cross-platform and targets different use cases -- more detail here
> [b].  The ultimate goal is ditch out-of-tree kernel drivers in the
> Android Emulator and adopt virtio, and porting gfxstream to QEMU would
> speed up that transition.

I wonder what is motivation for maintaining gfxstream instead of 
switching to virglrenderer/venus.

> 
> rutabaga_gfx is a much smaller Rust library that sits on top of
> gfxstream and even virglrenderer, but does a few extra things.  It
> implements the cross-domain context type, which provides Wayland
> passthrough.  This helps virtio-gpu by providing more modern display
> virtualization.  For example, Microsoft for WSL2 also uses a similar
> technique [c], but I believe it is not virtio-based nor open-source.

The guest side components of WSLg are open-source, but the host side is 
not: https://github.com/microsoft/wslg
It also uses DirectX for acceleration so it's not really portable for 
outside Windows.

> With this, we can have the same open-source Wayland passthrough
> solution on crosvm, QEMU and even Fuchsia [d].  Also, there might be
> an additional small Rust context type for security-sensitive use cases
> in the future -- rutabaga_gfx wouldn't compile its gfxstream bindings
> (since it's C++ based) in such cases.
> 
> Both gfxstream and rutabaga_gfx are a part of the virtio spec [e] now too.
> 
> [a] https://gitlab.com/qemu-project/qemu/-/issues/1611
> [b] https://lists.gnu.org/archive/html/qemu-devel/2023-03/msg04271.html
> [c] https://www.youtube.com/watch?v=EkNBsBx501Q
> [d] https://fuchsia-review.googlesource.com/c/fuchsia/+/778764
> [e] https://github.com/oasis-tcs/virtio-spec/blob/master/device-types/gpu/description.tex#L533
> 
>>
>> Stefan