commit | dbe1ade67054bc632c9f6f95e7f20495a482ea62 | [log] [tgz] |
---|---|---|
author | Jason Macnak <natsu@google.com> | Thu Nov 10 14:45:07 2022 -0800 |
committer | Jason Macnak <natsu@google.com> | Wed Jan 04 09:49:59 2023 -0800 |
tree | 8076220c324f3677add34bf34509a7c43b5968aa | |
parent | 981d85c1754b299a2a81cadec3d458634f715169 [diff] |
Route gl<->vk ColorBuffer syncs through FrameBuffer RenderControl functions such as rcBindTexture(), rcFlushWindowColorBuffer(), etc act as a kind of boundary between ColorBuffer usage across APIs (GL/EGL, Vulkan, and Gralloc) and need to sync the state of the ColorBuffer between the various host APIs that back ColorBuffers. For example, rcBindTexture() needs to sync the state of GL texture backing ColorBuffers for GL usage and does so by reading the state from the VK image. Upcoming ColorBuffer refactoring, to enable running without host GL, needs to make the ColorBuffer VK setup path not depend on the ColorBuffer GL path. With this, setup of the VK backing will no longer be deferred until the first VK usage and ColorBuffer::create() is updated to perform both ColorBufferGl::create() and ColorBufferVk::create() immediately. However, this can lead to a potential deadlock because of the order of locks acquired during the ColorBuffer creation flow and the RenderControl sync'ing flows. * The RenderControl functions use goldfish_vk::readColorBufferToGl() and goldfish_vk::updateColorBufferFromGl() to perform downloads and uploads for both GL and VK. These calls lock sVkEmulationLock first and then lock FrameBuffer::m_lock second. * The virtio-gpu resource_create_3d() path calls into FrameBuffer::createColorBuffer() which then calls into ColorBufferGl::create() and ColorBufferVk::create(). These calls lock FrameBuffer::m_lock first and then sVkEmulationLock second. This change updates the RenderControl functions to go through the FrameBuffer lock first so that it is kind-of always a top-down locking approach. Bug: b/233939967 Test: android build Test: cmake build Test: cvd start --gpu_mode=gfxstream Test: gfxstream unit tests Change-Id: I3d4aa41c1bad0028077ceb85700b401996e01e86
Graphics Streaming Kit is a code generator that makes it easier to serialize and forward graphics API calls from one place to another:
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
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.
Be in the Android build system. Then
m libgfxstream_backend
It then ends up in out/host
This also builds for Android on-device.
libgfxstream_backend.(dll|so|dylib)
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
.
First, build build/gfxstream-generic-apigen
. Then run
scripts/generate-apigen-source.sh
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
.
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%
.
These are currently not built due to the dependency on system libEGL/libvulkan to run correctly.
CMakeLists.txt
: specifies all host-side build targets. This includes all backends along with client/server setups that live only on the host. SomeAndroid.bp
: specifies all guest-side build targets for Android:BUILD.gn
: specifies all guest-side build targets for Fuchsiabase/
: 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.