Handle dependency by VkMemoryDedicatedAllocateInfo

We have a situation that if an image memory is created with
VkMemoryDedicatedAllocateInfo, the following commands that refer to the
same image  must happen in this exact order:

vkCreateImage
vkAllocateMemory (with dedicated image memory)
vkBindImageMemory
vkCreateImageView

Our previous dependency graph implementation uses Vulkan objects as
nodes and does not haven enough granularity to handle this situation.
vkCreateImageView can only be executed after an image is created and
bound to memory. Our previous dependency graph does not have the
notion of "bound to memory". We worked around it by adding
vkBindImageMemory as part of the image initialization steps.

To make sure we can bind image at initialization, we marked image to be
dependent on the memory it bounds to. When adding the new
vkAllocateMemory with dedicated image memory extension into the mix, it
introduced a circular dependency. vkAllocateMemory will say the memory
has dependency on the image. vkBindImageMemory will say the image has
dependency on the memory.

To properly resolve the issue, we will need to record the state of an
Vulkan object, and declare that vkCreateImageView not only depends on an
image, but also requires the image to be bound to memory. We do so by
introducing a "State" enum and use the pair <VkObjectHandle, State> as
the vertex in the deppendency graph. Currently State is an enum with 2
values: CREATED and BOUND_MEMORY. By default, after a VkCreate* command,
an object will be in CREATED state. When calling vkBindImageMemory or
vkBindBufferMemory it will transform the image or buffer into
BOUND_MEMORY state. Then vkCreateImageView will have dependency with
{VkImage, BOUND_MEMORY}.

Then we can create a dependency graph that looks like this:

VkImageView --> {VkImage,BOUND_MEMORY} --> VkMemory
                        |                       |
                        |   ┌-------------------⅃
                        v   v
                       VkImage

No more circular dependency.

Test: GfxstreamEnd2EndVkSnapshotImageTests
Bug: 333447188
Change-Id: Ie47a357a0a6560486c57d129037998a84e5eac1d
GitOrigin-RevId: 1006a864581cb6b96c408fc278225777dbefe0a8
5 files changed
tree: 3f2c134ac0cca873a0c2ca68241421fbdc03ebd2
  1. cmake/
  2. codegen/
  3. common/
  4. docs/
  5. guest/
  6. host/
  7. include/
  8. qnx/
  9. scripts/
  10. subprojects/
  11. third-party/
  12. utils/
  13. .clang-format
  14. .gitignore
  15. Android.bp
  16. BUILD.bazel
  17. CMakeLists.txt
  18. LICENSE
  19. meson.build
  20. meson_options.txt
  21. MODULE_LICENSE_APACHE2
  22. OWNERS
  23. README.md
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.