commit	f5d617e7153133adff46169e671853cf8e2501f9	[log] [tgz]
author	Gurchetan Singh <[email protected]>	Fri Jul 19 11:15:11 2024 -0700
committer	Gurchetan Singh <[email protected]>	Mon Aug 12 08:05:38 2024 -0700
tree	6b9343f850b544c5a44186a064142ef8d1357bcd
parent	050c8ffe5c860513e1d988c2b5f7087b9a229c5b [diff]

gfxstream: end2end: nuke RutabagaLayer, use kumquat for testing

This change nukes the RutabagaLayer and makes the
end2end testing layer use Kumquat.

The benefit is not having two different testing
frameworks.  Compared to the RutabagaLayer, Kumquat
is more complex, but potentially has more features
in the long run.  Some advanatages:

  - virtgpu_kumquat_ffi is portable enough that
    non-gfxstream libraries (minigbm, others) can
    depend on it.  This would enable more accurate
    gralloc testing long-term.

  - multiple different context types can connect to
    Kumquat at the same time, rather than just one with
    the RutabagaLayer.

  - If anyone is bored, it should be pretty easy add
    v4l2 apis via an virtio-media like interface.

  - The kumquat server can actually call
    stream_renderer_teardown(..) when performing
    snapshot tests.

  - Kumquat relies on EventFd + VkExternalSync:
    this can eliminate the need to export the
    libplatform sync API outside VK, EGL over the
    long-term.

A point of complexity was Gralloc.  We have an external
Gralloc instance, but HostConnection also maintains a
thread-local Gralloc instances.  The thread-local gralloc
instances can potentially step on the kumquat connection
of the pipe or ASG stream.  The solution was for
GrallocEmulated to maintain it's own virtgpu_kumquat
instance.

The proper long-term solution is move gralloc out of
HostConnection entirely.

A prior version of this change relied on:

   - vkInitializeKumquat,
   - rcCreateDeviceKumquat
   - eglInitializeKumquat

since I read somewhere GoogleTest is necessarily
multi-threaded. That turned out to be fake news, so nuke
those functions as well.

BUG=354706346
TEST=CI

Change-Id: I0bcf1ba0fa2f18f2b30c4177681959b0815d4068

36 files changed

tree: 6b9343f850b544c5a44186a064142ef8d1357bcd

README.md

Graphics Streaming Kit (formerly: Vulkan Cereal)

Graphics Streaming Kit is a code generator that makes it easier to serialize and forward graphics API calls from one place to another:

From a virtual machine guest to host for virtualized graphics
From one process to another for IPC graphics
From one computer to another via network sockets

Build: Linux

The latest directions for the standalone Linux build are provided here.

Build: Windows

Make sure the latest CMake is installed. Make sure Visual Studio 2019 is installed on your system along with all the Clang C++ toolchain components. Then:

mkdir build
cd build
cmake . ../ -A x64 -T ClangCL

A solution file should be generated. Then open the solution file in Visual studio and build the gfxstream_backend target.

Build: Android for host

Be in the Android build system. Then:

m libgfxstream_backend

It then ends up in out/host

This also builds for Android on-device.

Output artifacts

libgfxstream_backend.(dll|so|dylib)

Regenerating Vulkan code

To re-generate both guest and Vulkan code, please run:

scripts/generate-gfxstream-vulkan.sh

Regenerating GLES/RenderControl code

First, build build/gfxstream-generic-apigen. Then run:

scripts/generate-apigen-source.sh

Tests

Windows Tests

There are a bunch of test executables generated. They require libEGL.dll and libGLESv2.dll and vulkan-1.dll to be available, possibly from your GPU vendor or ANGLE, in the %PATH%.

Android Host Tests

There are Android mock testa available, runnable on Linux. To build these tests, run:

m GfxstreamEnd2EndTests

Structure

CMakeLists.txt: specifies all host-side build targets. This includes all backends along with client/server setups that live only on the host. Some
- Backend implementations
- Implementations of the host side of various transports
- Frontends used for host-side testing with a mock implementation of guest graphics stack (mainly Android)
- Frontends that result in actual Linux/macOS/Windows gles/vk libraries (isolation / fault tolerance use case)
Android.bp: specifies all guest-side build targets for Android:
- Implementations of the guest side of various transports (above the kernel)
- Frontends
BUILD.gn: specifies all guest-side build targets for Fuchsia
- Implementations of the guest side of various transports (above the kernel)
- Frontends
base/: common libraries that are built for both the guest and host. Contains utility code related to synchronization, threading, and suballocation.
protocols/: implementations of protocols for various graphics APIs. May contain code generators to make it easy to regen the protocol based on certain things.
host-common/: implementations of host-side support code that makes it easier to run the server in a variety of virtual device environments. Contains concrete implementations of auxiliary virtual devices such as Address Space Device and Goldfish Pipe.
stream-servers/: implementations of various backends for various graphics APIs that consume protocol. gfxstream-virtio-gpu-renderer.cpp contains a virtio-gpu backend implementation.

Guest Vulkan design

gfxstream vulkan is the most actively developed component. Some key commponents of the current design include:

1:1 threading model - each guest Vulkan encoder thread gets host side decoding thread
Support for both virtio-gpu, goldish and testing transports.
Support for Android, Fuchsia, and Linux guests.
Ring Buffer to stream commands, in the style of io_uring.
Mesa embedded to provide dispatch and objects.
Currently, there are a set of Mesa objects and gfxstream objects. For example, struct gfxstream_vk_device and the gfxstream object goldfish_device both are internal representations of Vulkan opaque handle VkDevice. The Mesa object is used first, since Mesa provides dispatch. The Mesa object contains a key to the hash table to get a gfxstream internal object (for example, gfxstream_vk_device::internal_object). Eventually, gfxstream objects will be phased out and Mesa objects used exclusively.