Google Git
Sign in
android / platform / hardware / google / gfxstream / b2a4a79b116fb4e2c366cc0f5e611012c0beab8f
commitb2a4a79b116fb4e2c366cc0f5e611012c0beab8f[log] [tgz]
authorJason Macnak <[email protected]>Thu Feb 23 00:40:01 2023 +0000
committerJason Macnak <[email protected]>Wed Feb 22 17:11:18 2023 -0800
tree8707d96c53b2a750f6f7ade6e87b897d0ba022d7
parent4c45edb1a4ecc426278b2952bdaad1b5c8c0e0ed [diff]
(Reland) Rename ColorBuffer to ColorBufferGl and add ColorBuffer

... which wraps ColorBufferGl and effectively ColorBufferVk
as the existing ColorBuffer code is GL specific. Moves routing
of existing Gl specific functions through prefixed 'glOp*'
functions. Potentially, ColorBuffer should just provide API
specific functions and be responsible for handling coordination
across APIs (sync'ing between Gl and Vk on read/update).

Reland notes:
 - See diff versus previous aosp/2385356 with
   https://android-review.googlesource.com/c/device/generic/vulkan-cereal/+/2452171/1..3

 - The previous attempt aosp/2385356 updated the "default" backing
   used for upload/download operations to Vulkan (for no particular
   reason). This caused issues for ColorBuffers which did not use
   shared external memory for both GL and VK (in this case, because
   it was for a YUV ColorBuffer) because the import to VK memory
   operation assumes a "default" backing to be GL and tries to do
   an extra GL->VK copy.

 - The previous attempt also uncovered that `importMemory()` did
   not reset the GL framebuffer used for blit'ing window surfaces
   into the ColorBuffer texture. This would result in blank images
   when the "default" backing was switched back to GL because (I
   believe) the framebuffer kept alive the original ColorBuffer
   texture (because it was still attached) and blits would go into
   the no longer used original texture.

Bug: b/270458925
Bug: b/270459313
Bug: b/233939967
Test: android build
Test: cmake build
Test: cvd start --gpu_mode=gfxstream
Test: gfxstream unit tests
Change-Id: I1fd7a7a79993074bd22af818a2325849cc59581f
20 files changed
tree: 8707d96c53b2a750f6f7ade6e87b897d0ba022d7
  1. cmake/
  2. fake-android-guest/
  3. gl-host-common/
  4. include/
  5. protocols/
  6. scripts/
  7. stream-servers/
  8. testenvs/
  9. third-party/
  10. utils/
  11. .clang-format
  12. .gitignore
  13. Android.bp
  14. android.cmake
  15. build-host.sh
  16. BUILD.gn
  17. CMakeLists.txt
  18. LICENSE
  19. METADATA
  20. 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

Make sure the latest CMake is installed. Make sure the opengl lib is installed. Otherwise, sudo apt-get install libglu1-mesa-dev freeglut3-dev mesa-common-dev Make sure you are using Clang as your CC and clang++ as yourCXX. Then

mkdir build
cd build
cmake . ../
make -j24

Unit tests:

make test

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

Check out the gfxstream-protocols repo at ../../../external/gfxstream-protocols relative to the root directory of this repo, and run the scripts/generate-vulkan-sources.sh script in the gfxstream-protocols root folder.

If you're in an AOSP checkout, this will also modify contents of the guest Vulkan encoder in ../goldfish-opengl.

Regenerating GLES/RenderControl code

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

scripts/generate-apigen-source.sh

Tests

Linux Tests

There are a bunch of test executables generated. They require libEGL.so and libGLESv2.so and libvulkan.so to be available, possibly from your GPU vendor or ANGLE, in the $LD_LIBRARY_PATH.

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

These are currently not built due to the dependency on system libEGL/libvulkan to run correctly.

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.