commit | 1006a864581cb6b96c408fc278225777dbefe0a8 | [log] [tgz] |
---|---|---|
author | Yahan Zhou <[email protected]> | Tue Apr 09 16:39:07 2024 -0700 |
committer | Yahan Zhou <[email protected]> | Fri Apr 12 15:41:23 2024 -0700 |
tree | a3c46e0af393d7ca6f7d1bb06e55b989b508ac88 | |
parent | c3407cd72eab0832c6d2b811ce0479386bf0cc31 [diff] |
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: Ice45b04292eea151bed18988872e2f34401b7182
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.