commit | bc4b38bb21451167dd9f8ab294ff650ca0a253f1 | [log] [tgz] |
---|---|---|
author | Lingfeng Yang <lfy@google.com> | Tue Jan 12 14:00:36 2021 -0800 |
committer | Lingfeng Yang <lfy@google.com> | Sun Jan 24 11:37:52 2021 -0800 |
tree | df19bd6cb6d3f38850beb400efec58bce93a04f3 | |
parent | 73225d20cace06c2144c98d3fae0b57d1eb76c14 [diff] |
[19/n] VkDecoderGlobalState: VulkanQueueSubmitWithCommands Bug: 177241396 This contains the bulk of the protocol changes for the VulkanQueueSubmitWithCommands optimization. It has two aspects, both of which are guarded by a feature flag: 1. Adding a sequence number to each encode/decode 2. Not serializing the dispatch VkCommandBuffer if we are doing queue submit along with commands, since we already know which VkCommandBuffer to use. The global sequence number has the effect of imposing a strict global sequence on all calls, which makes us slower than before in a lot of cases (esp ones where there is lots of multithreaded activity), but overall increases correctness. However, we do relax the global sequencing in some cases, such as for the vkWait* operations and vkQueueFlushCommandsGOOGLE. RELAXED commands cannot be reordered before any non-relaxed commands that have a lower client sequence number, but can be reordered both before and after other RELAX commands, and reordered after commands with a higher sequence number. That is, our current situation is that vkCmd* are arbitrarily reordered (to support command recording parallelism) but most non-vkCmd* API calls get the global ordering treatment. The next step would be to introduce some notion of per-object sequence number and have the guest tag each object with a notion of acquire and release operation, not like atomic APIs. This will let us more freely retire API calls in different orderings without affecting semantics, nor having to construct and consume a command dependency graph. Also: Decoding command buffer intermediate contents from the guest (subdecoding) is now connected to VkDecoderGlobalState. When we subdecode we spawn a reading stream (from a pool of them so we don't reallocate every time), and pass that to the subdecode routine (which is codegenned) Change-Id: Ide39da51d35ca151e2ad5a8b58829aa9d1ebc027
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 you are using Clang as your CC
and CXX
. 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)
scripts/generate-vulkan-sources.sh
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.