tree 3878423d264c5c369e499a32d6a389fa3c350ff0
parent 59f581f2a15524fd46a5dc0c0bf8d620589a97ab
author Gurchetan Singh <gurchetansingh@chromium.org> 1718127077 -0700
committer Gurchetan Singh <gurchetansingh@google.com> 1719855551 -0700

gfxstream: guest: enable virtio-gpu kumquat

This uses libvirtgpu_kumquat_ffi.so to send commands to the
Kumquat Media Server.  The implementation of Kumquat is found
at crrev.com/c/5645904.

This is a more complex, but more fully featured end-to-end testing
framework.  This biggest benefit it is can run complex apps (vkcube,
gfxbench + ANGLE/Zink) on Linux, without a VM or a full Android tree.
The rutabaga FFI path -- which relied on a nested Vulkan loader -- didn't
work for complex apps and funkiness was observed with the nested
Vulkan loader.

Plus, app 1 + app 2 could connect Kumquat at the same time.

This may also benefit snapshot tests, particular since end to end
flow relies on external blob.  For example, a snapshot save command
could actually call stream_renderer_teardown(..) on the host-side,
while the guest retains it's state (ASG mappings + vulkano mappings).

A snapshot restore would actually call stream_renderer_init(..)
+ stream_renderer_restore(..), which an actual upstream VMM would
do.

Another additional benefit is multi-context testing.  Since
libvirtgpu_kumquat_ffi.so is portable, other libraries (minigbm)
can also call it.  We can mimic the cross-domain context allocating
via libminigbm.so, while context libgfxstream_vulkan.so imports the
file descriptor.

This change only transitions the meson build since the main goal
is once again is Linux on Linux testing w/o an Android tree.

BUG=300140266
TEST=run apps via Kumquat

Change-Id: I37494a6146a969f5f21ac208141b640d2272692e