commit | 3eb6e5f7182776887b25e9a57e03b51b3db6bbcb | [log] [tgz] |
---|---|---|
author | Jason Macnak <natsu@google.com> | Mon Apr 15 08:51:37 2024 -0700 |
committer | Copybara-Service <copybara-worker@google.com> | Wed Apr 24 15:32:07 2024 -0700 |
tree | f7cfe4bfeacf7187ff0c5dcacd9422fadcf1afaf | |
parent | 9aeef0ca04f60860cadac89d6f500812fc44aedd [diff] |
Add tracking for sync objs used by vkAcquireImageANDROID() ... as the Gfxstream host renderer may launch additional queue submits to signal these sync objects without the guest knowing. This is an alternative approach to aosp/2908038. aosp/2908038 deferred the destruction of these sync objects until VkDevice destruction time under the assumption that these sync objects are generally recycled across frames frequently. However, this did not work for persistant services (SystemUI) nor longer lived apps (CTS) and would result in continuous build up of open objects which would eventually cause issues when the nofile limit was reached for the host process (CtsGraphicsTestCases seemed to peak at ~12k open FDs). Bug: b/319697090 Test: cts -m CtsDeqpTestCases --module-arg CtsDeqpTestCases:include-filter:dEQP-EGL.* on a GCE instance with 4096 nofile limit Test: GfxstreamEnd2EndTests Change-Id: I4d30eca439e29727d438bdc3eff6c6207ee881ee GitOrigin-RevId: 9a061665b6a05cf6ec74661abc627bcb024543c4
Graphics Streaming Kit is a code generator that makes it easier to serialize and forward graphics API calls from one place to another:
The latest directions for the standalone Linux build are provided here.
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)
To re-generate both guest and Vulkan code, please run:
scripts/generate-gfxstream-vulkan.sh
First, build build/gfxstream-generic-apigen
. Then run:
scripts/generate-apigen-source.sh
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%
.
There are Android mock testa available, runnable on Linux. To build these tests, run:
m GfxstreamEnd2EndTests
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.gfxstream vulkan is the most actively developed component. Some key commponents of the current design include:
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.